Dependency Intake Review Checklist: A Per-Package Form for Approving New Dependencies

Most organisations have an open source policy that says new packages must be reviewed, but very few give the reviewer a form that turns that sentence into a decision. This template is that form. It is filled in once per new direct dependency, before the package is merged to a main branch, and it records what was checked, what the evidence was and who approved it: maintainer health, authenticity and typosquatting, provenance and signatures, install-time behaviour, licence and the transitive footprint the package brings with it. It is written for application security teams, open source programme offices and the senior engineers who usually end up doing the review. It assumes the policy layer already exists (see the Open Source Software Policy Template) and that the background is understood (see the Open Source Security Guide); here we only cover the per-package review itself.

How to use this template

• One form per new direct dependency. Raise it when a pull request adds a package that is not already on [Organisation]'s approved component list. Version bumps of approved packages do not need a new form unless section 5 says so.
• Automate the evidence, keep the judgement human. Most of section 4 can be filled from software composition analysis, OpenSSF Scorecard, deps.dev and the registry's own metadata. The reviewer's job is to read those results and decide, not to collect them by hand.
• Use the risk tier to size the effort. A test-only helper and a package that will parse untrusted input in production do not deserve the same review. Section 3 sets the depth.
• Store the completed form with the pull request (as a linked ticket or a file under docs/dependencies/) so the decision can be found when the package later goes bad.
• Replace the bracketed values with your own: [Organisation], [OSPO], [AppSec team], thresholds and timings. Thresholds shown are NHI Mgmt Group recommendations unless a source is named.

1. Purpose and scope

1.1 This checklist ensures every new open source package added to [Organisation] software is necessary, authentic, maintained, free of known malicious behaviour, correctly licensed and traceable to an accountable approver.

1.2 It applies to direct dependencies declared in any manifest (for example package.json, requirements.txt or pyproject.toml, pom.xml, go.mod, Cargo.toml), to build and developer tools installed in CI, to GitHub Actions and other pipeline components, and to container base images. Transitive dependencies are covered by automated controls and assessed in item 4.6, not by separate forms.

1.3 It does not replace the response process for a dependency that is later found to be compromised. For that, see the Open source package compromise guide.

2. Roles

3. Request details and risk tier

3.1 Package identity: ecosystem, exact package name as published, version requested, registry URL and source repository URL. Copy the name from the registry page, never retype it.

3.2 Need: what the package does for this project and why an existing approved component or the standard library cannot do it. The OpenSSF Concise Guide for Evaluating Open Source Software puts "Consider Necessity" first for a reason: every dependency, and every transitive dependency it brings, adds attack surface.

3.3 Where it runs: production runtime, build or CI only, developer workstations only, or tests only.

3.4 Component owner: team name and a named individual.

3.5 Risk tier, chosen with this table:

3.6 A build-time package with access to CI secrets is Tier 1 even if it never ships. Install-time code runs with the permissions of whatever installs it.

4. Review checklist

Mark each item Pass, Fail or Not applicable, and record the evidence (a link, a score or a screenshot reference). A Fail on any item marked [blocking] stops approval unless an exception is granted under section 7.

4.1 Authenticity and typosquatting [blocking]

• Name check: the name matches the project's own documentation link to the registry. Search the registry for names one or two characters away, swapped hyphens and underscores, and common prefixes or suffixes (-js, py-, -cli). The OpenSSF Concise Guide advises checking whether a similar name is more popular, since that can indicate a typosquat.
• Source link: the registry entry links to a source repository, and that repository links back to the same registry name. A missing or mismatched link fails.
• Fork check: the repository is the original project, not a personal or attacker-controlled fork. Check the fork relation on the forge and any foundation affiliation.
• Age and popularity: record the package creation date and download trend. A package created in the last [90] days, or a sudden new maintainer on an old package, is referred to [AppSec team].
• Namespace and scope: for internal names, confirm the package resolves from [Organisation]'s private registry or scope and that the same name is not claimable on the public registry. See the Malicious Package and Dependency Confusion Guide.

4.2 Known malicious and vulnerable versions [blocking]

• Malicious package intelligence: the name and version do not appear in malicious package feeds. The OpenSSF Malicious Packages repository publishes reports in OSV format, so any OSV-aware scanner can check it.
• Known vulnerabilities: no unresolved critical or high advisory in the requested version (OSV, GitHub Advisory Database or your SCA tool).
• Version stability: note whether the version is 0.x, alpha, beta or a release candidate. Not blocking on its own, but it should change the upgrade plan in 4.8.

4.3 Maintainer health and project practices

Use the OpenSSF Scorecard result from deps.dev or a local Scorecard run where the project is hosted on a supported forge. Each check scores 0 to 10.

Treat the aggregate Scorecard number as a prompt to look, not a verdict. Scorecard's own documentation notes that small utility libraries may legitimately show little activity, and that a project younger than 90 days cannot yet be assessed for maintenance at all. See the OpenSSF Scorecard Guide for how each check is computed.

4.4 Provenance and signatures

