- Marcin Hoppe (Auth0 / Node.js Ecosystem Security WG)
- Eva Sarafianou (Auth0 / Node.js Ecosystem Security WG)
- Jason Keirstead (IBM Security)
- Josh Bressers (Elastic)
- Reed Loden (HackerOne)
- Matthew Dressman (Microsoft)
- Eduardo Barretto (Ubuntu/Canonical)
- Morten Linderud (Arch Linux)
- Paulo Flabiano Smorigo (Ubuntu/Canonical)
- Rhys Arkins (WhiteSource)
- Martin Prpic (Red Hat)
- Matt Wilson (GitLab)
- Josh Dembling (Intel)
- Welcome new members
- Working group governance topics
- New WG meeting time (#63)
- Doodle: https://doodle.com/poll/xapiz275mqsuwkrf
- OSS security pain points for:
- Maintainers
- Consumers
- Security researchers
- Motivation behind new security advisory schema standard in this repo (#53)
YouTube recording: https://www.youtube.com/watch?v=aFFyQIoiis8
- Welcome new members
- Rhys Arkins
- Martin Prpic
- Working group governance topics:
- New WG meeting time:
- Result: will time box doodle results to end of this week
- Interest in alternating timeslots to best accommodate for all who have competing standing meetings.
- Will look to invite the working group members to the community calendar invitations so the time is blocked out for members
- New WG meeting time:
- OSS security pain points for:
- Maintainers - Upstream maintainers(?) - Once they understand security is important, how do they start? (note GitHub has a policy generator available) - Could we offer information so that people can then leverage resources we know about and they don’t (i.e. embargo’d distribution list). Provide information such as - Who do you reach out to? How does an embargo work? Etc. - The largest group (larger than the security researchers) of people who would be consumers of our work. Ranges in scale from small to large (companies built on OSS) - Many problems the researchers experience could be mitigated by education and resources being provided to the maintainers. - We could help by explaining each step / process that is needed as a OSS project that should be considered (a framework) - We should solve for mission critical projects with one maintainer that is not going to have this as a top priority to implement - how do we ease the burden to the maximum extent possible. How to help them avoid the intricacies if they want. [is this more an incentives and maintainability discussion?] - If we focus on solving how do we help the ecosystem to set themselves up in a way they can handle security reports - but this could change scope - Could we take maturity into consideration when we reference resources? Note what items you will need to do differently if you don’t have a system in place or it’s manual. - We could try to assume that the person looking at these resources are interested in handling the vulnerabilities instead of getting people interested - that could be a later thing if needed (to get them interested) once we solve for the first - Helping the broader group do the minimum good practices - more than having them do a perfect flow - would be a good goal to start. Helping automation would help larger (more mature) projects and likely not help smaller ones. We could instead start on those that have nothing (how do you accept a report? How do you keep it private until it’s ready) - Discussion to have - if we address the concern of maintainers who are interested but do not have resources today - how do we get them things? What do we want them to have? Make it readable to humans but also available for software consumption.
- Consumers
- Downstream consumers. Both vendors who consume open source, as well as consumers & enterprises who consume products, that consume open source
- Facilitating CVEs and that process more efficient for everyone
- Nothing to reinvent or redesign, but making the current system easier to consume for them
- Around SBoM and having an inventory of the downstream libraries and understanding the other libraries that come with it (i.e. dependency tree). SBoM is going to be needed for the downstream consumer (not the vendors) to know the CVE impact
- Enabling - standardize recommended data formats - figure out which data formats do we want to recommend as standards and push forward. This is a large hurdle in consuming disclosures.
- Many OSS projects may not understand they are producing something other people are consuming. Perhaps teaching people others are interested in this in a machine readable format. [teaching maintainers point]
- Security researchers
- When vendors don’t have a bug bounty program, hard for security researchers to know how to report, what information vendor might need. Can feel like a black box if there’s just an email address and a PGP key.
- Opaque disclosure process from disclosure to CVE assignment
- HackerOne: Provides templates and processes for their customers. The platform itself offers time estimates (time to triage, time to payout) Communication is one of the most important things - settings and updating expectations is very important.
- OSS frameworks - PSIRT etc. Everyone should have a VDP (Vulnerability Disclosure Program)
- Many more mature products are capable and have a process to iterate on - but smaller groups may not know where to start.
- We (closed source) can hopefully take our learnings and help the OSS projects with their processes.
- Providers?
- These are people who don’t write the software but provide vulnerability disclosures (npm, cargo, github, Linux distributions etc)
- Upstream/Downstream notification? (due to SBoM) - the digital bill of materials group (linux foundation DBoM) deals with this
- We could make sure we are in synchronization with the standards in the industry (NTIA is one group…) We should keep up with what is out there and where the industry is going but avoid having that topic we focus on
- Motivation behind new security advisory schema standard in this repo (#53)
- Use case centered around workflow of HackerOne and GitHub
- There are a number of competing or complementary standards to accomplish the same goal - do we want to continue working on this schema? Or do we want to spend our time on other parts of the WG objectives.
- Do we want to reference existing standards and then promote one (or more) as the recommended (and used). We could then provide feedback to standards if we feel they are missing certain things / need feedback, but not do it ourselves. It sounds like yes.
- Educate OSS maintainers (if you are publishing an advisory here is how you do it so it’s in a standardized way)
- Identify standards that fit the bill and make sure they are easily used in OSS context. Even if the format itself is complex.
- And do we also work on some tools to make work with the formats easier if they don’t come with tooling themselves?
- Messages from Zoom chat:
- Eva: I need to drop earlier today but I’d like to suggest that we take the notes of the pain points of the different parties and polish them into a document in our GH repo. This will give a clear picture of the pain points we identify today. Based on this document we could discuss action items in the next meeting. I’m happy to turn the notes into the document.
- Jason: There is an SBom "Plugfest" happening this week actually, in conjunction with some other plugfests.. https://www.eventbrite.com/e/sbom-poc-openc2-plugfest-hackathon-tickets-124335150783 SBoM working group - https://www.ntia.doc.gov/SBOM
- Marcin: Doodle poll end of week update meeting time
- Marcin to kick off discussions about focus area after this meeting:
- List of standards and groups (we just fill in what we know)
- Crisp up - what do we want to solve (primary focus)
- Crisp up stakeholders & Pain Points