---
# System prepended metadata

title: Deep Dive - Open RFC Meeting (npm)

---

#### Meeting from: August 4th, 2021

# Deep Dive - Open RFC Meeting (npm)

### Attendees
- Darcy Clarke (@darcyclarke)
- Tierney Cyren (@bnb)
- Gar (@wraithgar)
- Zbyszek Tenerowicz (@naugtur)
- Myles Borins (@mylesborins)
- Mike MacDonald (@asciimike)
- Owen Buckley ()
- Rebecca Turner (@iarna)

### Previously...

- [2021-07-28](https://github.com/npm/rfcs/blob/latest/meetings/2021-07-28.md)

### Agenda

1. **Housekeeping**
	1. Introduction(s)
	1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct)
	1. Outline Intentions & Desired Outcomes
	1. Announcements
1. **Topic:**
    - `audit` improvements
1. **References/Resources:**
    - **PR**: [#422 RFC: audit assertions](https://github.com/npm/rfcs/pull/422) - @bnb
    - **PR**: [#18 RFC: npm audit resolver](https://github.com/npm/rfcs/pull/18) & [Drafted Audit File RFC & schema](https://github.com/openjs-foundation/pkg-vuln-collab-space/pull/11) - @naugtur
    - Foundation Efforts:
      - [Oasis Common Security Advisory Framework Version 2.0 - 4.5 Profile 5: VEX](https://github.com/oasis-tcs/csaf/blob/master/csaf_2.0/prose/csaf-v2-editor-draft.md#45-profile-5-vex)
      - [Open Source Security Foundation](https://openssf.org/) ([@ossf](https://github.com/ossf))
        - [Scorecard](https://github.com/ossf/scorecard)
        - [Tooling](https://github.com/ossf/wg-security-tooling)
        - [Disclosures](https://github.com/ossf/wg-vulnerability-disclosures) & [Guide](https://github.com/ossf/oss-vulnerability-guide)
        - [Criticality Score](https://github.com/ossf/criticality_score)
        - [GitHub Joins OSSF](https://github.blog/2020-08-03-github-joins-the-open-source-security-foundation/)
      - [Package Vulnerability Management & Reporting Collaboration Space](https://github.com/openjs-foundation/pkg-vuln-collab-space)

### Notes

#### **PR**: [#422 RFC: audit assertions](https://github.com/npm/rfcs/pull/422) - @bnb

- @bnb:
  - overview of the RFC is that this is an extension of the CLI to create a mechanism for counter-claiming a CVE
  - allows maintainers to claim whether their project is impacted (boolean) 
  - ideally, this information would then be surfaced by `npm audit` (have the ability to filter with this extra meta data/information)
  - large projects, like CRA, would take advantage of this
- @wesleytodd 
  - have done interviews for collab space
  - one use-case/user interviewed (similar to CRA) had issue with counter-claims
  - would be good to add more prior-art links/references to this RFC to help scope feedback/conversation
- @naugtur
  - believes that using a package definition vs. package tree reference/path is less useful
  - would recommend using the format/schema drafted [here](https://github.com/openjs-foundation/pkg-vuln-collab-space/pull/11)
- @wraithgar
  - `nsp` (Node Security Project) went this route as well
- @bnb 
  - we should probably align any specs with what other SME fondations/orgs look to be standardizing on/around (ref. https://github.com/oasis-tcs/csaf/blob/master/csaf_2.0/prose/csaf-v2-editor-draft.md#45-profile-5-vex)
- @wesleytodd
  - some of the referenced links were net-new materially to internal SMEs (ie. Security folks) at Netflix
  - we should @ the security folks that are working in this space to review this approach/work
- @naugtur
  - the tooling/schema in `npm-audit-resolver` has been in use for over 4 years
  - review of these separate tools/formats (re. links referenced)
  - our ecosystem's usage/tooling will always be bespoke
  - the issue at hand is letting the maintainers that are requesting it now - make counter-claims. They want to be able to do the work instead of responding to reports flooding in from users
- @mylesborins
  - concerned about solutioning something that is too large vs. addressing papercuts
  - many problems that we're trying to solve for
  - one of the major problems seems to be "noise"
  - potentially much smaller iterative changes (ex. UX/UI of current `audit` output)
  - another issue that seems to be raised in this area is the management of the community
  - believes CVE are inherently broken
    - context is lost 
    - need an understanding about applicability
    - are often applied in a binary vs. trinary (allowing)
  - "increase signal vs. reduce noise"
  - concerned about proprietary solutions for `npm`
  - would like to see smaller improvements to the existing experience/tools
- @asciimike
  - case-study from dependabot, have had experience in trying to resolve the noise - was able to increase  
  - can we remove human element by introducing static analysis (as there seems to be the potential for a maintainer to be a bad actor as they may be incentivized to not resolve or counter-claim CVEs)
  - not worried about nuanced ecosystem advisories (have already worked hard to resolve that within the GitHub Advisory DB)
- @wesleytodd 
  - can we align on scope
  - don't think we can go deep on resolving on the upstream CVE problems
  - we should be focused on `npm`
- @mylesborins
  - not trying to expand scope with original comments
  - do not want to have people turn off audit all together
- @darcyclarke
  - developers in the ecosystem already have turned off audits by using a different package manager that does not audit by default (ie. `yarn`/`pnpm`) 
- @wesleytodd
  - would want something that is provided by a third-party
- @bnb
  - to clarify, this RFC does not allow maintainers to silence dependency CVEs
  - this information is still available
  - this RFC is meant to provide more context
- @naugter 
  - I was thinking of dynamic analysis - instrument like nyc, run coverage in production to collect data, use the collected data to figure out real dependency coverage for a product. IT's a huge project this, I won't make it in my free time :D
  - there is an existing host for lists of resolutions which allows for a third-party source of truth/trust
  - not anyone should be able to counter-claim
  - ref. blog post https://dev.to/naugtur/do-you-need-help-with-your-npm-audit-3olf
- @bnb
  - as a new developer to the ecosystem, I have no understanding of who to trust 
- @wesleytodd 
  - Should queue up action items with OpenJS Collab Space

### Action Items
- [ ] @bnb to provide intial context/scope to the RFC (to narrow the focus of conversation)
- [ ] `npm` team to investigate/queue up changes to clean up output

