Dependency Management¶
Status: 🟢 Active | Owner: Security Engineering | Last Reviewed: 2025-Q4
Introduction¶
Third-party dependencies are one of the organisation's most significant and least-visible attack surfaces. Every dependency is code that runs in production with the same privileges as the application itself — written by people the organisation has not vetted, maintained by projects whose security practices the organisation does not control, and carrying vulnerabilities that may not be discovered until years after the dependency was first introduced.
This section governs the full lifecycle of dependency management: the approval gate before a new dependency is introduced, the pinning and versioning discipline that ensures builds are reproducible, the licence compliance checks that protect the organisation's IP posture, and the continuous scanning that catches newly-disclosed vulnerabilities in existing dependencies.
Why This Matters: The Supply Chain Risk¶
The software supply chain attack surface is broad and well-targeted:
- Typosquatting: malicious packages named to resemble popular libraries.
- Dependency confusion: internal package names resolved to public registry versions by a misconfigured toolchain.
- Maintainer compromise: legitimate packages whose publish credentials were stolen.
- Abandoned packages: dependencies that no longer receive security patches, leaving known vulnerabilities unaddressed indefinitely.
These are not theoretical risks. Supply chain attacks have affected major organisations with high engineering maturity. The approval process, pinning requirements, and continuous scanning in this section are the controls that make these attacks detectable and preventable.
Separation of Duties¶
| Activity | Owner | Approver |
|---|---|---|
| Proposing a new dependency | Engineer | Security Engineering |
| Fast-track approval (pre-approved publishers) | Engineer | Security Engineering (1 business day) |
| Dependency pinning and lock file maintenance | Engineer | Automated CI enforcement |
| Licence compliance verification | Automated (FOSSA) | Legal / Security (on FOSSA alert) |
| Vulnerability scan — per PR | Automated (Snyk) | CI gate (blocks on Critical/High) |
| Vulnerability scan — scheduled daily | Automated (Snyk + Dependabot) | Security Engineering triage |
| Critical vulnerability remediation | Squad | Security Engineering sign-off |
| Exception / accepted risk | Squad | Security Engineering (time-boxed) |
No engineer may introduce a production dependency that has not passed the approval process. No exception may be accepted without Security Engineering sign-off. The approval and scanning processes are not bureaucratic overhead — they are the controls that keep the organisation's production systems secure.
What You Will Find Here¶
| Page | Intent |
|---|---|
| Package & Library Approval | The gate before any new dependency is introduced; fast-track and prohibited sources |
| Dependency Pinning & Versioning | Lock file requirements, version specification standards, upgrade strategy, SemVer |
| License Compliance | Approved, restricted, and prohibited licence categories; FOSSA CI enforcement |
| Vulnerability Scanning | Snyk and Trivy integration, remediation SLAs, exception process |
Key Standards at a Glance¶
| Standard | Rule |
|---|---|
| New dependencies | Require approval before introduction into any production codebase |
| Lock files | Must be committed; never in .gitignore |
| Direct dependency versions | Must be pinned exactly — no ranges, no latest |
| Critical CVEs | Remediate within 24 hours |
| Prohibited licences | GPL, AGPL, SSPL — blocked by FOSSA in CI |
| Internal forks | Require registration and a sunset date; must upstream or retire |
| Dependabot / Renovate | Required on all repositories |
Last reviewed: 2025-Q4 | Owner: Security Engineering