Skip to content

Latest commit

 

History

History
2297 lines (1822 loc) · 141 KB

2022 WG Meeting Notes.md

File metadata and controls

2297 lines (1822 loc) · 141 KB
Raw

OpenSSF Vuln Disclosure WG Notes - 2022

→Notes for 2023:OpenSSF Vuln Disclosure WG Notes - 2023

→Notes for 2021:OpenSSF Vuln Disclosure WG Notes-2021

Antitrust Policy Notice: Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

20221214

Attendees: (Change color or add your entry)

  • CRob (Intel)
  • Madison Oliver (GitHub Security Lab)
  • Jonathan Leitschuh (Alpha Omega - OSSF/LF & Dan Kaminsky Fellowship - HUMAN)
  • Randall T. Vasquez (Gentoo)
  • Kate Catlin (GitHub)
  • Yogesh Mittal (Red Hat)
  • Jay White (Microsoft)

Meeting Agenda

Opens

OSS-SIRT SIG Section Team Activities

  • Full SIG (CRob)
    • OSS-SIRT plan delivered to TAC for review/comments. Anyone can still provide feedback via SIG issue 32
    • Expect to have deeper conversation with TAC in January

Meeting Notes:

20221130

Attendees: (Change colour or add your entry)
  • Madison Oliver (GitHub Security Lab)
  • Crystal Hazen (HackerOne)
  • Randall T. Vasquez (Gentoo)
  • Nathan Menhorn (AMD)
  • Ixchel Ruiz (JFrog)
  • Yogesh Mittal (Red Hat)
  • Art Manion (self)

Meeting Agenda

  • [CRob] - regrets, I have in internal call to do a “show and tell” about the OSSF to Intellers and can not make the call today
  • New Friends intros
  • Who wants to help out and scribe for us today?
  • Opens
  • OSS-SIRT SIG Under RFC period - please read it, give feedback through ossf/SIRT#32 by 2Dec2022 (Friday!)
    • After the RFC period, it will go from the SIG likely to the TAG (or elsewhere in upper OpenSSF/LF management)
    • Note: this is a plan, and not explicitly “this is what the SIRT will do: …” details
  • Discuss options for next group project/future work for WG
  • Is there another working group in OpenSSF that is setting up security-themed office hours for the community?
    • Yes, trying to determine how to get it off the ground and is still in early phases of development
  • Some folks have shown interest in presenting the Finder guide at conferences or other places and are encouraged to do so!
    • Shmoocon CFP: Nov 30, 2022, its Jan 20-22, 2023
      • Possibility > Bring It On track: 20- or 50-minute presentations with an open mind to technology and security related topics.
    • OpenSSF Summits in 2023 might also be a great place to share this information
      • OpenSSF Day at summits tends to be more curated content so we may be able to more easily fit in here, otherwise we can submit a CFP for the full event
    • What story do we want to tell? We can craft the abstract and presentation to be fairly reusable across conferences and working group members
    • Do we consider the guide to be finished enough to share more broadly? -> Yes
  • Open PR on the Finder guide fixing some grammar and making a few edits from Madison Oliver - this still needs review, approval and merged
  • SHMOO CFP 2023 - So you've found a security vulnerability, now what? - Document currently owned by Jonathan Leitschuh, needs to be moved into a LF location
    • Would appreciate any feedback on the title

Opens

  • None today

20221116

Attendees: (Change colour or add your entry)

  • CRob (Intel)
  • Madison Oliver (GitHub Security Lab)
  • Jennifer Mitchell (Tidelift)
  • Crystal Hazen (HackerOne)
  • Randall T. Vasquez (Gentoo)
  • Arnaud J Le Hors (IBM) (first half of the meeting)
  • Nathan Menhorn (AMD)
  • Sandipan Roy(Red Hat)
  • Yogesh Mittal (Red Hat)
  • Joe Sepi (IBM)
  • Jason Keirstead (IBM)
  • Avishay Balterr (Microsoft)

Meeting Agenda

  • New Friends intros
  • Who wants to help out and scribe for us today?
  • Opens
  • SIRT.SIG and WG calls during US Thanksgiving and End-of-Year Holidays
    • WG call will canceled 28Dec
  • Report of from OSS-SIRT SIG Sections
  • GROUP DISCUSSION
    • Arun Gupta ([email protected]), Intel to talk about OSSF upstream CVE remediation timelines guidelines
    • Recent CVE in zlib highlighted many critical oss projects have one or few maintainers and sometimes have limited security policy/documentation around vuln handling practices
    • How do we support these critical projects that many enterprises and foundation members use?
    • How do we ID these “at risk projects”
    • Secure Software Covenant Idea for members to pledge to support these high-impact critical projects
    • Yogesh notes that most maintainers do not know their downstreams.
    • Arun - many of us here have “critical lists”, we could combine these list to find the top ones to focus on
      • Yogesh acknowledges they also see the similar problem
      • Randall some projects WANT a select/small group of maintainers and do not want outside assistance (cites gpg project, dev likes to work alone)
      • Avishay - security tooling wg has stats on staggering numbers of projects that have single/few maintainers. Have other tools the foundation provides (scorecard, for example) been considered to be used to vet incoming ingestion of projects
      • Arun - Scorecard is being considered, yes. GB is very excited around Scorecard’s use, but the scorecard does not highlight the criticality of the project (the impact of issues in a given project)
    • Randall - Securing Critical Projects WG has a “set” of critical projects. The metrics are not a be-all, end-all and are not a competition/beauty show
      • Art M - in recent direct experience, a couple ~single dev projects didn't really want to publish CVE IDs, but were OK grabbing upstream patches, reviewing CVE IDs, and mentioning them in release notes. I/we wrote and handled the CVE stuff for them. also backports, fixing via commits vs. publishing new releases with version bumps
      • Randall - there is a lot of interest in this list
      • Randall - criticality score tool was meant to feed a list of projects and give output. Caleb is the lead developer
    • Arun - are we aware of other WGs that are also working through these challenges?
  • GROUP DISCUSSION - Issue 118 - Vote by 30Nov
    • Request to setup an APAC-friendly call for this WG. Who is interested/able in making such a call? How would we like to handle that:
      • Change call completely over to APAC-friendly time
      • Alternate calls every other meeting between EU/NA and then APAC
      • Hold extra quarterly meetings in APAC TZ, keep this call the same
      • Do nothing, make Aussies and all of APAC sad
      • Other amazing idea…..
  • Discuss options for next group project/future work for WG
  • Group to note interest (113 & 115 had most interest on the call) and follow-up meetings will be setup to start developing these ideas

Opens

OSS-SIRT SIG Section Team Activities

  • Team 1 - Problem Space (Randall) *
  • Team2 - ID core services (Art) *
  • Team 3 - Execution (Francis) *
  • Full SIG (CRob) *

Meeting Notes:

  • Expect meetings at the end of the year to be canceled as staff becomes unavailable for the holidays

20221102 - Call Canceled

Attendees: (Change colour or add your entry)

Meeting Agenda

  • New Friends intros
  • Who wants to help out and scribe for us today?
  • Opens
  • Report of from OSS-SIRT SIG Sections
  • Discuss - OSS-SIRT Section 3 - Discovery of what's out there for tooling for Incident Response #8

Opens

OSS-SIRT SIG Section Team Activities

  • Team 1 - Problem Space (Randall) *
  • Team2 - ID core services (Art) *
  • Team 3 - Execution (Francis) *
  • Full SIG (CRob) *

Meeting Notes:

20221019

Attendees: (Change colour or add your entry)

  • CRob (Intel)
  • Madison Oliver (GitHub Security Lab)
  • Yotam Perkal (Rezilion)
  • Francis Perron (Google LLC)
  • Jeffrey Borek (IBM)
  • Randall T. Vasquez (Gentoo)
  • Yogesh Mittal (Red Hat)
  • Avishay Balter (Microsoft)
  • Sandipan Roy (Red Hat)
  • Jonathan Leitschuh (Dan Kaminsky Fellowship @ HUMAN Security)

Meeting Agenda

  • New Friends intros
  • Who wants to help out and scribe for us today?
  • Opens
  • Report of from OSS-SIRT SIG Sections
  • GROUP DISCUSSION
    • Arun Gupta, Intel to talk about OSSF upstream CVE remediation timelines guidelines
  • DECISIONS NEEDED
    • Meeting cadence - 2x monthly vs. 1x monthly
      • We’ll want to document our new Issue Warden role into our git repo too
    • Does the group want changes to how things are run/change in leadership?
  • Discuss options for next group project/future work for WG
    1. Project Idea - CVD Guide for OSS Consumers - PR 115
      • This was discussed at the 13october End User WG to MUCH excitement
    2. Project idea: guide for maintainers on handling incidents - PR113
    3. Project Idea - create plugins and/or other tooling to enable CVD Guides- PR116
  • End User WG LOVED the idea of collabing on a CVD Guide/explainer for OSS-Consumers!

Opens

  • None

OSS-SIRT SIG Section Team Activities

  • Team 1 - Problem Space (Randall) *
  • Team2 - ID core services (Art) *
  • Team 3 - Execution (Francis) *
  • Full SIG (CRob) *

Meeting Notes:

  • OSS-SIRT SIG section review
    • So far the plan is going well, intend to share it with the TAC for funding approval as early as 2nd week of November
  • WG meeting feedback
    • Unless we have an active project, vote to keep the cadence monthly. If there’s an active project, we can increase it to biweekly or weekly
    • Everyone is in favor of continuing the way the group is run and having Crob as our chair
    • This will go to a vote in the email list post-meeting
  • Future project ideas:
    • PR 115 - CVD Guide for OSS Consumers
      • Consumers could be pretty broad - enterprises, end users/developers, open source downstream dependencies
    • Other content ideas aside from a guide? Podcast, webinar, blog, more engagement with the Education SIG
      • PR outside of the OpenSSF opportunities? CVE podcasts, engagement with open source ecosystems
      • Is there a budget for any of this?
        • 2 funding options: submitting a request through the WG with project description, and collaborating with the Education SIG (they intend to work with us already on CVD training resources in the future)
    • PR113 - Guide for maintainers on handling incidents
      • How to handle a fire when it arises
      • Red Hat recently released an IR plan, its meant to be consumed by the open source community and is not Red Hat-specific
    • PR116 - create plugins and/or other tooling to enable CVD Guides
      • It’s meant to be more than updating the existing guides, so tooling that allows for a specific task - no concrete idea yet on what tools are needed but is something we can look into
      • How can we make tooling platform agnostic?
      • The goal is to raise maintainer’s security bar and make various sections of the CVD guide easier to implement
  • There may be opportunities to collaborate with the PSIRT SIG in FIRST to generate content
    • Could we create a lab where folks can practice or train on the guides we’ve created? There’s a space in the Best Practices WG where this could live
  • Can the WG promote standards about vulnerabilities in cloud environments?
    • The disclosure process can be uniquely difficult for these types of products/vendors because it’s not standardized, and healthy security practices (assigning a CVE, publicly disclosing the issue) aren’t consistently followed
    • Could any CVD tooling help this community specifically? Several of the hyperscalers are members of OpenSSF so there’s opportunity to engage with them
  • It’s CFP season! The WG is welcome to submit proposals to security and development focused tech conferences about the work that the group is doing, and encouraged to collaborate with one another

