# Package Vulnerability Management & Reporting

## Champion(s) & Participants

- Darcy Clarke (@darcyclarke)
- Engineering Manager for the **npm** CLI & Node.js
Collaborator (active in Package Maintenance, Tooling WGs)
- Wesley Todd (@wesleytodd)
- Node.js collaborator (active in Package Maintenance, Web Frameworks WGs)

## Initial Participants

> Please provide a list of initial participants and their background/knowledge of the space proposed.

- Darcy Clarke (@darcyclarke)
- Engineering Manager for the **npm** CLI & Node.js
Collaborator (active in Package Maintenance, Tooling WGs)
- Wesley Todd (@wesleytodd)
- Node.js contributor (Package Maintenance WGs)
- Zbyszek Tenerowicz (@naugtur)
- Creator of [npm-audit-resolver](https://github.com/naugtur/npm-audit-resolver)
- Node.js contributor (Diagnostics WG)
- Christopher Hiller (@boneskull))
- Node.js collaborator and Mocha maintainer
- Michael Dawson (@mhdawson)
- OpenJS CPC member, Node.js collaborator and TSC Chair.
- Dominykas Blyžė (@dominykas)
- Node.js contributor (Package Maintenance WGs)
- Jordan Harband (@ljharb)
- Node.js, npm contributor

We also plan to reach out to Snyk, HackerOne & GitHub (specifically, the DSP - Data & Security Products - Team) to encourage participation.

## Description

> Please provide a rough description of the collaboration space in less
than 100 words and the goals that you hope to achieve.

Today maintainers get bombarded with issues and dependency update PRs when a new CVE is reported on popular libraries. Many, if not most, of these are false positives from a vulnerability perspective. This level of noise creates distrust between security companies/researchers, maintainers, and end users.

We hope to improve CVE reporting and resolution workflows to minimize the burden of vulnerability report handling on software maintainers and package consumers.

Example outcomes:
- allow audit result management
- maintainers can suppress dependency vulnerability reports not affecting their packages
- postponing/ignoring vulnerability reports by end user
- improve CVE communication between maintainers and security researchers/companies

## Impact & users of the project

> Why is the proposed area/topic important to the JavaScript Ecosystem?

Existing vulnerability reporting & management creates load on maintainers and end-users. There are many examples of this leading to frustrations and work for maintainers and end users, here are a few example links:

- https://github.com/facebook/create-react-app/issues/8529
- https://github.com/handlebars-lang/handlebars.js/issues/1668
- https://github.com/conventional-changelog/conventional-changelog/issues/592 (this one was not called out as a false positive, but it is)
- https://github.com/yargs/yargs/issues/1790 (a company reporting to users w/o notifying the maintainers or filing a CVE)

This is a cross-functional effort which might include and impact the following:

- Security Orgs
- Package Maintainers
- End-users

It is, therefore, important to the JavaScript ecosystem that we find a way to better handle CVE reporting and
management, particularly due to the deep depenency trees that exist for JavaScript applications. This makes the OpenJS
Foundation the most appropriate place to try to address the concern.

It is also worth noting that this extends beyond JavaScript, a key aspect for larger orgs might be considering how
this works across language ecosystems. We should consider the applicability/use of whatever the collaboration space comes up with
for CVE management for other languages as well.

## Resources

> Which [resources](https://github.com/openjs-foundation/cross-project-council/blob/master/COLLABORATION_SPACE_PROGRESSION.md#expectations) would the space need from those listed as available to Collaboration spaces:
>
- Repository
- Use of the Foundation Zoom & YouTube streaming
- A Slack channel within the Foundation Slack organization
- Use of meeting generation tools as may made available by the foundation
- 2 re-tweets from the OpenJS Foundation twitter account per month
- The foundation inviting member companies to participate
- Support for up to 2 surveys

## Existing assets

- JSON schema for audit-resolve format to be exracted from here https://github.com/naugtur/audit-resolve-core/blob/master/auditFile/versions/v1.js
- This is already licened as Apache 2.0.

## Proposal Checklist

- [x] members/space leaders agree to managing the space under open governance.
- [x] work will happen under the OpenJS Foundation IP Policy, and use the Apache 2.0 licence
- [x] the collaboration space will work under the OpenJS CoC

## Questions?

> What questions do you have? What questions might arise during your application?

None at this point.

---

# TODO

- ~~(Wes) Email the group to see who else wants to participate and be added to the initial participants list in the proposal~~
- [ ] (Darcy) Email OpenJS Foundation with proposal - [e-mail]

# Feedback

- (Wes) I would love if folks had more example links to show the amount of work this generates.
-