Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add npm audit policies rfc #11

Merged
merged 1 commit into from
Aug 7, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
89 changes: 89 additions & 0 deletions accepted/0000-npm-audit-policies.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,89 @@
# Audit Policies

### Motivation

Today there are a limited set of conditions in place that prevent the installation of a package (ex. integrity mismatches & engines conflicts); audits also happen post-installation meaning they are only advisory in practice.

### Solution

Introduce easily configurable audit definitions that can gate the installation of packages. This new feature should leverage existing functionality/commands (ex. `install`, `update` & `audit`), syntax (ex. Dependency Selectors) & metadata without expanding the scope to unbounded, arbitrary code execution (unlike `preinstall` scripts or lifecycle hooks).

### Known Caveats
- Adding extra validation during installation will slow down execution
- this will be up to end-users to control & determine what validations are necessary to meet their own requirements
- Not all usecases will be met
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion (documentation): Correct typo in 'usecases'.

Change 'usecases' to 'use cases'.

- we will be limited by the existing commands, syntax & metadata supported
- we aim to meet 80% (or the majority) of usecases with this feature
- end-users with broader security needs can & still should look at locking down developer environments & enforce policies at the system/network level (something that is outside the scope of the `npm` CLI today)

### Implementation

```json
{
"audit": {
"policies": [
{
"name": "Vulnerable",
"type": "error",
"query": ":vulnerable"
},
{
"name": "Peer Conflicts",
"type": "error",
"query": ".peer:not(:deduped)"
},
{
"name": "Deprecated",
"type": "warn",
"query": ":deprecated"
},
{
"name": "Outdated",
"type": "log",
"query": ":outdated()"
},
{
"name": "Licenses",
"type": "log",
"query": ":not([license=MIT])"
},
{
"name": "Remotes",
"type": "error",
"query": ":type(git), :type(remote)"
},
{
"name": "Extraneous",
"type": "warn",
"query": ":extraneous"
},
{
"name": "Missing",
"type": "warn",
"query": ":missing"
},
{
"name": "Duplicate Peers",
"type": "warn",
"query": ".peer:not(:deduped)"
},
{
"name": "Bad Packages",
"type": "error",
"query": "#phishing, #spam, #malware"
},
{
"name": "Bad Actors",
"type": "error",
"query": ":attr(contributors, [email=bad@example.com])"
},
{
"name": "Architecture Mismatch",
"type": "error",
"query": "@supports(cpu:x64) { [cpu=!x64] }"
}
]
}
}
Comment on lines +21 to +87

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The JSON configuration for audit policies is embedded directly within the markdown document. This can lead to issues with maintainability and readability, especially as the configuration grows or changes over time.

Recommended Solution: Extract the JSON configuration into a separate file and reference it within the markdown document. This will improve maintainability and make it easier to manage changes to the configuration.

```

Loading