• Registry signatures (npm): run npm audit signatures on the lockfile that includes the package. The npm CLI documentation states it verifies registry signatures and, where present, provenance attestations of downloaded packages.
• Attestations (PyPI): record whether the release files carry PEP 740 attestations. PyPI documents that publish attestations give publicly verifiable proof that a package was published through a specific Trusted Publisher, signed by GitHub Actions, GitLab CI/CD or Google Cloud identities.
• Build provenance: where the project publishes SLSA provenance, record the builder and source repository it names and confirm they match 4.1. See the SLSA and Build Provenance Guide.
• Release artefact matches source: for Tier 1, spot-check that the published artefact corresponds to a tagged commit. The XZ Utils backdoor hid its payload in release tarballs and test files rather than the source most reviewers read.
• Result: absence of provenance is not blocking for most ecosystems today, but record it. It becomes a gap to close when the project starts publishing provenance.

4.5 Install-time behaviour [blocking for Tier 1]

• Lifecycle scripts: check the package manifest for install hooks. In npm these are preinstall, install and postinstall; npm's documentation notes that preinstall runs before dependencies are fetched. In Python, a source distribution may execute build code at install time, which is one reason pip's secure install guidance recommends --only-binary :all:.
• Script content: for Tier 1, read any install script. The OpenSSF Concise Guide says to look for exfiltration from ~/.ssh and environment variables and for encoded or obfuscated values that are executed, and to examine recent commits.
• Sandboxed install: for Tier 1, install the package in an isolated environment with no credentials and outbound network monitoring, and record any unexpected network connection, file write outside the project or new process.
• Why it matters: the Shai-Hulud npm worm ran through a preinstall script with no user interaction and harvested npm, GitHub and cloud tokens from whatever machine installed it.

4.6 Transitive footprint

• Count: number of new transitive packages the addition brings, taken from the lockfile diff.
• New install scripts: any transitive package with lifecycle scripts is listed and checked against 4.2.
• Unnecessary dependencies: does it pull development or test dependencies into production? The OpenSSF Concise Guide lists this under Dependency Impact.
• Git and URL dependencies: any dependency that resolves from a git reference or URL instead of the registry is listed. npm offers an allow-git setting to limit these.

4.7 Licence [blocking]

• Declared licence: an SPDX identifier is present and matches the licence file in the repository.
• Approved for use: the licence is on [Organisation]'s approved list for this distribution model (internal, SaaS, distributed binary). If not, route to the licence reviewer. See the Open Source Licence Compliance Guide.
• Transitive licences: the SCA licence report for the lockfile diff shows no unapproved licence.

4.8 Pinning and update plan

• Lockfile: the exact resolved version and integrity hash are committed. For pip, hash-checking mode (--require-hashes) requires every requirement to be pinned with == and to carry a hash.
• Range policy: the manifest range follows [Organisation]'s rule. See Dependency Pinning vs Version Ranges.
• Cooling-off: the requested version has been public for at least [7] days. npm's min-release-age and before settings let the installer enforce this.
• Update owner: the update tool (for example Dependabot or Renovate) is configured for the package, and the component owner receives its pull requests.

5. When a new form is needed for an approved package

5.1 A version change of an approved package is covered by automated checks only, unless any of the following is true, in which case the reviewer repeats section 4 for the new version:

• a new major version, or a change of package name or registry namespace;
• a change of maintainers or publishing account since the last approved version;
• new or changed install scripts;
• loss of provenance or attestations that earlier versions carried;
• a licence change;
• the package moves to a higher risk tier, for example from tests into production.

6. Decision record

6.1 On approval, the package and version range are added to the approved component list and the SBOM process picks them up. On rejection, the requester records the alternative chosen.

7. Exceptions

7.1 A blocking failure may be accepted only by [AppSec team], for a stated period of no more than [6] months, with compensating controls recorded (for example vendoring a reviewed copy, running with install scripts disabled, or network isolation of the build step).

7.2 Exceptions are logged with the item number, the reason, the compensating control, the owner and the expiry date, and reviewed monthly. An expired exception reverts to a rejection unless renewed.

Implementation guidance

1. Start with detection, not blocking. Run the automated parts of section 4 against every pull request that changes a manifest for [4] weeks and report results without failing builds. Use the data to tune thresholds and find the noisy checks.
2. Turn on the cheap controls everywhere. Lockfiles committed, npm ci rather than npm install in CI, install scripts disabled on CI runners that hold publishing or cloud credentials (npm's ignore-scripts setting, with an allowlist for packages that genuinely need a build step), and a cooling-off period.
3. Route all installs through a proxy registry so that malicious package blocking and private namespace protection apply in one place.
4. Enforce the form as a merge check. A CI job detects a new direct dependency not on the approved list and fails until the form reference is attached. Tier 3 packages that pass all automated checks can be auto-approved by the same job.
5. Train reviewers on ten real forms before handing them the queue. Calibration matters more than the template.
6. Roll back safely. If the gate blocks urgent work, switch the CI job to warn mode for a stated period rather than removing it, and log every merge made in that window for retrospective review.

Metrics

Framework mapping

Standards and references

• OpenSSF: Concise Guide for Evaluating Open Source Software
• OpenSSF: Scorecard checks documentation
• OpenSSF: Malicious Packages repository
• npm: npm audit (audit signatures)
• npm: Scripts and lifecycle hooks
• PyPI: Attestations
• pip: Secure installs
• npm: Config (ignore-scripts, min-release-age, allow-git)

Related NHI Mgmt Group resources: the Open Source Security Guide, the Malicious Package and Dependency Confusion Guide, Dependency Pinning vs Version Ranges, the Open Source Software Policy Template and the Software Supply Chain Security Guide.