Our reliance on open source and third-party software components is a key enabler for innovation and speed. However, this reliance introduces security, license, and maintenance risks that must be managed proactively. This policy establishes the required, repeatable framework to govern the entire lifecycle of all external components, providing transparency to leadership and enabling our teams to use open source safely, efficiently, and compliantly.
Use the template below to establish a policy specific to your company and team. It is intended for you to adopt, adapt, and make your own.
**DRAFT TEMPLATE***
Version: 1.0
Last Updated: November 2025
Applies To: All projects, repositories, and teams using external or third-party software components, libraries, or packages, including AI-generated code suggestions.
1. Purpose and Scope
1.1 Purpose
This policy establishes automated, auditable, and enforceable controls for managing external software dependencies. It safeguards security, legal compliance, and long-term maintainability by mitigating software supply chain risks across all environments.
1.2 Scope
Applies to all development, DevOps/SRE, architecture, and security personnel working on company-owned or maintained projects using dependency managers (e.g., npm, Yarn, bun, pip, Maven, NuGet, Go modules).
Includes:
- Open source and commercial third-party libraries
- Internal forks and private registries
- AI/LLM-generated code recommendations that import dependencies
1.3 Alignment
This policy aligns with:
- NIST SSDF 1.1 (Secure Software Development Framework)
- OWASP SCVS (Software Component Verification Standard)
- SLSA Level 2+ provenance requirements (draft)
- ISO/IEC 5230 (OpenChain license compliance)
2. Software Composition Analysis (SCA) and Automation
2.1 Tooling
All projects must use an approved Software Composition Analysis (SCA) tool (e.g., Snyk, Mend, GitHub Advanced Security) integrated into the CI/CD pipeline.
SCA must:
- Block Restricted Licenses and High/Critical vulnerabilities
- Generate a Software Bill of Materials (SBOM) in SPDX or CycloneDX format
- Be executed on every build and pull request
2.2 License Compliance
2.3 Security and Quality Rules
3. Package Evaluation and Approval
3.1 Automated Prerequisites
Before submitting a new dependency:
- Vulnerability: No open Critical or High issues (per CVSS v3.1)
- License: Approved per Section 2.2
- Health: Active commits in past 6 months; published by reputable maintainer
- Types: Includes type definitions or equivalents
- Supply Chain Metadata: SBOM or provenance info available (SLSA Level 1+)
3.2 Formal Review and Justification
Developers must open an internal ticket (e.g., Jira, GitHub Issue) containing:
- Business Justification: Purpose and value
- Alternatives Review: Summary of similar options and rationale
- Risk Review: AppSec and Architecture sign-off on security and lifecycle fit
- License Review: Legal sign-off if license is not pre-approved
4. Dependency Maintenance and Security
4.1 Automated Updates
All projects must use automated update tooling (Dependabot, Renovate) for patch and minor upgrades.
SLO: Service Level Objectives
4.2 Lockfile and Reproducibility
- Lockfiles (e.g.,
package-lock.json,yarn.lock,bun.lockb) must be committed and version-controlled. - CI/CD must use commands respecting lockfiles (
npm ci,yarn install --frozen-lockfile). - Manual lockfile edits are prohibited.
4.3 Periodic Pruning
Every 6 months or during major refactoring:
- Remove unused, deprecated, or redundant dependencies.
- Prefer standard libraries or approved organizational packages.
5. Exceptions, Violations, and Incident Response
5.1 Policy Enforcement
Any attempt to bypass SCA or introduce Restricted components will:
- Fail the build automatically.
- Require immediate remediation before new development can proceed.
5.2 Exceptions
Exceptions are temporary and only granted for mission-critical packages with no viable alternative.
- Must be approved in writing by Technical Lead, Security Architect, and Legal (for license exceptions).
- Must include a time-bound mitigation plan (e.g., internal fork, patch, or migration).
- Exceptions expire annually unless renewed.
5.3 Dependency Security Incidents
When a dependency is compromised or found malicious:
- Immediately revoke access and remove the package.
- Notify Security and trigger incident response procedures.
- Document and publish remediation details.
6. Provenance, Attestation, and Reporting
- Projects must adopt package provenance verification technologies (e.g., Sigstore, SLSA, or in-toto attestations).
- SBOMs must be automatically generated for all releases and stored as build artifacts.
- Teams must track metrics for:
- Dependency age and update frequency
- License compliance rate
- Vulnerability closure SLA adherence
7. Governance and Continuous Improvement
Ownership
- AppSec/Security is Accountable for risk-based controls, vulnerability management, and metrics reporting.
- Architecture owns policy design, package approval criteria, and governance cycles.
- DevOps/SRE is Accountable for tooling automation, enforcement, and operational consistency.
- Legal is the sole authority for license approval and exceptions.
- Development is Accountable only where it owns package selection, justification, and ongoing hygiene.
Miscellaneous
- Reviews: Policy effectiveness is reviewed semi-annually.
- Training: Annual developer training on secure dependency management and license compliance is mandatory.
- Audits: Random SCA audit checks will validate compliance and provenance integrity.
⚙️ Policy Lifecycle Flow
Below is a process flow and lifecycle view.
1️⃣ Dependency Introduction Lifecycle
[Developer Proposes Package]
│
▼
[Automated Checks via SCA]
- Vulnerabilities
- License Type
- Maintainer Health
│
▼
[Formal Review Ticket]
- Business justification
- Alternatives reviewed
- Risk & license sign-off
│
▼
[Architect + AppSec Approval]
│
├──► [Approved → Added to Allow List]
│
└──► [Rejected → Developer notified or replaced]
2️⃣ Ongoing Maintenance Lifecycle
[Active Project]
│
├─► Automated PRs (Dependabot/Renovate)
│ - Minor/Patch updates
│
├─► SCA in CI/CD on every build
│ - Vulnerability & License check
│
├─► Biannual Pruning
│ - Remove unused/deprecated deps
│
└─► SBOM + SLSA Attestation
- Stored with release artifacts
3️⃣ Exception and Incident Handling
[Restricted or Vulnerable Package Detected]
│
▼
[Build Fails Automatically]
│
▼
[Developer Files Exception Request]
│
├──► Approval by Tech Lead + AppSec + Legal
│
├──► Temporary Mitigation Plan Required
│
└──► Exception Reviewed Annually
If Compromised Dependency Found:
Immediate Isolation → Incident Response Triggered →
Root Cause Analysis → Mitigation & Communication
4️⃣ Governance Cycle
[Quarterly Reporting]
│
▼
[Metrics & Audit Findings]
│
▼
[Policy Review & Refinement]
│
▼
[Developer Retraining + Tool Updates]
Who Does What? RACI
RACI: R=Responsible | A=Accountable | C=Consulted | I=Informed
- R (Responsible): Performs the work to complete the activity
- A (Accountable): Ultimately answerable for the correct and thorough completion
- C (Consulted): Provides input based on expertise
- I (Informed): Kept up to date on progress or decisions
Make the RACI your own. For example, if you don’t have a role, work with management to determine the team or person to own that work. For each activity (row) there should be 1 ‘Accountable’ person/team, and only 1.
Key Requirements
Deliverables Produced by this Policy
- Automated SBOMs for every release
- Centralized Approved Dependency Catalog
- Audit-ready logs for SCA scans and exceptions
- Metrics dashboard tracking compliance and remediation
Let me know if this has been helpful for you. Have I missed anything important to you? Any suggestions on how the template can be improved? Let me know.
I share lessons from decades in software delivery — from CI/CD to architecture governance. If you’re tackling similar challenges and want a seasoned perspective, I’m available for consulting.