20221005

Attendees: (Change colour or add your entry)

Meeting Agenda

  • New Friends intros
  • Who wants to help out and scribe for us today?
  • Opens
  • Report of from OSS-SIRT SIG Sections
  • Discuss options for next group project/future work for WG
    • #113
    • [vm] does anything currently exist on this?
    • [randall] - github docs

Opens

OSS-SIRT SIG Section Team Activities

  • Team 1 - Problem Space (Randall)
    • Team notes
    • Talked with Homebrew team about current challenges
    • Wwill be talking with Gentoo team later this week
    • [VM] what has attendance been like with these calls? [Randall] light but steady
  • Team2 - ID core services (Art)
    • Plan review in flight
  • Team 3 - Execution (Francis) - in Absentia
    • Updated the Plan with clearer goals, including blockers on other sections
      • Discussion in PR #5
    • Started a discussion thread for “what’s out there for tooling”
      • Issue #9
    • Meta - need to figure out how we track work for all sections
    • Every attendee left with action items
      • CRob to chat with folks
      • Randall to look at tools
      • Francis to do the needful
  • Full SIG (CRob)
    • Deadline to submit proposal for Stream 5 to GB - 01Dec2022

Meeting Notes:

  • #113
    • Next project? A guide for helping maintainers handle reports?
    • VMB: Does it exist already?
      • No one knows of one
    • CRob: Worth doing an initial investigation about doing this?
      • All thumbs up!

20220921

Attendees: (Change colour or add your entry)

  • CRob (Intel)
  • VM (Vicky) Brasseur (Wipro)
  • Madison Oliver (GitHub Security Lab)
  • Jonathan Leitschuh (Dan Kaminsky Fellowship - HUMAN)
  • Jennifer Mitchell (Tidelift)
  • Yotam Perkal (Rezilion)
  • Francis Perron (Google LLC)
  • Randall T. Vasquez (Gentoo)
  • Nathan Menhorn (AMD)
  • Avishay Balter (Microsoft)
  • Pedro Iglesias (Microsoft)

Meeting Agenda

  • New Friends intros
  • Who wants to help out and scribe for us today?
    • VMB will try, but more help needed plz
  • Opens
  • Last week CVD Guide for Finders was publicly announced! Thanks to everyone that helped assemble it!
  • Update on OSS-SIRT SIG
  • Discuss options for next group project/future work for WG
    • CVD Guide for Consumers or OSS?
    • Tooling to help enable guidance from guides
  • Homework for next time
    • Review Issue Backlog, make comments and note what can be closed, needs attention/discussion ← are there items in here we want to pick up as next/future projects

Opens

Meeting Notes:

  • OpenSSF Day recap from CRob
    • CVD Guide for Finders was publicly announced!
    • Thank you for all of your contributions! You’ve helped people, and that’s what it’s all about
    • Ton of feedback from attendees (not on the guide, but in general); very well received
    • Expect we’ll see more contributors from the EU
    • Francis: How are we handling PRs for the guide going forward?
      • CRob: Will review issues/PRs in this call, both for WG backlog and guides
  • CRob: What cadence should we have for reviewing these things?
    • Folks seem to like monthly review for the issues/PRs
    • Since this is a biweekly call, that’ll give us a work call and a review call; good mix
    • We’ll give this a try!
  • CRob with update on SIRT SIG
    • Have reviewed the relevant part of the mobilization plan
    • Have split the team into 3 focus areas:
      • Define problem space
      • ID core services & processes
      • Execution of the plan (select tooling, possible hiring, etc.)
    • SIG call every other week, focus area groups meet on own schedule
    • Find all the info at OSS-SIRT SIG
    • JL’s interested in participating; Randall will get him up to speed
  • CRob: What should our next project be?
    • Perhaps CVD Guide for Consumers of OSS?
    • VMB: Will be tricky (audience has different sort of experience/knowledge from any others we’ve written for), but would be valuable
      • Also great collaboration point with End User WG
    • Francis: Could be helpful to create plugins and/or other tooling
      • CRob: +1; may need to cultivate WG members w/the knowledge to do these things
  • Reviewing the issues/PRs
    • [note taker had to step away]
  • AR - create Issue templates, tags

20220907

Attendees: (Change colour or add your entry)

  • CRob (Intel)
  • Madison Oliver (GitHub Security Lab)
  • Jennifer Mitchell (Tidelift)
  • Yotam Perkal (Rezilion)
  • Francis Perron (Google LLC)
  • Randall T. Vasquez (Gentoo)
  • Avishay Balter (Microsoft)

Meeting Agenda

  • New Friends intros
  • Who wants to help out and scribe for us today?
  • Opens
  • Finalize 1.0 draft and push to GH this week:: CVDguidance for sec researchers
    • GOAL - to publish and present as part of the Sept13-16 OSS EU

Opens

Meeting Notes:

Future Work

  • CVD Guide for OSS Consumers
  • CVD Templates repo

20220824

Attendees: (Change colour or add your entry)

  • CRob (Intel)
  • VM (Vicky) Brasseur (Wipro) GHID: vmbrasseur
  • Jennifer Mitchell (Tidelift)
  • Francis Perron (Google LLC) -- github.com/u269c
  • Crystal Hazen (HackerOne)
  • Randall T. Vásquez (Gentoo) (ran-dall)
  • Arnaud J Le Hors (IBM) - https://github.com/lehors
  • Jay White (Microsoft)
  • Sandipan Roy (Red Hat)

Meeting Agenda

  • New Friends intros
  • Who wants to help out and scribe for us today? Francis Perron
  • Opens
  • Work on our next project: CVDguidance for sec researchers
  • **Next call **we will review WG Charter and go through Issues & PRs
    • Define & document in readme.md current Contributors, Collaborators, and Maintainers based off of 2022 attendance
    • Collaborators and Maintainers vote to approve/modify current WG charter
    • Does the group desire any changes in how WG is led or conducted?
    • We are looking for w WG co-lead, if anyone is interested in assisting
      • Francis: what are the responsibilities?

Opens

  • [CRob] anyone interested in providing GH id, please link it with your sign-in above
    • all: OKAY CRob.
  • [CRob] we’ll do a blog about CVD guide and announce release ideally at OSS-EU
    • Publication Date: 2022-sep-13..16
    • Deadline for draft: 2022-sept-07
    • Owner: Randall
      • drafted already, will provide this soonish.
      • Link to be sent to the slackroom

Meeting Notes:

  • CVD Guide
    • Francis: sent in issues/110 on templates for researchers
    • Disclosure Options (p7 for now, the big table):
      • Some descriptions need to be updated, and merged back with other sections.
        • TODO(Randall): sync CERT definitions with these
      • Is that list good enough?
        • group: agreed on keeping it minimalistic, and mark it as non-exhaustive
      • “write your disclosure for the public”
        • in order to avoid having rewrites happen when vulns are reported.
        • TODO(francis): write a little blurb above the purple comments.
      • Bugbounty… keep it in the table? is this a recommended option?
        • new sections for each types to offer suggestions?
        • shouldn’t we move this to more of a “vehicle” as opposed to a disclosure option here? BBounty isn’t really disclosing-related.
        • Group vote: agreed on making taht section
          • owner: Kayla Underkoffler
    • CNA of last resort
      • CRob: can we remove this?
      • Group: aye.
    • Dropping a 0-day
      • Francis: how about adding a little note that 0-days can happen, and it means we had a failure of the whole disclosure process.
        • Group: we would like to acknowledge that this exists, but want to be careful about wording this section…
        • Group: let’s move this to the “troubleshooting” section
      • Kayla: we should be clear about phrasing the 0-day section to be clearly different, but related, to te Full-disclosure disclosure option
      • Need volunteer to reword this: Kayla U. with Crystal H.
    • Appendices:
      • Defs:
        • see 2022-Jul-27 discussion
          • send this to have the Education SIG take this on to create a common language across all of OpenSSF, maybe even do a website.
        • TODO(francis): file an issue to get this looked at by the education SIG
          • CRob: I will stage a file in the edusig and ask for contribs
      • Templates:
        • Generate agreement to close issue111 with the suggested PRs
        • Embargo template:
        • Expectations for researchers:
          • as a researcher, what can I expect by reporting something?
          • → talk to Madison O. about this.
        • Vuln report submission
          • Francis: see PR#112
          • CRob: I did a presentation on this, I may have an example as well.
          • Jason: how about an example of a BAD REPORT?
        • Diff between Vuln reports vs Bug report
          • Vicky: just to help clarify this for non-security folks reporting things.
          • Jason: projects tend to have their own idea of what they want in their bug/vuln reports, we may not want to be prescriptive on this.
            • Group: point to prior-art on this, outside the doc, snip this section.

Next Meeting

  • For future call: Revisit maintainer guide; haven’t looked at it in a year; is it still up to date?
Action Items:
  • Randall:
    • Update disclosure descriptions with CERT’s
      • send verification to Crystal H.
  • CRob:
    • make sure we clarify this disclosure list is both non-exhaustive and non-exclusive
    • stage a file with the glossary / definitions for the community to contribute to
    • Reach out to Madison about the Expectations discussion
  • Francis:
    • flavortext for disclosure deduping
    • start working on a potential PR for adding the CVD guide to the repo
    • file an Issue agains the edusig for generating a common language glossary
  • Kayla U &Crystal H:
    • make that “vehicle” section blossom for additional resources
    • Move the “0-day” section to troubleshooting and discuss this better
    • Pass through the document to ensure acronyms are first described.
  • Jason
    • Provide an example of a BAD vulnerability REPORT

Next project: CVD guidance for sec researchers - Target release - ~~BH USA Aug 2022? ~~OSS-EU Sept 2022

20220810

Attendees: (Change colour or add your entry)

  • CRob (Intel)
  • Madison Oliver (GitHub Security Lab)
  • Francis Perron (Google LLC)
  • Randall T. Vasquez (Gentoo)
  • Brian Fox (Sonatype, OSSF GB)
  • Sebastian Crane
  • Peter Singh (Fuzzy- Astro Tech)

Meeting Agenda

  • Special Time for today: only 30mins due to BlackHatUSA
  • New Friends intros
    • Hi Brian! He’s a veteran at community wrangling.
    • Hi Sebastian! He’s our SPDX person as of now.
  • Who wants to help out and scribe for us today? Francis Perron
  • Opens
    • OSSF Day in Dublin (Sept 12ish), CFP coming up
    • See the Slack channel for details
  • Is anyone going to the OSSEU conference? Do we want to do a meet-up to collab on anything in person?
    • There will be an OSSF Day, we may want to do a preso about our CVD guides there
  • Work on our next project: CVDguidance for sec researchers
  • Update to the TAC on WG & SIG 6Sept
    • Will be using this ppt for the update, patches welcome

Opens

  • CRob will probably have to step out around 930 for a BH thing

