Dependency Management Policy Template (SSDF, Scorecard)

Dependency Management Policy: [Organisation or product line]

Policy for adding, sourcing, pinning, updating, monitoring and removing third-party dependencies: open source and commercial libraries, container base images, build plug-ins and CI actions. It sets intake criteria, approved sources, lock and integrity rules, update cadence with a release-age cooldown, vulnerability and malicious-package response, licence gates, vendoring and removal. It is based on NIST SP 800-218 SSDF version 1.1 practice PW.4 (reuse existing, well-secured software) and uses OpenSSF Scorecard v5 checks and the OpenSSF Open Source Project Security Baseline (OSPS Baseline, release v2026.08.28) as evaluation signals, with the CISA Known Exploited Vulnerabilities (KEV) catalog as an exploitation signal. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Purpose, scope and principles
2. Roles and responsibilities
3. Policy statements
4. Ecosystems, dependency types and tiers
5. Intake of a new dependency
6. Sourcing, pinning and integrity
7. Updates and cooldown
8. Vulnerable and malicious dependencies
9. Licence compliance
10. Forks, vendoring and patches
11. Removal and end of life
12. Exceptions and risk acceptance
13. Compliance measurement
14. Review cycle
15. Glossary and references

1. Purpose, scope and principles

1.1 Purpose

Most of the code [Organisation] ships was written by someone else. This policy makes sure that code is chosen deliberately, comes from where we think it comes from, is the exact version we tested, stays patched, is legally usable, and is removed when it is no longer needed. It implements SSDF practice PW.4 (reuse existing, well-secured software): task PW.4.1 (acquire well-secured third-party components and keep them maintained), task PW.4.4 (verify that third-party components keep meeting our requirements over their life cycle) and, for shared components built in-house, task PW.4.2.

1.2 Scope

In scope: every third-party component that is compiled into, bundled with, loaded by or used to build software we ship or operate. This covers direct and transitive library dependencies, container base images, OS packages installed in images, build plug-ins and compilers, CI actions and reusable workflows, infrastructure-as-code modules and providers, AI models and datasets pulled from public hubs, and commercial SDKs.

Out of scope: SaaS services consumed over the network (covered by supplier security assessment) and developer desktop tools that do not take part in builds.

1.3 Principles

• Fewer, better dependencies. Every dependency is attack surface, licence obligation and maintenance cost.
• Reproducible resolution. A build resolves the same bits today and in a year.
• Trust is checked, not assumed. Provenance, signatures and integrity hashes are verified where the ecosystem provides them.
• Updates are routine, small and automated, so that urgent security updates are not also large migrations.
• The owning team owns its dependencies, including transitive ones.

2. Roles and responsibilities

R = responsible, A = accountable, C = consulted, I = informed.

3. Policy statements

4. Ecosystems, dependency types and tiers

4.1 Dependency types

4.2 Tiers

Tier is set per repository by the highest-risk product it feeds.

5. Intake of a new dependency

5.1 Questions for every intake

1. Need: what does it do that the standard library, the platform or an existing approved dependency does not?
2. Size: how many transitive dependencies does it add? Does it run install scripts?
3. Maintenance: are there releases and responses to issues in the last 12 months? More than one active maintainer?
4. Security practices: does it publish a security policy, sign releases or publish provenance, and have a reasonable OpenSSF Scorecard result?
5. Vulnerability history: open known vulnerabilities, and how fast past ones were fixed.
6. Licence: is the declared licence in the allowed list, and do file-level licences agree with it?
7. Identity: is this the genuine package (not a typosquat or a namespace confusion), from the expected publisher?
8. Exit: how hard would it be to replace?

5.2 Full review criteria (Tier 1)

Decision rule: a candidate passes with a weighted score of at least 70 and no failed Known vulnerabilities or Licence criterion. A criterion that meets its threshold earns its full weight and one that fails earns 0; a reviewer may award partial credit on a criterion with a written reason in the intake log. Scorecard scores run from 0 to 10 per check, and a check can return -1 when the result is inconclusive: treat -1 as a fail until the reviewer has checked the signal manually. Record the Scorecard version used, because checks and probes change between releases.

