1 of 23

Discussion: OpenJS CNA

Adam ‘rudd’ Ruddermann�22 April 2024

2 of 23

Context: DESTF Workstream 2�Coordinated Vulnerability Disclosure (CVD)

2

CVD Program Guidance�for OpenJS Foundation Projects

CVD Runbooks and Templates�for OpenJS Foundation Projects

CVD Compliance Standards�for OpenJS Foundation Projects

  • Developing and maintaining:
    • Coordinated Vuln Disclosure Policy (CVDP)
    • Tooling for receipt and handling of vulnerabilities
    • Security Advisory/CVE framework in human-friendly and machine readable formats�
  • Establishing and routinely iterating:
    • Vulnerability Submission and Triage Processes
    • Fix Development and Verification Processes
    • 3rd Party Communications Processes

(DRAFT) Develop resources and provide direct support to OpenJS Foundation Projects to enable adoption of and consistent adherence to low friction, best practices-based processes for the handling and disclosure of security vulnerabilities.

  • Customizable Runbooks
    • Vulnerability Receipt and Handling
    • Triage, Root Cause, and Fix Development
    • Fix Release and Communications�
  • Customizable Templates
    • Coordinated Vuln Disclosure Policy (CVDP)
    • Finder (researcher) Communications
    • Security Advisories / CVEs
  • Incubating Projects
    • Minimal CVD Program requirements to graduate from Incubating Status�
  • At Large and Impact Projects
    • Ongoing Minimal and Recommend CVD Program requirements�
  • Emeritus Projects
    • Clearly defined boundaries and long-term expectations for security vulns and CVD

3 of 23

What is a CNA?

CVE Numbering Authority

What is a CVE?

Common Vulnerabilities and Exposures

Bigger Picture/Fine Print�The CVE Program was created in 1999 and is now funded and managed by the US Department of Homeland Security’s (DHS) Cybersecurity and Infrastructure Security Agency (CISA) via the Homeland Security Systems Engineering and Development Institute (HSSEDI), a US federally funded research and development center (FFRDC). HSSEDI is operated by The MITRE Corporation, a 501(c)3 non-profit. Since 2011, the UN International Telecommunication Union has recommended the use of CVEs share security vulnerability information and coordinate remediation.��The NVD Program, which (not without controversy) analyzes CVEs to provide an independently assessed CVSS Score and other data for CVEs, is also funded by CISA but created and administered by the US NIST Information Technology Lab.

A CVE ID is a unique record of a vulnerability in software that requires coordination between or notification of third parties to remediate.

  • CVEs provide a common ID for vulnerabilities to ease notification and coordination between third parties.
  • CVEs are not issued for vulnerabilities that a developer fixes without coordination (eg: a vuln in www.openjsf.org).

CNAs issue CVEs within their scope. This scope is delegated from the Top Level Root (TL-Root) / CNA of Last Resort (CNA-LR) operated by MITRE.

  • The CNA-LR (MITRE) issues the majority of CVE IDs as most software is not in the scope of a more specific CNA.
  • If no CNA exists, MITRE will issue a CVE for nearly any apparently-valid vulnerability reported to them by anyone rather than gatekeeping or rejecting potentially valid vulns.

4 of 23

Examples of Open Source Foundation CNAs

5 of 23

Examples of Open Source Project CNAs

6 of 23

How does it work?

CNAs provide MITRE with an estimate of how many CVEs they think they’ll issue in that CALENDAR YEAR.

MITRE reserves a block of that year’s CVE IDs and sends the list to the CNA

1

CNAs request CVE IDs each year

CVE IDs start with the year they’re issued. Example: CVE-2024-24691

2

MITRE returns a block of CVE IDs

These CVE IDs are initially marked as *RESERVED* Examples: CVE-2024-29203 / CVE List Search

3

CNAs issue CVE IDs from the list

The CVE API or Web Form can be used to Publish and Update CVE Records.

CNAs choose a CVE ID from their list and publish it by populating the ID’s Record.

7 of 23

Example Scenarios

7

8 of 23

But first: some definitions

Finder

  • Anyone who discovers a potential security vulnerability in a product.
  • In other words, anyone: tech muggles, researchers, contributors, and maintainers.

Project

  • Typically the maintainers or security team responsible for a Github Org.
  • Depending on Project structure, this could also be an individual Repo.

Root CNA

  • Simplified: An org that manages CNAs on behalf of MITRE’s Top Level Root.
  • Red Hat’s Root provides open source CNAs a more focused alternative to MITRE.

Example: Various Humans

9 of 23