Meeting Notes:

  • Traveling to Scotland?
    • TODO(you): ping Fuzzy for inspiration.
  • OSSEU in Dublin
    • Meetup would be nice.
  • OSSF Technical Advisory Committee (TAC) presentation - Sept 6th
    • CRob: we’ll put a deck up (see below), with status updates and next steps
      • accepting volunteers for help.
  • CVD guide discussion
    • Call for Contributions: Glossary, References, p14’s Templates & Examples
    • Deadline: Let’s try to finalize this before the TAC update (2022-SEP-06)
    • Madison Oliver: we mentioned wanting the LF editors to check… how about asap?
      • CRob: yes, let’s chat with them to start something 2022-AUG-31
  • Working Sessions to get this completed:
    • 4 volunteers already, early next week tentatively.
    • Request: someone to do a DOODLEthingy for date selection - ToBeEmailed.

Next project: CVD guidance for sec researchers - Target release - BH USA Aug 2022?

20220727

Attendees: (Change colour or add your entry)

  • Paulo Flabiano Smorigo (Ubuntu/Canonical)
  • VM (Vicky) Brasseur (Wipro)
  • Madison Oliver (GitHub Security Lab)
  • Randall T. Vasquez (Gentoo)
  • Jennifer Mitchell (Tidelift)
  • Francis Perron (Google LLC)
  • MegaZone (aka MZ) (F5, Inc.)
  • Kayla Underkoffler (HackerOne)
  • Sandipan Roy(Red Hat)

Meeting Agenda

  • New Friends intros
  • Who wants to help out and scribe for us today?
  • Opens
    • INTENTIONALLY LEFT BLANK.
  • Work on our next project: CVDguidance for sec researchers
    • Project goals
      • Help explain OSS dev practices to Finders
      • Promote collaboration through CVD
      • Provide links & resources to effectively share vuln reports to oss maintainers
    • Outstanding areas to address:
      • Intro (probably done last)
      • Glossary of term definitions
      • Templates & resource links
      • ~~Explanation on Vuln identifies (~p4)~~
      • Explanation how oss development works/flows and talk about scheduling/backlog
      • Explanation of difference between pure upstream and commercially-backed projects
      • ~~Disclosure options table (~p7)~~
      • Troubleshooting common challenges section (p10 and following)
      • Review brainstorming ideas on p12
      • Is VDP & BBP section already addressed in doc or does p12 & following need moved up in the body of doc

Opens

Meeting Notes:
  • [email protected]to lead the meeting
  • Glossary of Terms
    • Vicky: did a first pass, found jargon/acronyms, and put them a sort|uniq in the doc, at the end; We need help defining them
      • Madison: I’d love to help. Should we split this in its own doc?
      • VM: +1 to split this.
      • Randall: true, lots of docs have glossaries as well
      • Francis: how about we have a site?
      • VM: How about we have the EDUCATION WG do this!!
  • Bibliography
    • Vicky: I did this as well, it also needs to be cleaned up. I can do this as I love books.
  • Templates
    • Vicky: 2 templates were created
      • Need someone to convert them or review them so that FINDERS (not simply maintainers) can use them
      • What other templates do we need?
        • Randall:: I’d recommend we have a look at the Kubernetes templates.. they have good stuff
        • Vicky: What about a “personal CVD guide” for researchers wishing to do this themselves? like this … should we templatize this?
          • Randall: +1 on this, lots of communities like to move fast
          • Francis: how about a 1-pager version?
            • Randall: you have ppl on both sides of the isle here, where some folks really want to read the full documents/process,
            • Vicky: I love the idea of a 1-pager as well. Adding this to the TODO for later.
        • Madison: about about splitting/categorizing this in the different disclosures options?
          • Vicky: agreed, let’s wait for the document ot be more complete before embarking on this, thoughts?
        • Randall: lots of more junior contributors/maintainers do not grasp why security is important and friction is created. Do we want to address this in the document?
        • Kayla: A vuln report template - what it should look like.
          • Francis: I have one I can share.
          • Madison: agreed, we have one, let’s work on that together.
    • Explanation on Vuln identifies (~p4)
      context: OSV, CVE, …
      • Madison O.: I talked to Oliver Chang from OSV, and concluded it is not possible to do this.. OSV only generates entries for specific context/software at the moment.
    • Explanation how oss development works/flows and talk about scheduling/backlog
      Context: needs a new section - How OSS dev works
      • include Explanation of difference between pure upstream and commercially-backed projects
      • Vicky: I’m working on a book about this, I want to take a stab at it plz
      • Kayla: please include the different styles of OSS dev environments (small shop vs full distro, for example) to surface the engagement styles and processes… just making sure we outline these.
    • Disclosure Table
      • Francis: this section was added live during a meeting, it’s not complete
      • Kayla: maybe if we find standard definitions here as opposed to quick, opinionated descriptions? eg: ‘FD’ means a different thing for my corp
        • Comment:** there might be ISO standards on this**
        • Vicky: these probably cost money… let’s see if free options exist.
        • Madison: added a comment with some resources
    • Troubleshooting common challenges section (p10 and following)
      • Vicky, Madison: unclear as to what this refers to. Need help passing through this w.r.t. finders/maintainers context improvements.
      • → Punted to next meeting.
        • Madison: FYI, Next meeting falls under BlackHat. . .
        • Vicky: I’ll comm that out.
    • Review brainstorming ideas on p12
      • ~~How to get a CVE id - ~~ addressed
      • What is OSS tl;dr: -- working on this
      • included in bug report -- added to NEEDED TEMPLATES.
      • Exploits? PoC? -- NEED to be discussed
        • Kayla: it is a leeeeeeeeeetle bit referenced, “after established secure channel…” but it could probably use its own section
        • Francis: PZ has some “exploit disclosure process” already, we could look at it for inspiration
      • Write disclosure for the public to avoid duplication -- moved up to the Setup disclosure section for further clarification
      • Timelines for disclosures --
        • Somewhat already in the personal disclosure section, without numbers (purposefully)..
        • Kayla: embargoes are somewhat in-scope…maybe a new section? → needs to be discussed further again
      • Dependency Vulns coordination -
        • do you, as a researcher, need to coordinate this?
        • → not discussed in the doc yet.
      • Diff between BB & VDP
        • Kayla: discussed already, will erase this section below in the doc here and make it a section above
  • High Level about the doc
    • Kayla: i see a lot of “finders vs maintainers” point of views that need to be added to each sections, do we want to actually take a look at how we want to position the document first?
      • Vicky: don’t know if we figured this out yet, but if someone wants to volunteer at looking at the document as a whole to see about what to do here → Kayla, in suggest mode
Action Items
  • TODO(Madison O.):
  • TODO(Vicky B.):
    • work on the Biblography clean-up.
    • populate OSS dev work
    • Figure out if we are meeting in 2 weeks (Aug10), communicate this out to the list
  • TODO(Kayla U.):
    • Add some good wordings around “the Human Element” of dealing with maintainers and researchers
    • Will look at references and other provided definitions for the different disclosure styles - might work with the Glossary as well
    • Review the whole document to see and reflect about the point of view described (finder vs maintainer) and make suggestions
    • Add a BB vs VDP program section
  • TODO(Francis P.):
    • provide a vuln report template for researchers

Next project: CVD guidance for sec researchers - Target release - BH USA Aug 2022?

20220713

Attendees: (Change colour or add your entry)

Meeting Agenda

Opens

Meeting Notes:

  • SIRT SIG update
    • Stream 5 from the mobilization plan
    • Weekly calls; we’re now 2 weeks in: Tuesdays at 09:00 EST
    • Repo: https://github.com/ossf/SIRT (work in progress; it’s new)
      • Will contain notes & artifacts
    • Will have a mailing list & slack channel eventually. Stay tuned!
  • CVD guide for finders/researchers review
    • https://docs.google.com/document/d/1u3NqbFr0o7PkWeyjIvWB-M16S4E1ZQSbMRTHiMzbVUA/edit#heading=h.m102bvvl6xzl
    • General consensus is that we’re happy with the way the document is shaping, many comments have been made/accepted
    • Future work that still needs to be done is applying the LF style/brand guide to the document - https://linuxfoundation.org/brand-guidelines/
    • Do we need to do more with the “Who is an open source maintainer?” section/definition?
      • No feedback from the audience
    • Gonna focus on filling out Disclosure Options (currently on p8)
      • Most of the work on this is happening in the document itself
      • Francis reformatted it to a table & everyone loved that (thanks, Francis!)
      • Listing them all and giving plusses/minuses
      • Specifically calling some out as endorsed by OpenSSF; this is a reflection of us taking the perspective of the FOSS maintainers: which options are best for the ecosystem? Those are the ones we endorse.
    • Recommend CVEs over alternatives (like OSV)?
      • CVEs are the standard in North America, for instance
      • But there are alternatives, including proprietary options from SCA vendors
      • Cloud providers are a different sort of beast; often fix w/o notifying
        • Should make sure to note that there will be differences when approaching a hyperscaler/cloud service provider
      • Josh Buker: Can say there are alternatives but we’ll be using CVE in the examples
        • Everyone’s on board with this idea (thanks, Josh!)
      • Prior to finalising this document, would like to hear from the OSV folks (CRob added a note to that effect in the document)
      • If you’d like to provide verbiage around all this stuff, please do so!
    • ISO standard stuff
    • “When all else fails” section (currently p9) needs augmentation
      • Note that you shouldn’t be a nuisance, especially if it’ll work against your goals
      • We’ll be recommending that 0-days shouldn’t be the first course of action; Kayla will reword (thanks, Kayla!)
    • “Ensuring everyone understands what and how things will be disclosed” has no content (oh no!)
      • Slowly iterating on this during the call
      • All agree that being explicit & up-front, setting expectations ASAP, is important
      • May need to get legal review for this section, especially for having your own disclosure policy
        • Do expectations get expressed as Terms & Conditions?
        • Are these enforceable?
      • May need to state that as a researcher you should set your expectations & constraints, especially in regards to dates or external forces (conference submissions, etc.)
        • “Policy” may not be the best word for it, though; we’re tripping over the formality/legality of this one
      • We want to tell researchers how to communicate best with open source maintainers - can we set up a template about what a maintainer expects to see and what a researcher can provide to make it as easy as possible? (think of an issue template)
        • Original maintainer guide has a stock security.md file and intake template, so we can absolutely do that within the researcher document as well
        • A glossary would also help with these issues as well
        • Point recommendations in the direction to increase the likelihood that the vulnerabilities will be remediated and increasing collaboration
        • Should we stylistically label WG opinions explicitly within the document separately from other recommendations?

Next project: CVD guidance for sec researchers - Target release - BH USA Aug 2022?

20220629