5.3 Intake log

Worked score for DEP-INT-014 (Example): Maintenance 20, Code review 15, Release integrity 15, Known vulnerabilities 20, Security policy 10, Footprint 0 (24 new packages, over the threshold), Licence 10. Total 20 + 15 + 15 + 20 + 10 + 0 + 10 = 90. The reviewer reduced Release integrity to 10 because only some releases carried provenance, giving 85, and approved it with a note to track the footprint.

6. Sourcing, pinning and integrity

6.1 Approved sources

Build runners MUST NOT reach public registries directly except through the proxy. Internal package names MUST be reserved or scoped so that a public package with the same name cannot be substituted (dependency confusion).

6.2 Pinning and lock files

• Commit the lock file for every application and service. Libraries that are published SHOULD also commit a lock file for their own CI, while declaring compatible ranges for consumers.
• Install with the frozen or immutable lock option so CI fails when the lock file and manifest disagree.
• Pin CI actions and reusable workflows to a full commit SHA, with the version in a trailing comment for readability, and let the update bot propose SHA updates.
• Pin container base images by digest in Dockerfiles and deployment manifests.
• Lock files record integrity hashes; review hash changes in pull requests that do not change versions, because they can indicate a re-published artefact.

6.3 Verification

7. Updates and cooldown

7.1 Currency targets

7.2 Cooldown (minimum release age)

A newly published version is not adopted for normal updates until it has been public for the cooldown period. Compromised releases and accidental breakages are often found and withdrawn within days, so a short delay removes much of that risk at low cost.

Configure the cooldown in the update tooling, for example the cooldown option of Dependabot, the minimumReleaseAge option of Renovate or the minimumReleaseAge setting of pnpm; check each tool's documentation for units and defaults, which differ. Dependabot's cooldown applies to version updates only and never delays its security updates; pnpm's minimumReleaseAge is expressed in minutes, so 7 days is 10080.

7.3 Update process

• Group related updates (for example all patch updates of test tooling) to limit pull request volume. Keep runtime-critical packages in their own pull requests.
• Auto-merge is allowed only when the test suite meets the coverage floor of the repository and the update is patch or minor.
• Major upgrades are planned work with an owner and target date in the backlog; read the upstream changelog and migration guide.
• A version held back on purpose is pinned with a comment linking to the issue that explains why and when it will be lifted.

8. Vulnerable and malicious dependencies

8.1 Detection

• Software composition analysis (SCA) runs on every pull request, nightly on default branches, and continuously against the SBOMs of released versions, so new advisories on old releases are found.
• Advisory sources: the ecosystem advisory databases, the OSV database, vendor advisories, and the CISA KEV catalog for evidence of exploitation.

8.2 Prioritisation and remediation

Remediation SLAs, severity rules and exploitation signals are owned by the Vulnerability Management Policy (security/vulnerability-management-policy). For dependencies this policy adds:

1. A vulnerability listed in the CISA KEV catalog, or with confirmed exploitation, takes the shortest SLA regardless of base score.
2. When a fixed version exists, update to it; the cooldown does not apply.
3. When no fixed version exists, apply a documented mitigation (configuration, input validation, removing the vulnerable feature) or replace the dependency.
4. When the vulnerable code is not present or not reachable in our product, record a VEX status of not_affected with a justification, as set by the SBOM and VEX Policy (security/sbom-vex-policy).
5. Released product versions affected by a dependency vulnerability are fixed according to the Versioning and Release Policy (dev/versioning-release-policy) backport rules.

8.3 Malicious packages

A dependency that contains malicious code (credential stealer, backdoor, protestware) is a security incident, not a vulnerability ticket:

1. Block the package and version at the registry proxy immediately.
2. Identify every build and environment that installed it, from lock files, build logs and SBOMs.
3. Assume secrets available to those builds are exposed: rotate CI tokens, registry tokens, cloud credentials and signing keys in scope.
4. Rebuild affected artefacts from a clean state and check released artefacts for contamination.
5. Run the incident under the Incident Response Plan (compliance/incident-response-plan) and record lessons learned.

9. Licence compliance

