A contractor's open source policy should state who may add a dependency, what is checked before approval, where the inventory lives, how fast known flaws are fixed and what is recorded. One page that engineers actually follow beats a long document nobody reads, and it gives customers a clear answer when they ask.
Why contractors get asked
Government customers and primes ask suppliers about their software components, update practices and incident handling. Clauses in contracts may also flow security duties down to subcontractors. The easiest way to answer consistently is a written policy backed by data from your build.
The one page policy
1. Scope. Applies to every package, container image and build tool used in products delivered to customers.
2. Intake. Any new direct dependency goes through a pull request that records: purpose, license, maintainer activity and known flaws at the time of adding. A second person approves.
3. Allowed and blocked. List licenses that need legal review, and a short blocklist of packages or maintainers you refuse after past problems.
4. Inventory. Generate an SBOM for each release and store it with the release. Transitive dependencies count.
5. Pinning. Lockfiles are committed. Builds use exact versions and verify integrity where the ecosystem supports it.
6. Updates. Set target times to fix known flaws by severity and exposure. Reachability helps prioritise. Record exceptions with an owner and an expiry date.
7. Source of packages. Pull from approved registries or a mirror. Ban installing from unreviewed URLs in builds.
8. Incident response. If a dependency is found compromised, who decides, who rebuilds, who tells customers.
9. Records. Keep the approvals, SBOMs and scan reports for the retention period your contracts require.
Make it enforceable
Policies rot unless the pipeline checks them. Add a gate in pull requests that fails when a new dependency has no approval record or carries a flaw above your threshold. Review exceptions monthly.
Customer questions it answers
- What is in your software? The SBOM.
- How do you track vulnerabilities? Scans on each build and a response time.
- How do you stop tampering? Pinning, integrity checks and controlled sources.
- How do you handle a compromised package? The incident step.
Check any specific contract language with your contracts and legal team. This post does not claim what any particular clause or rule requires beyond what you read in your contract.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning, policies, gates and guardrails for pull requests, reachability analysis and compliance evidence automation. A free scan is available at gold.safeguard.sh/scan.
Rolling it out
Start with one product line rather than the whole company. Generate SBOMs for the last three releases, run a scan, and use the results to calibrate your response times so they are realistic. Publish the one page policy in the engineering handbook and walk each team through it in fifteen minutes. After a month, review how many pull requests were blocked and why, and adjust thresholds that are too noisy. Then extend to the next product line.
Quick check
Do transitive dependencies need to be in the inventory?
Yes. Most real exposure comes from components several levels down, so the SBOM should include them.
Last reviewed: 19 October 2026.