Attendees: (Change colour or add your entry)

  • Anne Bertucio (Google)
  • Eric Hatleback (CERT/CC)
  • Pedro Iglesias (Microsoft)
  • VM (Vicky) Brasseur (Wipro)
  • Eric Tice (Wipro)
  • Crystal Hazen (HackerOne)
  • Jonathan Leitschuh (Dan Kaminsky Fellowship - HUMAN)
  • Madison Oliver (GitHub Security Lab)
  • Francis Perron (Google)
  • Jennifer Mitchell (Tidelift)
  • Yogesh Mittal (Red Hat)
  • Kayla Underkoffler (HackerOne)
  • Josh Buker (CSA)
  • Jason Keirstead (IBM)
  • Jory Burson (Linux Foundation)
  • Randall T. Vasquez (Gentoo)
  • MegaZone (aka MZ) (F5, Inc.)

Meeting Agenda

  • New Friends intros
  • Who wants to help out and scribe for us today?
  • Open Source Summit NA and OpenSSF Day
    • What’d you like?! What went well? What didn’t?
    • OSS EU in Dublin → what should this group submit?
  • Opens
  • Work on our next project: CVDguidance for sec researchers

Meeting Notes:

  • Today the role of CRob is played by Anne
    • Sorry CRob is sitting in a pub in Cork, Ireland atm
  • New friendos?
    • Josh Buker (Cloud Security Alliance w/ Global Security Database project)
    • Pedro (Microsoft)
    • Randall (Gentoo)
  • VMB is scribing away
  • Summit/Day feedback
    • What went well?
      • Madison: Loved the content, esp. the Maven Central talk
      • Jonathan: Good to see the wide variety of people and companies who are having these conversations & addressing these problems
        • Also: Anne’s talk was really well done
          • Jory: Huge +1; total pro!
        • Anne happy to share the deck later
      • Jory: Recordings will be posted next week (will ping in Slack)
    • What could’ve gone better or what could we do differently?
      • Madison: Would be helpful to have time for the working groups to meet
        • Also, share w/community what each WG is working on
      • Josh: More outreach to let folks know OpenSSF Day is happening
      • Vicky: Clarity around the intended audience, is this for contributors or newcomers?
        • Madison: It would be great to cater to both groups, perhaps using the morning for existing OpenSSF contributors, and afternoon for newer folks. Using the morning for existing contributors may help logistically as they would be more willing to go earlier.
      • Jason: Comparing to RSA
        • RSA: Not a lot of chatter from OpenSSF community
        • OpenSSF: Not a lot of chatter from the CyberSecurity community
        • There’s a lot of work to do to build bridges between the security & FOSS communities
        • VMB: Marketing is discussing being at Black Hat; would be a good opportunity to start building the bridges?
        • Jason: YES PLZ!
        • Anne: What would we ask of the security community at these events?
          • Jason: End consumer of these communities are those doing vuln response, triage, etc
          • Key stakeholder is CISO in enterprise & software procurement
            • will start to get audited on their software
            • Will have to answer questions about security, patches, etc
          • Come in and talk to them about how OpenSSF is working on this problem and how we can help
          • Feel this WG is well positioned for this, along with End Users nascent WG
        • Anne: So mostly education about the realities of FOSS? Help those who understand proprietary to learn more about nuances of FOSS?
          • Jason: Yes. Answer “what does this mean to me?” and “is this relevant?”
          • Lots of people talking about this stuff (esp. since EO) but OpenSSF doesn’t enter the conversation
          • Everything is siloed in this space, so the more bridges we can build the better
        • Kayla: With bug bounty program, spend a lot of time addressing the gaps between the communities
          • Not CISOs, but the ones we’re writing the Finding CDG for
          • Evangelizing between communities to identify synergies is critical
          • Was recently in a focus group for ENISA & brought up that FOSS components are out there, discussing how to educate security communities how to deal with this
          • So huge +1 to what Jason is saying
          • Would love an OpenSSF speaker for HackerOne conference later this year (get them onto a panel)
            • Jonathan volunteers (Yay! Thanks, JL!)
        • Anne: Are people here planning to attend Black Hat?
          • JL is (and B-Sides Vegas, and Defcon)
          • Jason is, as is Josh
          • Crystal will be at Def Con and BSides, plus the last day of Black Hat
        • Jory: High level stuff
          • Marketing talking about sponsoring Black Hat, but have been lukewarm because they don’t know what the value story is
          • Going to introduce Jason & Jennifer Bly to refine what the booth could be
          • Minimum: provide partners with some sort of asset to have at their own booths (“Proud member of OpenSSF” sign or what have you)
          • Brian planning to be there, host a dinner or something
          • Good opportunity for 2023 to have things a lot more coordinated now that Jennifer is here (thanks, Jennifer!)
    • Anne: Do we want to have a presence at other events?
      • Madison: Reporters guide will be done in August; present in Dublin
        • JL: Will need to submit to the CFP?
        • VMB: Unless there’s another OpenSSF Day?
        • Jory: Are collocated events for Open Source Summit
          • Will be looking at the attendance from this one to see what proportion of attendees were existing participants
          • Have asked OSSEU to hold a day/room for OpenSSF
            • So could probably present it there
          • Other collocated event CFPs are closed right now, including CloudNative Security Con
  • Opens?

20220615

Attendees: (Change colour or add your entry)

  • CRob (Intel)
  • Eric Hatleback (CERT/CC)
  • VM (Vicky) Brasseur (Wipro)
  • Eric Tice (Wipro)
  • Madison Oliver (GitHub Security Lab)
  • Emily Sarneso (VINCE)
  • Mike Brown (IBM) (github mikebrow)
  • Nathan Menhorn (AMD)
  • Francis Perron (Google)
  • Jennifer Mitchell (Tidelift)
  • Antonette Caldwell (Cloud Underground)
  • Yogesh Mittal (Red Hat)
  • Yotam Perkal (Rezilion)
  • Kayla Underkoffler (HackerOne)
  • MegaZone (aka MZ) (F5, Inc.)

Meeting Agenda

Meeting Notes:

  • OSS-SIRT SIG (fka Stream 5) - will be meeting …
    • Tie on the Doodle poll, but CRob found a way to make it work
    • First call will be Tuesday, July 7 at 9AM Eastern
    • Will be a weekly call
    • Meeting invite will be headed out soon
    • Anticipate smaller focused meetings to come out of it
  • VINCE
    • Vulnerability coordination tool
    • Widely used in the industry
    • Recently open sourced!
    • Emily w/a presentation (no slides)
      • https://www.kb.cert.org/vince/
      • Been in production since May 2020
      • Open sourced May 13, 2022
      • In active development now (Emily is flying solo on that right now) - https://github.com/CERTCC/VINCE
      • Walk through the project on GitHub
        • Could use some help with docs, please?
        • Have questions, need support? Please open an issue
      • Demo time! (of dev system, not live data/real vulnerabilities)
        • Three parts
          • VINCEComm: Your dashboard/view
          • VINCETrack: Coordinator view
            • Triage queue for new reports (cases), which can be assigned out if the case is accepted
            • Can add new vendors & coordinators to a vulnerability and notify them
              • Vendors are commercial entities, FOSS projects…pretty much anyone that produces software
            • Can reserve/request CVEs
          • VINCEpub public website/database view
      • Questions?
        • Near term roadmap/backlog? Esp. to be cloud env agnostic?
          • Not in the immediate future, but is a good way forward
          • See also: CERTCC/VINCE#13
        • Integration with vulnogram?
          • Used already to do the CVEs
          • Set the required fields then submit via the API
        • If reporter provides half-baked info…? The coordinators take that on?
          • Don’t expect reporters to know everything
          • Coords do investigation to get a better picture of the scope of the vulnerability
        • How do you handle embargoed info?
          • Only the vendors & coords that coordinator has added to the case will have access to it
          • Only those explicitly added to a case will see a case
          • Also possible for the vendor admin to limit which cases their users can see
        • Is this a replacement to distros-list?
          • CRob: Nope, and not plugged into it
          • Maybe will talk about these (semi-)private lists in the WG in the future
        • It’s FOSS now…how can we help?
          • Even just testing the installation docs would help a lot
          • VINCE users are very welcome to log issues/feature requests
          • If you work for a vendor, your product security team probably already uses this so reach out to your PCERTs
          • Francis: would love a wishlist of prioritized needs for the project’s public page (contributing is daunting else)
          • VMB: An hour Emily brain dump that someone then turns into that list would be a super contribution (then Emily doesn’t need to do everything)
  • Finders CVD
    • Jonathan: A few updates last week
      • Removed the memes
      • Had the intern read through it for feedback; received generally positive feedback
      • Added a warning about disclosure policies
    • Madison
      • Recorded CVE podcast last week & they want more researcher content
      • Podcast wants her to come on & talk about this doc once its done
    • Please have a look at the doc
    • Would like to have this done in August
  • OSS EU

Next project: CVD guidance for sec researchers - Target release - BH USA Aug 2022?

20220601

Attendees: (Change colour or add your entry)

Meeting Agenda

Meeting Notes:

  • New friends!
    • Yogesh Mittal (Red Hat)
    • Alex Quesada (Wipro)
  • Mobilization Plan Stream 5 & 6
    • https://openssf.org/oss-security-mobilization-plan/
    • Stream 5 (S5): Response team
    • Stream 6 (S6): Putting our CVD guides into practice
    • Proposal: Adopt streams 5 & 6 as SIGs. Feedback? Questions?
      • Yotam: could facilitate S5 for creating an OSS structure for incident response
    • Anyone opposed to us adopting these streams?
      • Nope!
    • CRob will send out a Doodle for a S5/S6 call
    • Jennifer F: Level set…this all happened quickly, so the streams aren’t perfect and we need your help to smooth out rough edges (and fill in a lot of holes!)
      • We need you!
      • Please join the SIG(s)!
  • Opens
    • Eric H: Emily is good to go for presenting about VINCE in the next meeting
      • VINCE helps coordinate vulns
      • Pretty heavily used in vendor ecosystem, and now open source!
      • So maybe we could use for S5? Let’s find out!
  • CVD for Finders
    • https://docs.google.com/document/d/1u3NqbFr0o7PkWeyjIvWB-M16S4E1ZQSbMRTHiMzbVUA/edit#heading=h.qzp7hn23sj6z
    • Jonathan & Madison have done a little work in last week (thank you!)
    • CRob added some feedback today & would like to discuss some of it
    • The memes: fun but…probably don’t belong in the official doc
      • Some +1s
      • Jonathan: Would like it to be something that’s easy to read
      • VMB: Walking in the middle: Would like it to be casual & approachable but can’t be too casual. Memes probably cross that line, alas.
      • CRob: And there could be copyright issues (ooh, good point)
      • We’ll look at this and see what we can do
    • Nathan: Are there tech editors at OpenSSF we can use?
      • …maybe? We’ll see!
      • Madison: How much lead time would they lead? We have Blackhat deadline
      • CRob: Um…about that… Blackhat proposal was declined. (sad trombone)
        • So deadline is a little more flexible, but still should aim for that timeframe
      • DWheeler is going to ask a tech editor how much lead time they’d need for 15-20 pages
    • Crystal: OpenSSF have any brand guidelines?
    • Madison: How about the idea of a glossary? Single one that can be used/linked to by all our docs?
    • Kayla: Where to relocate the VDP/BBP section?
      • Probably closer to the end…?
      • She’ll take a swing at this one for us (thank you!)
    • Morten: coordinated disclosure embargos need a bit more explanation
      • Good to refer to how the linux-distros list does it
      • Also should include “if you don’t have time to disclose this yourself…”
        • Many distros have teams that can help
        • CRob also included a suggestion for “CNAs of last resort”
    • Jonathan: What’s the current status of VDP/BBP?
      • CRob: Currently just some notes in the brainstorming section; Kayla has offered to work on it
      • Kayla: Crystal & I have worked on it a bit; currently bulletpoints; content is good but will rewrite to match style of rest of the doc & find the right home for it in the doc
      • Crystal: Used bullet points for easier reading; will switch to paragraph
        • CRob: Can add checklists, etc as needed, too!
        • Jonathan: Won’t work here, but a side by side comparison would be great!
      • Jonathan (JL): Also need to have some guidance cautioning about NDAs; be aware of where they come in and how you might see them or deal with them
        • Crystal: In prior call found this wasn’t prevalent in open source
        • JL: But common when dealing with a corporate entity that “owns” an open source project. Eg: Netflix, Amazon, Expedia, Hotels.com (JL has hit this issue with all of these)
        • Need to be aware that these agreements include an NDA; can’t disclose and can’t get a CVE if you’ve agreed to an NDA & not gotten an exception from the company
    • VMB: When close to done w/the doc, should add a tl;dr at the top
      • Executive summary sorta thing

