Skip to content

Latest commit

 

History

History
70 lines (60 loc) · 5.51 KB

2020-02-26.md

File metadata and controls

70 lines (60 loc) · 5.51 KB
Raw

Vulnerability Disclosure WG

Working Group Members

Notes

  • **Objective: **(researcher <3 maintainer) Make open source vulnerability reporting a ubiquitous process (every security researcher knows how to use and every maintainer knows how to accept).

    • KR: n% of “active” projects have a SECURITY.md (or appropriately-formatted equivalent) that points to a vulnerability reporting process that doesn’t rely on email/Twitter/informal connections.
    • KR: n% of “active” projects that have received a vulnerability report have responded in 7 days.
    • KR: There is a vendor-agnostic process for security policies (SECURITY.md) and vulnerability reporting (TBD).
      • Initiative: Define shared set of metadata that a vulnerability report contains (as the precursor to an API)

  • **Objective: **(maintainer <3 users/world) Enable coordinated disclosure and make the time gap between remediation as small as possible.

    • KR: Existing release channels (e.g. new package notifications) can communicate the security status of the release (does this contain a fix?)
    • KR: A feed exists that can answer the question “what are all of the packages with security fixes?”
      • Initiative: Develop a shared format that can connect a vulnerability report (e.g. a line item in NVD, a HackerOne private report, etc.) to a package to the commit/changelist that fixed the vulnerability.
    • KR: A researcher discovering a new widespread vulnerability can write a CodeQL query and bring it to the standard query set.

  • **Objective: **(world <3 maintainer) Create a transparent and objective security score for projects

    • Component: What is your average response time to reports? Average time to fix? Is there a priority/important customer pre-release time?
    • Component: Do they use a disclosure process that enables coordinated disclosure? (see previous objective)
    • Component: Do you have a security policy and contacts (other metadata?)?
    • Component: Do you have a Safe harbor language included in your security policy?
    • Note: similar to Best Practices and Security Tooling WG - let’s collaborate!

  • **Objective: **Prevent known types of vulnerabilities from ever being introduced

    • KRs: Researchers have a pathway to bring CodeQL queries into the standard query set that can be run on all open source code.
      • Initiative: Promote integration in GitHub CI or CL

  • Is there anything else to address?

    • There’s a dichotomy between security-aware and non-security-aware projects. Something used in the power grid should be considered, someone’s home server shouldn’t be. Need to consider this in KR metrics/goal setting.

  • Who is your group leader?

    • Marcin & Alex

  • When will this working group meet next? Please aim for dates within the next week.

    • Monday, March 9, 9 a.m. Pacific

  • Raw notes

    • What’s wrong today:
      • Way too manual. Too many vulns to handle in the pipeline, so they’re not reported. Automation is a huge need.
      • Mapping vulnerability to CLs and versions that include those CLs.
      • In other words, mapping from binary -> (package) -> source code.
      • Knowing where the vulnerability is fixed.
      • Marcin: (NodeJS) serving as an intermediary between a security researcher and npm community
      • Challenging to know that an issue is fixed and disclosed.
      • HackerOne is the primary workflow tool in this area today, also GitHub as most projects are hosted there. But independent package managers operate outside of that workflow (Email and Twitter are the fallbacks but are time-intensive)
        • E.g., even trying to report a vulnerability in jQuery (huge project) means chasing individuals
      • Problem: clear ownership.
      • Problem: clear notification mechanisms.
      • NodeJS: Disclosed on H1, but time delay between disclosing on H1 and then security tools scraping for notifying end users (GitHub security alerts, Snyk, etc)
        • Could we produce vulnerability information in a standard feed format
        • Alex Mullans: NVD is our fallback for standard feed format, but clearly not designed with open source in mind
        • What is the canonical way to reference a package?
          • SBOM
          • OWASP initiatives?
    • Discuss: one canonical form for all package managers?
      • Maybe not, but can we have some boundaries.
      • e.g. can we express version ranges as sets
      • Most package managers don’t give us an ordering of versions - can they write the rules? What is the resolution protocol?
      • Can we push for SemVer as a default version expression and ordering system?
      • Streamline vuln disclosure