#### 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