Next project: CVD guidance for sec researchers - Target release - BH USA Aug 2022?

20220518

Attendees: (Change colour or add your entry)

Meeting Agenda

Meeting Notes:

New friends!

  • Jennifer Mitchell
  • Cliff Perry
  • Matthias Weckbecker
  • Jon Velando

OS Summit II

  • David with recap of both days
    • First meeting in January, lots of companies & OpenSSF, Apache, others
      • Came out with three goals
    • Developed 3 goals into 10 streams (Mobilization Plan): https://openssf.org/oss-security-mobilization-plan/
      • Draft, v0.9.1
    • Presented at Summit II
    • So far has been well accepted
    • Lots of comments & feedback
  • CRob w/recap of his day
    • Decent engagement, lots of good feedback
    • Esp. much discussion on education in high schools
  • OS Summit II Stream 5 & 6
  • Who’s read it so far? What are your thoughts?
    • VMB: Great summary of the working documents; all the meetings I’ve had end up asking questions about the funding/money side; would like to have more information on how to move forward/next steps
    • Anne: Workstreams more or less map to
    • working groups; intention that these streams next under WGs & then WG is accountable, or…?
      • CRob: direct correlation between several streams & WGs, yes
      • Streams 5&6 are good fits for this WG
      • Do people agree? If so, can adopt these streams as SIGs
      • Anne: Agree, definitely should be heavily in stream 5 at the very least
    • Anne: Is this the model for other streams? Adoption by WGs?
      • David: Goal 1: figure out what needs to be done. Goal 2: figure out HOW it should be done
      • Was intentionally vague on that at the time
      • His expectation is next step is for obvious WGs adopt obvious streams
        • Also expect iterations on the doc as new things are discovered
        • May also need new WGs
        • Sounds like everything is on the table, but generally things that are aligned to existing WGs will head on over there
      • There’s also the possibility there are tasks that don’t fit in OpenSSF at all: public/government actions
        • Example: education group to influence academic curricula, but would need cooperation from government agencies for that
        • David: ACM & IEEE do stuff for college accreditation and they’re really slow/hard to change things in the past but may be different now
    • VMB: Next steps? (Anne: +1, don’t lose momentum!)
  • HOMEWORK FOR NEXT CALL:
  • Note: There is significant argument/discussion on the oss-security mailing list about vulnerability disclosures for the Linux kernel & the linux-distros mailing list policy. The discussion itself is ongoing in the oss-security mailing list, subject “Re: [oss-security] linux-distros list policy and Linux kernel”. See: https://www.openwall.com/lists/oss-security/ . The challenge is that the Linux kernel generally develops fixes in public (without noting that they’re vulnerabilities); the linux-distros has a policy of reporting publicly the details of a vulnerability in 14 days. See the discussion for details. GregKH & others have commented.
    • 3 groups involved
      • linux-distros mailing list - is the disclosure of embargoed issues to Linux Distro's security teams.
      • oss-security mailing list - open source project security discussions and disclosures, where anything embargoed on linux-distro's needs to be disclosed too when public.
      • Linux Kernel - the engineers working and everything is a bug :)
    • Kernel devs disagree with linux-distros mailing list members (limited overlap between the groups)
      • Having the discussion in the list for a third group (oss-security)
      • Distros & kernel devs have different incentives, which is leading to complications
    • Hard for kernel devs to work or do things in private
      • Have been taking approach of a bug is a bug just don’t say it’s a vulnerability
    • Distro folks see vulnerabilities as a totally special thing to be handled differently
    • Initial message explaining: https://www.openwall.com/lists/oss-security/2022/05/15/1
    • General disagreement in timing, process, procedure
    • https://www.openwall.com/lists/oss-security/2022/05/17/5
    • Anne: We’re unlikely to change the kernel, but are there other projects we can help?
      • This may be the more abstract discussion
    • Jonathan: What was the process beforehand?
      • Kernel fix & then go public, or…?
      • DW: Depends on where the vuln is reported to
      • CRob: Have an SME on the call who maybe could present on next call how large, mature community operates & how downstream consumers collaborate
        • VMB: Yes, please!
        • Cliff: RH is working on a doc/playbook for how to handle these vulns at scale
          • Will ask around internally to see whether someone would come talk to us about this stuff

AOB

  • Eric Hatleback: VINCE is now OPEN SOURCE SOFTWARE!

Next project: CVD guidance for sec researchers SIG - Target release - BH USA Aug 2022?

20220504

Attendees: (Change colour or add your entry)

  • CRob (Intel)
  • Anne Bertucio (Google)
  • VM (Vicky) Brasseur (Wipro)
  • Eric Tice (Wipro)
  • Jeffrey Borek (IBM)
  • Jason Keirstead (IBM)
  • Crystal Hazen (HackerOne)
  • Jonathan Leitschuh (Dan Kaminsky Fellowship - HUMAN)
  • Madison Oliver (GitHub Security Lab)
  • Kate Catlin (GitHub)
  • Luigi Gubello
  • Kayla Underkoffler (HackerOne)
  • Jon Velando (Individual Contributor)
  • Lucas Gonze (Magmacore)
  • Lorenzo De Carli (WPI)
  • Nathan Menhorn (AMD-Xilinx)

Meeting Agenda

Meeting Notes:

  • New Friends intros
    • Luigi Gubello (Identifying Security Threats WG)
  • Who wants to help out and scribe for us today?
    • VMB
  • Please propose to OSS EU!
    • In beautiful Dublin, Ireland
  • Tabling the charter conversation for now
    • The TAC is doing some work to create a more unified approach
  • Luigi with SECURITY INSIGHTS https://github.com/ossf/security-insights-spec
    • Luigi! Woo! Welcome!
    • A YAML file for a standard for a repo
      • Fields include
        • If there is a bug bounty program
        • Security.md (reporting)
    • Goal is machine and human readable “single source of truth” for security information
      • What you can’t find out from a security.md or security page
      • Improve visibility
    • Vulnerability-reporting property
    • Will be platform independent (not specific to Github, for instance)
    • Feedback:
      • CRob: This is the fourth standard that we’ve seen around this information. What steps have you taken to try to integrate with FIRSTs, security.txt, security.md? How does this link up?
        • Luigi: I have a presentation for the [CFC?] group. We need this because there are a lot of standards that are different. Security Scorecards can scan a repo and find this file (problem is that projects have files in different places). Want a standard that is independent of the platform. Don’t need to move documentation, just add link to YAML.
          • Think OpenSSF is in a good position, Scorecards is very popular. A lot of open source projects follow here. One suggestion is to coordinate with Alpha Omega. Plan is to coordinate the effort to implement this file with A/O. If we can convince the companies involved with OpenSSF to also use this.
          • Risk of missing adoption is real, but OpenSSF is in a good position.
          • Every project is doing this in a different way (security.md, link to docs page) it’s difficult to collect the information. Machine readable.
          • Deprecated old dashboard, working on a new dashboard.
      • VMB: One of the things OpenSSF is going to be looking at is helping to promote the use of SBOMs. At the moment it looks like SPDX is going to be the format. SPDX is currently working on v3.0 – ISO standard – 3.0 includes various profiles including a security profile. Security profile will include a fair bit of the information here. Could be an integration point. Encourage you to show up to the SPDX community – specifically one called Defects. Also the technical WG community. They’re working on this security profile spec. Also another group, Canonicalization group. Coming up with a way to translate between SPDX and other SBOM formats. Those three groups could be very helpful for getting additional feedback and adoption. MITRE, NIST, etc are involved.
        • Luigi: Can you send me links via Slack for these groups?
        • Jason Keirstead: The other major SBOM format is CycloneDX from OWASP - https://cyclonedx.org/
      • Anne: Consider the audience here
        • Adding another layer of abstraction can make it more difficult to communicate sometimes
        • LG: YAML is a good middle ground between human & computer; readable by both
        • LG: could potentially also use this to create a database across all projects
      • Lucas: Intersection of this with the well-known URI approach?
        • https://en.wikipedia.org/wiki/Well-known_URI
        • Common technique for publishing documents that need to be widely available
        • Not exactly the same as what you’re doing here (file in a repo) but very similar and would benefit from looking for commonalities
        • LG: Important question. Repos follow no real standards for where to find files
        • Jason Keirstead: Have seen companies posting SBOMs using a well known URI
        • LG: Suggest that projects put this in the main folder of the repo, which will work even if the project doesn’t have a website
      • CRob: Thank you, Luigi!
        • Please have a look at our CVD guides
  • No other opens
  • CVD guide!
    • https://docs.google.com/document/d/1u3NqbFr0o7PkWeyjIvWB-M16S4E1ZQSbMRTHiMzbVUA/edit#
    • JL: Had a great working session with Madison
      • Had questions about things like “why disclosure is important”
      • Doc is by no means done but made a lot of progress
    • CRob: Talk about things like CertCC before going full disclosure?
      • JL: Not in the list yet; Cert also isn’t good for single-vendor stuff
      • Eric Hatleback: I’m at Cert CC!
        • Try to work with people
        • Can’t work w/in bug bounty constraints of all companies
        • Certainly do include on the list
    • Kayla & Crystal making progress on their part of the doc
      • Some of the language will need work (VDP?)
      • JL: Bug bounty orgs will have an NDA on their VDP (whatever it’s called)
        • So the differentiation between VDP and bug bounty doesn’t matter as much as ensuring that when doing this you’re not agreeing to an NDA
      • Kayla: Took the stance that a VDP should not include an NDA
    • Kayla: For bug bounties…
      • It’s open source, so shouldn’t be a non-disclosure, but it’s complicated
      • Some vendors support open source
      • Worded it “…if supported by a private entity, may be a more strict disclosure process…”
      • But don’t know whether we have an opinion on that as a group? Is there a place for non-disclosure in open source?
        • JL: No, but it’s there so we have to deal with it
      • Anne: Important to distinguish OSS projects that use embargos and the bug bounty program their use
        • (and also need to discuss OSS having embargos at all)
        • How does this work with bug bounties?
        • Crystal: Never see this in OSS, only commercial projects, so didn’t make a big deal of this in the doc
        • Kayla: Internet Bug Bounty is clear there’s no reward until/unless the finding is reported according to the project’s wishes, but have no examples of IBB-enrolled projects that have an NDA
      • JL: Sounds like this model pays researchers for their silence?
        • Bug bounty is almost like paying researchers not to air their dirty laundry
        • May disincentivize disclosure of vulnerabilities
        • For the embargos that exist, are they reasonable?
        • Kayla: IBB doesn’t pay until disclosed, and there’s always a firm timeline for the projects that have processes in place
          • For OSS, can be a longer timeline because of volunteer availability
          • But never see OSS not wanting to disclose
        • Kayla: Kept repeating during writing: focus on intended audience and context
          • So NDAs shouldn’t be an emphasis for OSS
      • JL: Stories for context
        • Project run by Expedia
          • Jump through a lot of hoops, only THEN learn the VDP is under NDA
          • Told them he wouldn’t agree to the NDA
          • Would prefer to just use email
        • Project run by Netflix
          • Have NDA on their bug bounty process
          • Sent ticket in advance to submit w/o an NDA
          • A lot of time & effort even before reporting the vulnerability
        • Don’t have a good solution to that
          • Should at least tell people that they should be aware of this
          • Communicate people that they may need to do this sort of due diligence ahead of time
        • CRob: You’re reporting to commercial entities (maintainers/suppliers)
          • Different focus than what we’re hoping for here
          • JL: So the difference is that it’s predominantly supported by a commercial entity?
            • Yes
          • CRob: May need to provide instruction to these entities in the future
            • How to make it easier to provide reports
            • NDA policies for OSS project reports
            • VMB: Have one policy that applies to proprietary & OSS; can help them create policies to do this