• The licence scanner reads both the declared licence and file-level licence texts and reports mismatches.
• Products that are distributed (SDKs, agents, mobile apps) MUST ship a third-party notices file generated from the SBOM.
• Commercial dependencies are reviewed with the Software Licence and Contract Technical Review (compliance/software-licence-review).

10. Forks, vendoring and patches

• Prefer contributing a fix upstream and pinning to the fixed release over forking.
• When we find a vulnerability in a third-party component, report it to the maintainer through their published route. For products in scope of the EU Cyber Resilience Act, Article 13(6) makes this a duty, requires the manufacturer to remediate the vulnerability in its own product under Annex I, Part II, and, where it has developed a fix, to share the code or documentation with the maintainer, in machine-readable form where appropriate (check the consolidated text; this is a documentation format, not legal advice).
• A temporary patch (for example through the package manager's patch mechanism) MUST link to the upstream issue or pull request and be reviewed every update cycle.
• A fork or vendored copy MUST be registered below, keep the original licence and notices, and stay visible to SCA scanners (vendored directories are included in SBOMs).

11. Removal and end of life

• Unused dependency reports run monthly; unused direct dependencies are removed within one release cycle.
• A dependency is considered abandoned when the repository is archived, the maintainers say so, or there has been no release or maintainer response for [18] months while issues accumulate. Abandoned Tier 1 dependencies need a replacement plan with an owner and date within [90] days.
• Runtimes and frameworks follow their upstream lifecycle; the upgrade is planned before upstream end of life, as set in section 7.1.
• When removing a dependency, also remove its configuration, licence notice entries and any exceptions that referenced it.

12. Exceptions and risk acceptance

An exception names the policy statement (section 3), repository, dependency and version, the reason, compensating controls, approver (per tier in section 4.2) and an expiry no later than [6] months. Exceptions that accept a known vulnerability are also recorded in the Risk Register (compliance/risk-register).

13. Compliance measurement

Worked example (Example): corvid-storefront has 61 direct dependencies; 55 are within target, so DEP-M03 = 55 / 61 x 100 = 90.2%, just above target. The six behind are tracked in the backlog with owners.

Results are reported monthly on the dependency dashboard and quarterly to the engineering leadership review. Repositories can also run the OpenSSF Scorecard against themselves. DEP-04, and in part DEP-03 (frozen installs in scripts and workflows), map to its Pinned-Dependencies check, which inspects Dockerfiles, shell scripts and GitHub workflows; DEP-05 and DEP-06 map to its Dependency-Update-Tool check. DEP-02 has no Scorecard equivalent and is checked through runner egress rules and registry configuration.

14. Review cycle

• Scheduled review every 12 months by the policy owner with AppSec and open source counsel.
• Early review after: a malicious-package incident affecting the organisation or a major ecosystem; a new ecosystem adopted; a new major release of SSDF, Scorecard or OSPS Baseline; a regulatory change affecting component due diligence (for example the EU Cyber Resilience Act duty to exercise due diligence on integrated third-party components, Article 13(5), applying from 11 December 2027; check the consolidated text).
• Review outcomes are recorded in the revision history.

15. Glossary and references

15.1 Glossary

15.2 References

Standard and licence note

Based on NIST SP 800-218 (SSDF version 1.1, February 2022), a work of the United States Government not subject to copyright in the United States, and on Regulation (EU) 2024/2847, Articles 13(5) and 13(6), paraphrased from the Official Journal text; the CRA parts are a documentation format, not legal advice. OpenSSF Scorecard (Apache-2.0) check names and the OSPS Baseline (OpenSSF, release v2026.08.28) level, category names and control IDs are cited by name only; no check or control text is reproduced. The CISA KEV catalog is a public US Government resource. Dependabot, Renovate and pnpm are named as configuration examples; GitHub and Dependabot are trademarks of GitHub, Inc., Renovate is a trademark of its owner, and this template is not affiliated with or endorsed by them. Licence identifiers follow the SPDX License List. Check the current official versions of SSDF, Scorecard, OSPS Baseline and the tool documentation before adopting this policy. Original text written for this collection. Template licence: MIT.