Definitions

Finder

  • Anyone who discovers a potential security vulnerability in a product.
  • In other words, anyone: tech muggles, researchers, contributors, and maintainers.

Project

  • Typically the maintainers or security team responsible for a Github Org.
  • Depending on Project structure, this could also be an individual Repo.

Root CNA

  • Simplified: An org that manages CNAs on behalf of MITRE’s Top Level Root.
  • Red Hat’s Root provides open source CNAs a more focused alternative to MITRE.

10 of 23

Definitions

Finder

  • Anyone who discovers a potential security vulnerability in a product.
  • In other words, anyone: tech muggles, researchers, contributors, and maintainers.

Project

  • Typically the maintainers or security team responsible for a Github Org.
  • Depending on Project structure, this could also be an individual Repo.

Root CNA

  • Simplified: An org that manages CNAs on behalf of MITRE’s Top Level Root.
  • Red Hat’s Root provides open source CNAs a more focused alternative to MITRE.

https://www.cve.org/PartnerInformation/ListofPartners

Search “root” for the list of all 7 Roots

11 of 23

Scenario: A valid vulnerability in an actively maintained At Large/Impact Project

1) Finders may request a CVE directly from the MITRE CNA-LR using MITRE's CVE Form:

  • Unilaterally and at any time during the disclosure process without the Project’s knowledge.

2) Projects may request a CVE:�

1) Finders may only request a CVE directly from Project maintainers during the disclosure process.��2) Projects may issue a CVE from their OpenJS pre-assigned block or request a CVE:�

11

Without a CNA (current state)

With a CNA

12 of 23

Scenario: A valid bug an actively maintained At Large/Impact Project reasonably does not consider a vulnerability

1) Finders may request a CVE directly from the MITRE CNA-LR using MITRE's CVE Form:

  • Unilaterally and at any time without the Project’s knowledge or agreement.

2) Projects may file a dispute to reject the CVE with the MITRE CNA-LR using MITRE's CVE Form.�

3) MITRE will determine if there is *any* theoretical security impact and likely update the CVE record to:

  • Mark it as DISPUTED but not reject it
  • Update the CVE to include data provided by the Project but likely w/o changing the original CVE

�NOTE: MITRE will NOT reject the CVE unless there is demonstrable proof that it is a true false positive.�

1) Finders may only request a CVE directly from Project maintainers during the disclosure process.��2) Projects may reject the request based on its CVD Policy.�

3) Finders may appeal the Project’s rejection directly with the OpenJS CNA POC(s), who must:

  • Evaluate the appeal against its CNA CVD Policy
  • Provide a rationale for not issuing a CVE

4) Finders may appeal this rejection with OpenJS’ Root CNA (most likely the Red Hat Root CNA).

5) Red Hat must evaluate the appeal using its published process and MITRE's CNA Rules and either:�

  • Provide a rationale for rejecting the appeal
  • Direct OpenJS to issue a CVE and take corrective action against the OpenJS CNA

12

Without a CNA (current state)

With a CNA

13 of 23

Scenario: A valid vulnerability in a deprecated version of an actively maintained At Large/Impact Project

1) Finders may request a CVE directly from the MITRE CNA-LR using MITRE's CVE Form:

  • Unilaterally and at any time during the disclosure process without the Project’s knowledge.

2) Projects may request a CVE:�

1) Finders may only request a CVE directly from Project maintainers during the disclosure process.��2) Projects may issue a CVE from their OpenJS pre-assigned block or request a CVE:�

13

Without a CNA (current state)

With a CNA

14 of 23

Scenario: A valid vulnerability in an Emeritus Project

1) Finders may request a CVE directly from the MITRE CNA-LR using MITRE's CVE Form:

  • Unilaterally and at nearly any time without Project/Foundation knowledge.

2) Project may request a CVE:�

1) Finders may only request a CVE:

  • From the Project’s maintainers during disclosure
  • If unresponsive, directly from the OpenJS CNA

2) If responsive, Projects may issue a CVE from their OpenJS pre-assigned block or request a CVE:�

3) If Projects aren’t responsive, the OpenJS CNA POC(s) must:�

  • Evaluate the request against its CVD Policy
  • If found to be a likely valid vuln, issue a CVE

14

Without a CNA / OPTION 1: Emeritus Projects Removed from CNA Scope

OPTION 2: Emeritus Projects Kept in CNA Scope

15 of 23

Scenario: A valid vulnerability in an Incubating Project

1) Finders may request a CVE directly from the MITRE CNA-LR using MITRE's CVE Form:

  • Unilaterally and at any time without the Project’s knowledge or agreement.