Next project: CVD guidance for sec researchers - Target release - BH USA Aug 2022?

20220420

Attendees: (Change colour or add your entry)

  • Eric Hatleback (CERT/CC)
  • VM (Vicky) Brasseur (Wipro) (and Nigel)
  • Jason Keirstead (IBM)
  • Crystal Hazen (HackerOne)
  • Jonathan Leitschuh (Dan Kaminsky Fellowship - HUMAN)
  • Eric Smalling (Snyk DevRel)
  • Madison Oliver (GitHub Security Lab)
  • Adam Nygate (huntr.dev)
  • MegaZone (aka MZ) (F5, Inc.)
  • Marta Rybczynska (OSTC)
  • Yotam Perkal (Rezilion)
  • Sandipan Roy (RedHat)
  • Marcus Meissner (SUSE)

Meeting Agenda

  • Welcome to our new day & time!
  • Regrets from CRob - I have to lead an internal training during this slot today, can someone please assist in leading the call today?
  • New Friends intros
  • Who wants to help out and scribe for us today?
  • Opens
  • Charter review & ratification (or debate)
  • Work on our next project: CVDguidance for sec researchers

Meeting Notes:

  • New friends!
    • Eric Smalling (Snyk DevRel)
    • Marta Rybczynska (OSTC)
    • MegaZone (aka MZ) (F5, Inc.)
    • Sandipan Roy (RedHat)
  • Charter
    • Jason Keirstead: Questions about the TSC – who’s on it? How is it decided?
    • VM: Doesn’t fit well with a WG – drop all the TSC stuff
    • Anne: +1
    • Jason: +1 – do things based on consensus, consensus based governance.
      • May need more governance or endorsements on behalf of the OSSF. Like the CVD guide, how do we ensure we have that working consensus? Everything in OSSF is moving quickly, are things we think we have consensus, but it’s not clear. Need to codify how we’re validating for consensus.
    • Jason and Vicky will try to draft something about consensus – will open a PR
    • Two areas to consider
      • How do projects/endorsements within the WG happen?
      • How do artifacts of this WG get the “official” OSSF stamp?

Next project: CVD guidance for sec researchers - Target release - BH USA Aug 2022?

  • Sec Researcher pain points - https://docs.google.com/document/d/1iJV1_gICvu3OnVcYJHL5uTN9RdcLZMp3NqIAs5hAaT8/edit
  • OSS Maintainer pain points - https://docs.google.com/document/d/1fZlo2K0yhRpY7shOKmIXk6gHsuWPbMtFpWRIqp4oqiI/edit
  • DRAFT CVD Guide for Sec Researchers to engage OSS - https://docs.google.com/document/d/1u3NqbFr0o7PkWeyjIvWB-M16S4E1ZQSbMRTHiMzbVUA/edit#heading=h.vjrcdvqsajwp
  • [email protected] to send an update to the mailing list on this document :) Where’s it at and where does it need to go next?
  • Jonathan sent Crob a doc with his experience as a researcher working on OSS
  • Jonathan: Why does this WG not have more security researchers in it?
  • Jason: Researchers go where there are bounties
  • Anne: Mostly have maintainers/vuln teams
  • Jonathan: Snyk has a security research lab
  • Madison: Researchers don’t join industry groups typically
  • Anne: Consider what we’re asking of researchers, scope the request, go to them
  • Adam (huntr.dev) happy to do outreach
  • Crystal (hackerone) happy to do the same
  • Vicky: [re the ask] give input on the document we’re creating
  • Jonathan: Huawa at GitHub is doing this kind of work as well
  • Jonathan: Katie Moussouris would be good to approach as swell
  • Madison, Jonathan, Crystal, Kayla volunteer to review & edit the document
  • Claim a section, please!
    • If you’ve claimed a section, no need to use suggest mode for it
    • If you’re editing in a section you haven’t claimed, please use suggest mode
  • Jonathan: Will need to include mention of companies and company names
  • Publishing via certain companies has complications
  • Crystal: in favour of being vendor-neutral in the document as much as possible
  • MZ: Agree we shouldn’t name names in an official document like this
  • Jonathan: CNAs are tied to companies, so choosing a CNA naturally refers to a company, so will be tricky to avoid mentioning companies
  • VMB: Remember, we have a deadline for this document: Black Hat in August
  • Jonathan: …uh, the CFP is closed?
  • VMB: Hmm! Maybe someone’s already proposed?
    • VMB will send email to the list asking for more information
  • No opens to discuss today

20220404

Attendees: (Change colour or add your entry)

  • Eric Hatleback (CERT/CC)
  • Paulo Flabiano Smorigo (Ubuntu/Canonical)
  • Jeffrey Borek (IBM)
  • VM (Vicky) Brasseur (Wipro)
  • Lorenzo De Carli (WPI)
  • Jonathan Leitschuh (Dan Kaminsky Fellowship - HUMAN)
  • Abigail Davidow (University of Kansas)
  • Thomas Steenbergen (SPDX)
  • Yotam Perkal (Rezilion)
  • Kayla Underkoffler (HackerOne)
  • Nathan Menhorn (AMD)
  • Eric Tice (Wipro)
  • Tom Bedford (Bloomberg)
  • Madison Oliver (GitHub)
  • Jennifer Mitchell (Tidelift)

Meeting Agenda

Meeting Notes:

  • CRob promises exciting news
  • Deferring charter conversation for now
    • Please comment on the issue! #106
  • Meeting time change!
    • 11:00-12:00 EDT, every other Wednesday
    • Can schedule an APAC call if needed
  • Quick note - LF’s Summer Security Conference has extended CFP for the Vuln Coordination track
  • SPDX Defects, courtesy of Thomas Steenbergen
    • Quick overview of SPDX (came out of license compliance world)
    • Current version of SPDX is v2.2: doesn’t officially include vulnerability references
      • V2.3 will include this
        • MVP for communicating security info
        • Patch that will enable more use cases while v3.0 spec is in flight
      • V3.0 will include a LOT more, including profiles and disclosures for each profile
        • Will be a specific Vulnerabilities Profile (also License, Provenance, others)
    • Overview of the direction of the v2.3 work
    • Agendas and notes for SPDX Defects meetings
    • CRob: How do you see this interact with VEX?
      • TS: If you can link to a disclosure doc, could also link to a vex doc (or CSAF or whatever)
      • V3.0 may formalize this more, but v2.3+ will simply be a link
    • CRob: Could you talk a bit about the adoption of SPDX in general?
      • TS: Automotive (his previous employer), SPDX was the default
      • VMB: Adoption is growing, esp. since ISO announcement & EO
        • RH doing it for Fedora, for instance
    • JBorek: How about CycloneDX?
      • TS: All standards support their use cases well
      • Tools will probably need to support all the standards
        • Example: ORT supports SPDX and CycloneDX
    • CRob: What can this WG do to help (adoption, awareness, etc)?
      • TS: Biggest challenge is to help with the v3.0 spec
        • Have tons of vendors at the table but very few from FOSS community
        • This work happens in the SPDX Tech meetings and mailing list

Next project: CVD guidance for sec researchers - Target release - BH USA Aug 2022?

20220321

Attendees: (Change colour or add your entry)

  • CRob (Intel)
  • Eric Tice (WIpro)
  • Eric Hatleback (CERT/CC)
  • Jennifer Fernick (NCC Group)
  • Aeva Black (Microsoft)
  • Jeffrey Borek (IBM)
  • VM (Vicky) Brasseur (Wipro)
  • Jonathan Leitschuh (Dan Kaminsky Fellowship - HUMAN)
  • Olivia Gallucci (RIT Student)
  • Nathan Menhorn (AMD)
  • Shelby Cunningham (GitHub)’’
  • Lorenzo De Carli (WPI)
  • Jason Keirstead (IBM)
  • Abigail Davidow (University of Kansas)
  • Nico Marguet (Wind River)
  • Christine Abernathy (F5)
  • Kayla Underkoffler (HackerOne)

Meeting Agenda

  • New Friends intros
  • Opens
    • VMB: SPDX Defects update (very short)
  • Who wants to help out and scribe for us today? (VMB volunteered)
  • [AR] WG Charter review
  • [AR] Meeting time?
    • Several requests to change; do we all desire a different time?
    • Earlier or later in the day preference?
  • Next project: CVDguidance for sec researchers
  • Project - understanding impact of aggressive vulns reports (Lorenzo)

