Update: NPM_Security_Cheet_Sheet - Artifact Governance

[imaPheven]

What is missing or needs to be updated?

More emphasis on artifact governance / dependancy chain

The cheatsheet has little emphasis dependancy chain / artifact governance. Yet OWASP has identified these as top concerns in multiple areas:

• A08:2021 – Software and Data Integrity Failures
• CICD-SEC-3: Dependency Chain Abuse
• CICD-SEC-9: Improper Artifact Integrity Validation

Section 5: Audit for vulnerabilities in open source dependencies references dependancies but doesn't address artifact managment.

Section 6: Use a local npm proxy refers to private proxies but the emphasis seems to more directed at convenience and performance rather than security.

Most major platforms offer some form of artifact management (Azure Artifacts, AWS CodeArtifact, Google Artifact Registry, GitHub Packages, GitLab Package Registry) and there might be a way to reference artifact management or governance in addition to convenience.

Typosquating

Typosquatting briefly mentioned near the end and feels almost as if it's an after thought. As is, it could be easily missed as a concern that it is a vector to introduce threats into an ecosystem.

How should this be resolved?

Typesquating should be prioritized higher.

Dependancy chain

A new section could be created focusing on language around artifact management or dependancy governance, or simialar language.

Or ...

• Section 5 updated to expand on the artifact management
• Section 6 could be updated to expanding beyond just proxy that more than just convince and performance.

In addition, linking out other relevant cheatsheets so that an interested reader can dive deeper.

• OWASP: CI/CD Security Cheat Sheet
• OWASP: Software Supply Chain Security
• OWASP: Typosquatting attacks

[szh]

Yes, recent events have made apparent the risks here. Many orgs use private npm registries that mirror the public ones but have some controls to attempt to prevent these kinds of risks. I'm not an expert on these systems but it would probably make sense to at the very least make mention of them.

[Jeymz]

Would something like a 6.1 section make sense here? e.g.

## 6.1) Artifact governance and supply chain protections

Supply-chain attacks increasingly target build artifacts, registries and CI credentials. Add lightweight governance and verification steps to reduce risk and improve response time:

- Track provenance and produce an SBOM for builds (CycloneDX/SPDX) so you can trace what was built and where inputs originated.
- Sign artifacts and build provenance (for example, use Sigstore / cosign or similar signing tools) so consumers can verify integrity before installing.
- Prefer immutable, access-controlled registries or vetted mirrors (private registries, Verdaccio with an upstream cache, or approved mirrors) and enable retention/immutability policies where available.
- Restrict, scope and rotate CI and publisher tokens; bind tokens to workflows or IP ranges and minimize privileges.
- Verify packages during CI: check signatures or provenance, validate the SBOM, run SCA and static analysis, and install from pinned lockfile resolutions.
- Automate monitoring and alerts for unusual publishes, token usage or dependency changes and keep a documented remediation playbook (revoke tokens, deprecate/yank compromised packages, publish fixes and notify consumers).

These measures are incremental and low-risk to adopt; combined they make supply-chain attacks harder and speed up recovery if a compromise occurs.

[Jeymz]

Might even be worth including a link to the OWASP Dependency Tracker or examples of generating CycloneDX SBOMS in pipelines.

[jmanico]

I these are all good ideas @Jeymz

[Jeymz]

I these are all good ideas @Jeymz

Would you like me to take a stab at it and issue a PR, or do you feel like there are still some gaps from the original issue?

[jmanico]

Go go PR, you got this. We prefer to give you a hard time AFTER the PR, not before it. wink

[imaPheven]

I like what @Jeymz had ... only recommendation I might add is adding definitions around terms like SBOM, SCA and CI credentials. Often times as part of onboarding for projects is OWASP cheatsheets are required training people might not dig into what those mean.

[Jeymz]

I'm waiting on another PR with my fork right now, but I do have this staged in a branch and included some of those details.

...

## 6) Artifact governance and supply chain protections

### Use a local npm proxy

The npm registry is the biggest collection of packages that is available for all JavaScript developers and is also the home of the most of the Open Source projects for web developers. But sometimes you might have different needs in terms of security, deployments or performance. When this is true, npm allows you to switch to a different registry:

When you run `npm install`, it automatically starts a communication with the main registry to resolve all your dependencies; if you wish to use a different registry, that too is pretty straightforward:

- Set `npm set registry` to set up a default registry.
- Use the argument `--registry` for one single registry.

[Verdaccio](https://verdaccio.org/) is a simple lightweight zero-config-required private registry and installing it is as simple as follows: `$ npm install --global verdaccio`.

Hosting your own registry was never so easy! Let’s check the most important features of this tool:

- It supports the npm registry format including private package features, scope support, package access control and authenticated users in the web interface.
- It provides capabilities to hook remote registries and the power to route each dependency to different registries and caching tarballs. To reduce duplicate downloads and save bandwidth in your local development and CI servers, you should proxy all dependencies.
- As an authentication provider by default, it uses an htpasswd security, but also supports Gitlab, Bitbucket, LDAP. You can also use your own.
- It’s easy to scale using a different storage provider.
- If your project is based in Docker, using the official image is the best choice.
- It enables really fast bootstrap for testing environments, and is handy for testing big mono-repos projects.

### Governance & Verification Steps

Supply-chain attacks increasingly target build artifacts, registries and CI credentials. Add lightweight governance and verification steps to reduce risk and improve response time:

- Track provenance and produce an SBOM for builds (CycloneDX/SPDX) so you can trace what was built and where inputs originated.

  CycloneDX Example:

  ```bash
  # Generate SBOM
  npm install @cyclonedx/cyclonedx-npm
  npx @cyclonedx/cyclonedx-npm --validate > sbom.json # Use the flag `--omit dev` to exclude dev dependencies from SBOM if needed
  ```

- Sign artifacts and build provenance (for example, use Sigstore / cosign or similar signing tools) so consumers can verify integrity before installing.

  Sigstore Example:

  ```javascript
  // sign-and-verify.js
  // npm install sigstore fs

  import * as fs from 'fs';
  import * as sigstore from 'sigstore';

  // Path to your built npm package (via `npm pack`)
  const artifact = 'my-lib-1.0.0.tgz';

  // --- Sign ---
  const payload = fs.readFileSync(artifact);
  const bundle = await sigstore.sign(payload);
  fs.writeFileSync(`${artifact}.sigstore.json`, JSON.stringify(bundle, null, 2));
  console.log('Signed:', artifact);

  // --- Verify ---
  await sigstore.verify(payload, bundle);
  console.log('Verified OK!');
  ```

- Prefer immutable, access-controlled registries or vetted mirrors (private registries, Verdaccio with an upstream cache, or [approved mirrors](#use-a-local-npm-proxy)) and enable retention / immutability policies where available.
- Restrict, scope and rotate CI and publisher tokens. Bind publisher tokens to workflows or IP ranges and minimize privileges.
- Verify packages during CI: check signatures or provenance, validate the SBOM, [run SCA and static analysis](#5-audit-for-vulnerabilities-in-open-source-dependencies), and [install from pinned lockfile resolutions](#2-enforce-the-lockfile).
- Automate monitoring and alerts for unusual publishes, token usage or dependency changes and keep a documented remediation playbook (revoke tokens, deprecate/yank compromised packages, publish fixes and notify consumers).

These measures are incremental and low-risk to adopt. Combined they make supply-chain attacks harder and speed up identification & recovery if a compromise occurs.
...