2) Projects may file a dispute to reject the CVE with the MITRE CNA-LR using MITRE's CVE Form.�

3) MITRE will determine if there is *any* theoretical security impact and likely update the CVE record to:

  • Mark it as DISPUTED but not reject it
  • Update the CVE to include data provided by the Project but likely w/o changing the original CVE

�NOTE: MITRE will NOT reject the CVE unless there is demonstrable proof that it is a true false positive.�

1) Finders may only request a CVE directly from Project maintainers during the disclosure process.��2) Projects may issue a CVE from their OpenJS pre-assigned block or request a CVE:

15

Without a CNA / Option 1: Incubating Projects Never in OpenJS CNA Scope

Option 2: Incubating Projects added to CNA Scope individually upon meeting specified minimum process criteria

16 of 23

What would OpenJS need to become a CNA?

16

17 of 23

What would OpenJS need to become a CNA?

  • A public CVE list and machine readable OSVs for all in-scope OpenJS Projects��This work will be happening anyway on a per-Project level as part of Workstream 2. This work would be to aggregate Project-level data together.
  • An OpenJS Disclosure Policy and list linking to the individual Project Policies�
  • Two or more POCs to participate in MITRE’s required CNA training and initialization meetings�
  • An ongoing POC to issue CVEs and handle annual program administrivia

18 of 23

What would OpenJS need to become a CNA?

  • A public CVE list and machine readable OSVs for all in-scope OpenJS Projects
  • An OpenJS Disclosure Policy and list linking to the individual Project Policies��This work will be happening anyway on a per-Project level as part of Workstream 2. This would be a higher-level policy based on the consensus Minimal CVD Policy developed for individual Projects.
  • Two or more POCs to participate in MITRE’s required CNA training and initialization meetings�
  • An ongoing POC to issue CVEs and handle annual program administrivia

Example: Google’s CNA references individual programs’ respective rules/disclosure policies and vulnerability reporting workflows

19 of 23

What would OpenJS need to become a CNA?

  • A public CVE list and machine readable OSVs for all in-scope OpenJS Projects
  • An OpenJS Disclosure Policy and list linking to the individual Project Policies�
  • Two contacts to participate in MITRE’s CNA training (seen in image) and evaluation/initialization meeting��Training is ~1 hours of Youtube videos (screenshot) and participating in two practice exercises covering publication of a hypothetical CVE. A version of this training is to be given to maintainers/triagers during CVD Program development.
  • An ongoing POC to issue CVEs and handle annual program administrivia

20 of 23

What would OpenJS need to become a CNA?

  • A public CVE list and machine readable OSVs for all in-scope OpenJS Projects
  • An OpenJS Disclosure Policy and list linking to the individual Project Policies�
  • Two or more POCs to participate in MITRE’s required CNA training and initialization meetings�
  • An ongoing POC to issue CVEs and handle annual program administrivia��The overhead for issuing CVEs is minimal with a well established process. Annual program administration tasks are <1 days work.

21 of 23

How would it work for OpenJS Projects?

Option 2: Break up the OpenJS CVE Block and distribute sub-blocks for Projects to manage locally

Option 1: Designated maintainers have access to OpenJS CVE Block and choose IDs for themselves

Option 3: Security Engineering Champion directly supports CVE issuance as needed

In these Options, to populate/publish the CVE Record with MITRE, Projects would need one of the following:

In this Option, SecEng Champ and one or more backups would have credentials to populate/publish to OpenJS CVEs in coordination with the Project.��This Option can also be used in hybrid with all other Options. It may also make sense to choose the best Option for individual Projects.

a) access to an OpenJS-wide shared credential

b) access to a per-Project shared credential

c) credentials issued to specific maintainers

Option 4: Projects can continue requesting CVE IDs from Github’s CNA by using Github’s Advisory Publication process.

Option 5: If on HackerOne, Projects can continue requesting CVE IDs from H1's CNA by using H1’s CVE Request process (NOTE: this is Node.js’ current approach)

22 of 23

Discussion Summary

  • Projects can keep doing what they’re doing and don’t have to use the OpenJS CNA�
  • No more invalid/unilateral CVEs and challenging dispute processes�
  • Easier and consistent handling of CVEs across OpenJS Projects
  • There is some small, annual overhead for CNA management�
  • Potentially more valid CVEs being issued than than Projects are used to

22

Pros

Cons

23 of 23

Discussion: OpenJS CNA

Adam ‘rudd’ Ruddermann�11 March 2024