Meeting Notes:

  • New friends
    • Shelby Cunningham from GitHub (welcome!)
    • Lorenzo De Carli (Prof at Worcester Polytechnic Institute)
    • Christine Abernathy (F5)
    • Olivia Gallucci (RIT)
  • Business matters
    • Crob “gets” to review TAC issue backlog, including WG charters
    • Move the meeting time?
      • Some folks are finding this time difficult to make
        • Esp. folks in APAC & EU
      • On the table:
        • Changing time
        • Alternating times
        • Have multiple meetings (cover different time zones)
      • CRob will email & post in Slack to let folks know
  • Opens
    • VMB: Still working on getting SPDX Defects to come talk to us
  • Lorenzo: Impact of aggressive vulnerability reports (if interested, feel free to reach out to Lorenzo: [email protected])
    • Sometimes reports are made in less than knowledgeable or respectful ways
      • Aggressiveness in language or behavior
    • Trying to understand the extent of aggressive reports & the impact they have on the receiving end of the reports
    • Have the start of a list of these behaviors
      • Unreasonable timelines
      • Extortion (pay me or I release this)
      • Etc.
    • Would love folks on this WG to give feedback
      • Can also be a part of the data set of the report (anonymous)
    • End goal: help create better guidelines
    • Feedback/questions from the group
      • JFernick: Likes the study in context of FOSS is that we could create some sort of norms for software overall
        • Would like a sort of de facto standard of what’s included in a bug report, for instance
        • Higher informational bar may help
        • Anecdata: bug bounties may be leading to lower quality bug reports
        • So this WG could do a lot for norm setting and this could be part of it: what is & isn’t acceptable
      • KUnderkoffler (from HackerOne): Only interested in speaking to FOSS projects?
        • Lorenzo: Happens outside of FOSS as well, & interested in speaking with them as well
        • KU: Would love to connect you with folks at HackerOne
        • KU: Looking at researcher side as well or receiver only?
          • Lorenzo: Receiver mostly for now
          • Reports are public so can already do sentiment analysis
          • Harder to get info about impact on receivers & their orgs (burnout, etc)
    • CRob: As a group have talked about this in the recent past
      • Next project is to set some norms for researchers
      • Which leads us right into…
  • CVD Guide for Finders (our next project)
    • https://docs.google.com/document/d/1u3NqbFr0o7PkWeyjIvWB-M16S4E1ZQSbMRTHiMzbVUA/edit#heading=h.vjrcdvqsajwp
      • Copy & super duper drafty
    • Today: brainstorm on sections or strawperson of what we’d like to talk about
    • Any thoughts of topics we should or shouldn’t cover in the guide?
      • JLeitschuh:How to get a CVE number (even in face of potential conflict with the maintainer)
        • CVE appeals process
        • Easy CNAs
        • Pitfalls of different CNA
        • Etc
        • Happy to brain-dump to someone who can write it up
      • CRob: pain points of different personas
        • Developer
        • Researcher/finder
      • KUnderkoffler: High level overview of “what is open source”
        • May seem redundant but good to be clear
        • Also good to reinforce that this is volunteer, community (drive empathy)
      • JFernick: What types of things to include in the initial bug report
        • Standard things to recommend including (systems, versions, impact on system, do you have a proof of concept, etc)
      • JFernick: Could also consider including suggestions on when to release exploits
        • Can really help people to have more guidance about what to consider on there
      • JLeitschuh: Wish he’d known when he started that you should write your disclosure for the public
        • So you don’t have to write it twice
        • Also, public gets the same info the maintainer does
      • JLeitschuh: Disclosure timelines
        • Standards & norms for these things
      • JFernick: Not just timelines, but also tips for getting patches written
        • Incentivising or encouraging creation of a patch by a maintainer
        • For instance, her last resort has been offering to have a short call & this has been very effective to help get patches
      • JKeirstead: Should we be targeting all the personas at https://github.com/ossf/wg-vulnerability-disclosures/blob/main/docs/personas.md ?
        • Yup, this is informing the project
      • NMenhorn: Guidance on how to recreate the attack, How to avoid sensationalization
        • These can be time wasters for the company
        • Also are super valuable for the maintainers
      • JFernick: Thinking about the problems that researchers face?
        • CRob, yes! Let’s look at the pain point guide
    • Reviewing the Pain Point Guide
    • Aeva: Sometimes when vulns are found they’re in lower-level dependencies
      • Guidance for that situation?
      • Dev needs to coordinate between others AND do it under embargo?
      • How do you approach that problem?
      • JLeitschuh: Helping them report to as close as the root cause as possible
    • NMenhorn: DB of people whom to contact for this?
      • JL: disclose.io exists; mostly for companies though
      • Maybe piggyback on that?
    • KU: Calling out the difference between a bug bounty & a vuln disclosure
      • Disclosure doesn’t equate to payment in all cases
    • JF: Guidance around validating the correctness of to whom you’re reporting
      • Don’t divulge info to ne’er do wells
    • JL: Pitfalls of unintentionally agreeing to an NDA when you disclose
      • For instance, HackerOne usually includes an NDA, which is a problem if you’re reporting for open source
      • Has experience here, happy to brain dump
    • Lorenzo: Already a doc for agreed upon goals or intended audience for this document?
      • New to this & trying to get a better sense of what’s going on
      • CRob: First time talking about it; need to do this: scope out audience
    • JKeirstead: Thing that gets circulated in the media isn’t the disclosure but the first article to get written
      • That’s often wrong or warped
      • So be as crystal clear as you can in the disclosure
      • Maybe put an example in the document
      • Point out that one audience for the disclosure is the media
    • KU: Would like to get some more feedback from her internal teams & this is really helpful to structure that
      • How should they contribute input for the doc after speaking w/their teams?
      • CRob: For other guide, created a repo w/issues & PRs against that; do again?
        • VMB: Big +1 to this; transparent & allows all to participate
        • No objections, so will proceed that way
    • CRob will take this feedback & incorporate it into the doc, come up w/an initial outline
      • Will send out to mailing list
      • Later may need LF help to create the repo
    • JLeitschuh had a long thread about this pitfall stuff about a year ago
      • Fill locate & share if possible
  • AOB?
    • Nope!
    • CRob will send a “barrage of emails” about stuff, so be on the lookout for those
  • Meeting adjourned. Y’all have a lovely fortnight!

Next project: CVD guidance for sec researchers - Target release - BH USA Aug 2022?

20220321

Attendees: (Change colour or add your entry)

Meeting Agenda

  • New Friends intros
  • Opens
  • Who wants to help out and scribe for us today?
  • Lorenzo De Carli from Worcester Polytechnic Institute to talk about their “research [on] aggressive and generally inappropriate bug report practices”
  • Next project: CVDguidance for sec researchers

Meeting Notes:

Next project: CVD guidance for sec researchers - Target release - BH USA Aug 2022?

20220307

Attendees: (Change colour or add your entry)

  • CRob (Intel)
  • Anne Bertucio (Google)
  • Eric Tice (Wipro)
  • VM (Vicky) Brasseur (Wipro)
  • Paulo Flabiano Smorigo (Ubuntu/Canonical
  • Jeffrey Borek (IBM)
  • Jonathan Leitschuh (Dan Kaminsky Fellowship - HUMAN)
  • Madison Oliver (GitHub)
  • Aeva Black (Microsoft) [they/them]
  • Jamie Magee (Microsoft)
  • Jory Burson (Linux Foundation)
  • Oliver Chang (Google)
  • Nathan Menhorn
  • Kayla Underkoffler (HackerOne)
  • Yotam Perkal (Rezilion)

Meeting Agenda

Meeting Notes:

  • Suggestion for next project: guide for vulnerability disclosures for researcher
    • Will cover more after opens
    • [couple of folks having issues getting in touch with MITRE the last two quarters]
    • Crob: August/BlackHat reveal?
      • Discussion ensued. Seemed to get consensus on BlackHat reveal + panel. Good way to get out of our “echo chamber”, cross the dev<>research gap.
    • Homework:
      • What would we like to achieve with a CFP?
      • What would we like to achieve with a paper?
        • Volunteers to lead a section?
  • SPDX
    • VMB is working on scheduling with the head of the SPDX Defects team to have him give us info about how SPDX is thinking of handling vulnerability reporting in SPDX v2 & v3
  • OSV
    • Is both a schema (OSSF) and infrastructure (run by OSS team at Google) – “OSV is a bit over an overloaded term these days” :)
    • https://github.com/ossf/osv-schema
      • Designed to be human readable – json format – understand straight away what this vulnerability is about
      • Working with CVE 5.0
        • Will be adopting some of the version spec changes so CVE 5.0 and OSV are compatible
    • https://github.com/google/osv
      • An API and web UI where you can browse aggregated and indexed vulns in OSV format
        • Indexed by commit hash and package urls
      • Live at osv.dev
      • “Could this correlate CVE to file hashes, rather than commit hashes?” Yes, I think this can we just don’t have any source of data right now that would give us that information
    • Future work
      • Missing things for Linux distros, Debian
      • Anyone who uses their own format or feed (eg Kubernetes), would prefer to have one format for OSS
      • Is a missing piece in tooling so it’s more like a scanner
        • SBOM → scanner → match vulnerabilities in OSV ecosystem
        • Integration with existing scanners/tools
      • Longer term goal is figuring out what kind of metadata can be in the schema to avoid false positives
    • Q&A
      • Crob: where are you in approaching large distros/suppliers?
        • Some folks involved in Debian have reached out to OSV, haven’t made much progress, but interest – would like to have Debian as a first example of Linux distro that publishes in this format
        • Crob: Red Hat has their own data API, SUSE does → many Debian cats to herd
      • Vicky: What are the other potential options for this functionality? Are there other projects that already do this, how is this different or better?
        • I don’t think there are any completely free open source alternative in terms of infrastructure or format
        • Vicky: Seems like having both a schema and infra – there are other schemas for vulnerability disclosure – why do another schema?
        • Oliver: Yes other standards like CSAF and CVRF, but couldn't find one that’s suitable for open source – easy for both humans and machines to use. Being able to just read and see what it is, but also precise enough to describe vulnerabilities in OSS. Every [project] has their own format – Rust, GHSA, GSD, GitLab – there was a need for someone to define a new format that fit the needs of all of these.
      • Jonathan: Have you spoken with Snyk? Any work with Snyk to try and get the Snyk data in the OSV format so their information is available freely?
        • Have talked
        • OSV’s goal is to make this information freely available
      • Aeva: There are multiple commercial entities providing this data, has any outreach or coordination been done? Will this be perceived as trying to directly compete, or will it not compete?
        • I think it’s beneficial to these commercial solutions as well – OSS ecosystems can more easily share this information – could also improve the commercial ecosystems with standardized data. Haven’t made much progress yet – perceived as a competitor.
        • Aeva: Distinguishing between the schema and the infra might help there. Could find very willing allies for the schema, will probably not find as much collaboration for the infra.
      • Vicky: I would love to see more examples of OSV in the field. How it’s working, how it’s integrated with all these things – what sort of difference is it making now and in the future? This is understandably very high level a the moment – if we go further I would appreciate a deeper dive.
        • If you look at the schema on github. It has links to examples of adoptions of the schema. Because the format is machine and human readable
      • Crob: Kernel and Apache would be good to approach
        • Kernel works with GSD – from Cloud Security Alliance – some kernel maintainers have a direct relationship with GSD – is at a granularity that CVE doesn’t have
        • OSV infra will query by commit –
      • Anne: what is hte relationship between SPDX and OSV?
        • Haven’t talked to SPDX too much – Russ Cox originally reached out – but agree should be aligned in how we describe vulnerajbilities – we’re probably trying to address different use cases, but it would be good to talk more
        • Vicky: There is an SPDX Defects call Wednesday – that’s the group that will have these conversations
    • Crob: If OSV is interested in more formally engaging with OpenSSF, that is done through the TAC. Aeva is codifying what the process is. That’s another path you might want to explore.
      • Yes please, let me know next steps.
      • Aeva: Please don’t expect anything immediately, we’re discussing how to more thoughtfully discuss and design that process moving forward.
      • Crob: TAC meets 11am ET Tuesdays
      • Oliver can find someone, that’s 3am Sydney time :)
  • Story time
    • JL has some open issues with CVE
      • Includes one to Google, being a slow CNA
      • To get all the infrastructure kicked off, you really need to get a CVE number
      • To alleviate problems, JL is applying to become a CNA
      • Crob: A lot of people are talking about that topic right now – OSS people don’t talk about it as much, but vendors
        • FIRST
        • Could be a good conversation between FIRST, MITRE and your perspective

