2020-03-23.md

March 23, 2020

Attendees

• Alex Mullans (GitHub)
• Nico Waisman (GitHub)
• Eva Sarafianou (Auth0)
• Crystal Hazen (HackerOne)
• Eric Brewer (Google)
• Hauwa Otori (GitHub)
• Lindsey Glovin (Uber)
• Sherif Mansour (OWASP)
• Martijn Russchen (HackerOne)
• Ben Willis (HackerOne)

Agenda

• Review existing vulnerability disclosure formats (maintainer -> world)
  • Python
  • NodeJS samples

    • core:

      https://github.com/nodejs/security-wg/blob/master/vuln/core/65.json
      https://github.com/nodejs/security-wg/blob/master/vuln/core/55.json

    • npm: https://github.com/nodejs/security-wg/blob/master/vuln/npm/100.json

  • GitHub
  • Google
  • CVE Automation Working Group Schema
• Review existing vulnerability report formats (researcher -> maintainer)
  • HackerOne:
    • POST (Create) Vulnerability Report: https://api.hackerone.com/core-resources/#reports-create-report
      (existing format, uses some HackerOne-specific terminology today)
    • GET (Read) Vulnerability Report: https://api.hackerone.com/reference/#report
  • GitHub: at the outset, our private vulnerability reports will have the same set of metadata as our Security Advisories
  • OWASP cheat sheet
• Create lists of the metadata we think all:
  • All disclosures and reports should share
  • All disclosures should share
  • All reports should share
• Create agenda for next meeting
  • Finishing the table 👇🏻 (start at remediation section)
  • Am I actually vulnerable?
• Future meetings
  • How do you update a report, and how can I trust your update? - is Git a model here?

Notes

We spent the entirety of the meeting reviewing all of the various disclosure/report forms listed in the ☝️ agenda and combining them into the following list of metadata.

Outcomes

• We agreed that we would put our weight behind the **Package URL (PURL) **spec as a standard way to refer to a package ecosystem, host, name, and version. In the coming weeks, all of us that own vulnerability reports or disclosures will need to assess how best to do so.

Table column descriptions

• The disclosure and report columns are checked if we thought the metadata was appropriate for a vulnerability disclosure (maintainer -> world) and/or a vulnerability report (researcher -> maintainer), respectively.
• The auto? column indicates that a column should/shouldn’t be usable by automation.

Table

Remains in Google Docs: https://docs.google.com/document/d/1w_I7Uf0Vy9o_PjF9KnhVZzEdust0S3yLU0WLFkEYjcc/edit#