# Supply-chain security

Dependency security is a continuous control from resolution and installation through scripts, upgrades, and publishing—not a one-time scan.

## Reproducible installation

Since Deno 2.8, `deno ci` provides an `npm ci`-style strict install: it requires `deno.lock`, removes stale `node_modules`, and installs from a frozen lockfile.

```bash
deno ci
deno ci --prod
deno test
```

Use `deno install` during development and `deno ci` for CI or production builds. Refresh an outdated lockfile explicitly in a development branch and review its diff; never repair it automatically in CI.

## Vulnerabilities and lifecycle scripts

```bash
deno audit
deno audit --socket
deno audit --fix
deno approve-scripts
```

`deno audit --fix` changes manifests and regenerates the lockfile, so treat it as a reviewed upgrade. Deno does not run npm `preinstall` / `postinstall` by default. Approve only a package that genuinely needs scripts:

```bash
deno install --allow-scripts=npm:better-sqlite3
```

## Minimum dependency age

Deno 2.9 skips npm versions published less than 24 hours ago by default. Projects can increase the window:

```json title="deno.json"
{
  "minimumDependencyAge": "P3D"
}
```

```ini title=".npmrc"
min-release-age=3
trust-policy=no-downgrade
```

`trust-policy=no-downgrade` prevents a locked package from silently moving from a trusted publication method to a weaker one. It is currently opt-in; first assess provenance coverage across your dependencies.

## Lockfile and vendor

A lockfile pins versions and integrity, but cannot make a build offline when a remote source disappears. `vendor: true` materializes source in the repository. High-assurance environments commit both `deno.lock` and `vendor/`, then enforce frozen resolution in CI.

Official sources: [Supply chain management](https://docs.deno.com/runtime/packages/supply_chain/), [`deno ci`](https://docs.deno.com/runtime/reference/cli/ci/), and [`deno audit`](https://docs.deno.com/runtime/reference/cli/audit/).