20220221

Attendees: (Change colour or add your entry)

Meeting Agenda

  • New Friends intros
  • Opens
  • Who wants to help out and scribe for us today?
  • Townhall 23Feb - what activities do we want to highlight? What projects do we want to focus on for 2022?
    • Proposed updates to TAC and for townhall
      • oss cvd guide - https://github.com/ossf/oss-vulnerability-guide
      • FOSS Backstage panel
      • Future project - maintainer survey - how can we assist them?
      • Next project guidance for sec researchers
      • Collab with omega on handling cvd
      • Vuln report formats discussions
      • Ongoing talks with CERT/CC - Carnegie Melon re: open sourcing VINCE tool
      • Ongoing talks with the CVE Board about opportunities to improve processes for OSS maintainers, projects, and researchers

Meeting Notes:

20220207

Attendees: (Change colour or add your entry)

  • CRob (Intel)
  • Anne Bertucio (Google)
  • Michael Scovetta (Microsoft)
  • Arnaud J Le Hors (IBM)
  • Jonathan Leitschuh (Dan Kaminsky Fellowship - HUMAN)
  • Madison Oliver (GitHub)
  • VM Brasseur (Wipro)
  • Yotam Perkal (Rezilion)
  • Nico Marguet (Wind River)
  • Kayla Underkoffler (HackerOne)
  • Kate Catlin (GitHub)
  • Aeva Black (Microsoft)

Meeting Agenda

  • New Friends intros
  • Opens
    • Annebertucio: ideas of getting maintainer feedback on priorities?
      • ~~Surveys → survey fatigue ~~
      • Alpha Omega is just getting started
      • “Super scientific social outreach” (biases towards own networks, but may give some signals)
      • Direct outreach to projects/search for past list conversations
      • Crob will email David about projects that they made connections with MFA project
    • Scovetta: How should Omega handle vulnerability disclosure (medium-term approach) – e.g. maybe the CVD guide for finders? Tooling-support?
      • Michaelscovetta: Pain with disclosure for Omega
      • Annebertucio: Tell us more about your pain! Is it projects that don’t have disclosure policies? Unresponsive projects?
      • Scovetta: How to find maintainers, scale, don’t wnat to automate everything
      • Aeva’s gas pedal metaphor
      • Annebertucio: Should go back to mission of OSSF → improving security of OSS projects → not just acting as individual security researchers or mission is just security research. If Omega encounters a project that doesn’t have a disclosure policy, the next step should be to work with the project to learn about disclosure and set up a policy (ie off the gas). If a project is unresponsive, that package is not maintained. Mission of OSSF is to address things like that → should it be forked and maintained in parallel? Focus should shift to what to do about critical unmaintained package.
      • VMB: “account manager” model - single person who can manage processes for multiple (but limited number for each account) projects; individual processes easier to manage that way; can also manage our throughput by prioritising projects and managing as many as we have people to support
      • Google Project Zero FAQ: https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html
    • Jonathan Leitschuh: Inverting the disclosure process with GHSA
      https://github.com/JLLeitschuh/security-research/blob/main/README.md
    • Kate: Let’s talk about OSV vs. other vulnerability data formatting! Are your teams prioritizing either?
      • SPDX I hear is thinking of their own vulnerability format?
      • Vicky: Participates in SPDX, but not on ‘technical’ where the spec covos are happening
        • They are considering a format.
        • Not sure how far down the list this is on V3
        • But right now if you need to choose vuln formatting go with what we have, OSV
      • Yotam: We are using OSV at Rezilion
        • But is not that familiar with SPDX, will take a look
        • Creating a DB with many sources, including NVD.
        • There’s also a project starting with Cloud Security Alliance called GSDB. Aim of project is to eliminate the gatekeepers! Everyone who thinks something is wrong… fixing that. They ARE ALSO using OSV as the format.
      • Rob mentions that within industry they back the CSAF format
      • Jonathan: I’m not familiar with all these formats. Are they all based in CVE as the underlying identifier?
        • Rob: Most if not all will touch on CVE. At least in US/Europe, CVE is the common language although there are different formats. But some nations use a different format/organization.
        • Yotam: GSDB has a namespace, so even a proprietary scanner can add it’s take on a vuln. So you have all the data of the vuln from various places in one place. So if you have an OSV format,

Meeting Notes:

  • Future call - review available options for Vuln reporting
    • OSV (annebertucio can contact team)
    • SPDX (VMB to contact SPDX)
    • CSAF

20220124

Attendees: (Change colour or add your entry)

Meeting Agenda

  • New Friends intros
  • Opens

Meeting Notes:

  • Discussion with Adam of huntr.dev - https://huntr.dev
    • Huntr.dev runs a bug bounty program to provide incentives to the sec research community & maintainers by getting commercial/enterprise users to provide funding
    • Many oss maintainers are not monetizing their code.
    • Works with enterprise users to sponsor security researchers
    • They dedicate portion of funds to the maintainer
    • Have had a “rough history to date”, but are iterating and improving
    • Based in London (thanks for joining us so late today!)
    • There are a few vendors in this space, doing generally similar services
    • [Morten] - are they a CNA? [Adam]- Yes! They are!
      • Everything is confirmed by maintainers, they are not adding additional assurances on top of what is produced
    • [Anne] how do maintainers get access to vuln info? And …….
      • [adam] 3 scenarios - dev is already on platform, if not on platform - 1.) reach out to security contact (security.md, etc) & provide link to access report 2.) if no sec policy - they open an issue w/out details and ask maintainer to contact them for more deets
    • [Jonathan] - looking at vulns across many repos (1000s). As a researcher, the platform sounds interesting. Can researcher set their own disclosure policy? How does that play out?
      • [adam] they follow a standard disc.policy, if project does not have one, they use their template to start. Desire to list reports that are in/out of scope for participants in the platform
      • Trying to hone in on the end-users of the software to do best by them
    • [anne] - how are developers reacting to the program? Can they opt-ion/out?
      • [adam] working with ~2000 maintainers to date, overwhelming positive experiences so far, but as with anything on the internet, there are negative comments as well.
      • [adam] - Anyone that is writing code in the open already opting-in to have their code reviewed/criticized by the public
    • [anne] BB is different from VDP - do you have a sense of how this project is operating? How is the signal-to-noise ration of reports?
      • [adam] - roughly 60% tend to be a positive validation
    • [crob] - how connected are you to existing cvd communities/entities e.g. - oss-sec list, distros list, etc? Are you connected to CERT-CC’s VINCE platform?
      • [adam] - not connected at this time
    • [morten] - some cve’s have not been disclosed and/or some reports do not cross security boundaries - (sometimes the program just failing). CNAs are obliged to provide some level of assurance prior to issuing ID. some of these reports may just be creating noise.
      • [adam] - they are aware, and checking internally if they need to disincentivizing certain behaviours. [crob] - if multiple offerings are impacted by the same cve (or are not affected, they are entitled to issue their own score/statement that will be collected along with cve materials
      • [kate @github] - they also almost always issue cve if requested
    • [anne] - who owns the report? What are the terms about “shopping the vuln”
      • [adam] - covered under legal Ts and Cs for specifics
      • Platform does not want to explicitly own the report
    • [jonathan] - what is the best way to share a lot of vulns across lots of projects? Is it better to disclose, fix but not disclose cuz coordination is hard? Seeking advice on good practices. - how does huntr.dev handle situations like that
      • [adam] they side with the maintainer on the validation/refusal of reports. They also have an api that can handle large volume of reports
    • [jonathan] is there risk of ejection from the platform for researchers if there is disagreement about a report
      • [adam] - they default to public for reports ← if report is invalid, if report is pending, held in confidence/private and bar future disclosures on the issue until resolved
    • [crob] - There is a Bug Bounty Community of Interest group you may want to check out/participate in
    • [Crystal - H1] - OSS program - https://www.hackerone.com/company/open-source-community
    • [adam] only started talking with Enterprises this quarter (just starting their journey)
      • Eager for feedback on how they can better us their resources, engage with the community, and assist enterprise devs using OSS
      • Willing to come back if there are follow-up requests
      • Shout out to IBB https://hackerone.com/ibb
  • Some folks have had an issue with the meeting invite. @CROB to talk with Jenn to ensure we’ve got the right data attached to the community invite

20220110

Attendees: (Change colour or add your entry)

Meeting Agenda

  • Welcome to 2022 - **the **most important year for OSS developer security!
  • Welcome new friends to WG
    • Kate Catlin (GitHub Security Advisories) - new to GitHub, was at CircleCI, DevOps background
    • Nico Marguet
  • 2022 Security Conference Calendar
  • Opens
  • TAC Elections *
  • What do we want to work on as a group in 2022?
    • Annebertucio: maintainer survey? (conversation roll over from 2021)
    • Easing pain points between devs & sec researchers
    • Bug Bounties - guidance for projects on how to be able to interact with or keep up with BBs
    • Standardized disclosure template (when/when not to share PoCs)
    • “Messaging framework” for this WG to have consistency around valued issues (reporter’s rights, maintainer autonomy, etc) as we do advocacy, press response, etc

Meeting Notes:

  • Proposal: Fridays are a bad day to announce things :-). Based on log4j. Prefer MTW. Add something to guide?
  • Bigger new project was discussed: Guidance for security researchers (instead of projects) - don’t extort, etc.
    • The larger document included personas, & discussed this.
    • Where possible, don’t reinvent the wheel. Perhaps just point to existing material & note a few additions.
    • Not all projects have bug-bounties, and sometimes people create bug bounties without coordinating with project. Scope is critical for bug bounties.
    • Bug bounties are terrible as a “first step” - need to first fix the “easy problems” before enabling bug bounties.
    • Beware bug bounties from organizations that aren’t connected with the projects, they may be paying for 0-days & turn around to exploit users, which has many ethical concerns. Bug bounty orgs may impose conditions that OSS projects may reject. Bug bounty project needs to work with project to determine if it’s a real problem & if it is, fix it.
    • Bug Bounty community of interest (COI) - https://bugbountycoi.org/
    • Some bug bounty programs’ terms of service can be perceived as onerous - may disincentivize participation
    • Report template? CRob can track one down.
  • Survey of developers to make sure that we’re addressing real needs?