Federal agencies now treat open source software as a key security asset. CISA recommends tracking every open source component, monitoring for vulnerabilities, and regularly assessing project health throughout the software lifecycle.
Your compliance team needs the same discipline. This template provides a policy for tracking open source dependencies using Software Bill of Materials (SBOMs) and the governance structure to keep your inventory current.
Purpose of This Template
This policy outlines how your organization will:
- Maintain an inventory of all open source components in production
- Generate and update SBOMs for each application
- Monitor components for newly disclosed vulnerabilities
- Assess whether projects remain actively maintained and trustworthy
- Define ownership and escalation paths when issues arise
The template assumes you're working toward compliance with frameworks that require software inventory controls, such as PCI DSS v4.0.1 Requirement 6.3.2, NIST CSF v2.0 ID.AM-2, and SOC 2 Type II CC7.1. Even if you're not under these mandates, the policy helps you quickly answer, "What open source are we running?"
Prerequisites
Before implementing this policy, ensure you have:
- SBOM generation capability: Use build-time tools (like Syft, CycloneDX generators) or runtime analysis (like Snyk, Dependabot)
- Vulnerability database access: NIST NVD, GitHub Advisory Database, or commercial feeds
- Defined application inventory: You can't track dependencies if you don't know which applications exist
- Named owners: Every application needs a technical owner to respond to vulnerability alerts
If you're missing any of these, address them first. The policy won't work without them.
The Template
# Open Source Software Inventory and Monitoring Policy
**Effective Date**: [DATE]
**Policy Owner**: [ROLE, e.g., Director of Security Engineering]
**Review Cycle**: Quarterly
## 1. Scope
This policy applies to all software applications developed, deployed, or maintained by [ORGANIZATION NAME] that incorporate open source components, including:
- Customer-facing applications
- Internal tools and services
- Infrastructure-as-code repositories
- CI/CD pipelines and build tooling
## 2. SBOM Generation Requirements
### 2.1 Build-Time Generation
All applications MUST generate an SBOM during the build process using one of the approved formats:
- CycloneDX (JSON or XML)
- SPDX (JSON or RDF)
The SBOM MUST include:
- Component name and version
- License identifier (SPDX format)
- Direct and transitive dependencies
- Package manager and ecosystem (npm, pip, Maven, etc.)
### 2.2 Storage and Versioning
SBOMs MUST be:
- Stored in [LOCATION, e.g., artifact repository, S3 bucket with versioning]
- Tagged with application version and build timestamp
- Retained for [RETENTION PERIOD, e.g., 24 months or application EOL]
## 3. Inventory Maintenance
### 3.1 Central Registry
The [TEAM NAME, e.g., Security Engineering team] maintains a central registry of all active SBOMs at [REGISTRY LOCATION].
Application owners MUST update the registry within 5 business days of:
- Deploying a new application to production
- Releasing a version that changes dependencies
- Decommissioning an application
### 3.2 Quarterly Reconciliation
Each quarter, application owners MUST confirm their SBOM is current. Applications with SBOMs older than 90 days trigger an automatic review.
## 4. Vulnerability Monitoring
### 4.1 Automated Scanning
All components in the SBOM registry are scanned against [VULNERABILITY SOURCE, e.g., NIST NVD, GitHub Advisory Database] at least daily.
### 4.2 Severity Classification
Vulnerabilities are classified using CVSS v3.1:
- **Critical (9.0-10.0)**: Remediation plan required within 24 hours
- **High (7.0-8.9)**: Remediation plan required within 7 days
- **Medium (4.0-6.9)**: Remediation plan required within 30 days
- **Low (0.1-3.9)**: Address in next scheduled maintenance window
### 4.3 False Positive Process
Application owners may mark findings as false positives if:
- The vulnerable function is not reachable in the deployed code
- Compensating controls eliminate the risk
- The vulnerability requires preconditions that do not exist in your environment
All false positive designations MUST include written justification and are reviewed during quarterly audits.
## 5. Project Health Assessment
### 5.1 Trustworthiness Criteria
Application owners MUST assess each direct dependency quarterly for:
- **Active maintenance**: Last commit within 12 months
- **Security responsiveness**: Median time to patch critical CVEs under 30 days
- **Community health**: Multiple maintainers, documented security policy
- **License compliance**: License matches approved list
### 5.2 Remediation for Unmaintained Projects
If a dependency fails trustworthiness criteria, the application owner MUST:
1. Document the finding in [TRACKING SYSTEM]
2. Evaluate alternatives within 30 days
3. Create a migration plan or accept documented risk
## 6. Contribution Guidelines
When contributing code, documentation, or issues to open source projects:
- Do NOT include [ORGANIZATION NAME] internal hostnames, IP addresses, or architecture details
- Do NOT commit with corporate email addresses that reveal security team membership
- Do NOT reference internal ticket numbers or customer names
- Do submit security issues via the project's designated security channel, not public issues
## 7. Roles and Responsibilities
**Application Owners**:
- Generate and update SBOMs
- Respond to vulnerability alerts within SLA
- Assess project health quarterly
**Security Engineering**:
- Maintain central SBOM registry
- Configure and tune vulnerability scanning
- Audit compliance with this policy quarterly
**Compliance Team**:
- Map policy to applicable frameworks (PCI DSS, SOC 2, etc.)
- Provide evidence during audits
## 8. Exceptions
Exceptions to this policy require written approval from [ROLE, e.g., CISO] and must include:
- Business justification
- Compensating controls
- Review date (maximum 6 months)
Customization Tips
Section 2.1 (SBOM format): If you've standardized on one format, remove the other option. CycloneDX offers better tooling for vulnerability correlation if you're starting fresh.
Section 3.2 (90-day threshold): Adjust based on your release cadence. Weekly deployers might use 45 days; quarterly release teams might use 120 days.
Section 4.2 (remediation SLAs): These timelines match common compliance requirements. If you're in a regulated industry with stricter mandates, tighten them. PCI DSS v4.0.1 Requirement 6.3.2 requires you to define and follow your own timelines, so document what you can actually achieve.
Section 5.1 (12-month activity window): Some security-critical libraries update infrequently because they're stable, not abandoned. Add nuance: "Last commit within 12 months OR documented long-term support with active security response."
Section 6 (contribution guidelines): If your organization prohibits contributions entirely, replace this section with a simple statement. If you encourage contributions, add your code review requirements.
Section 7 (roles): Map these to your actual org chart. If you don't have a dedicated Security Engineering team, assign responsibilities to DevOps or the application teams themselves.
Validation Steps
After deploying the policy:
Test SBOM generation: Pick three representative applications (one in each major language/framework you use) and verify SBOMs generate correctly in CI/CD. Check that transitive dependencies appear, not just direct ones.
Verify vulnerability detection: Introduce a known vulnerable package (like an old version of Log4j) into a test application. Confirm your scanning tool flags it within your stated SLA.
Audit the registry: Two weeks after rollout, check how many applications have current SBOMs. If it's under 70%, your rollout communication failed or the process is too manual.
Review false positive rate: After the first month, calculate what percentage of findings get marked as false positives. If it's over 30%, your scanning tool needs tuning or your developers need training on proper justifications.
Run a tabletop exercise: Simulate a critical vulnerability disclosure (like a new OpenSSL CVE). Time how long it takes to identify affected applications, notify owners, and get remediation commitments. If it's longer than your policy SLA, you need better automation or clearer escalation paths.
The policy only works if you enforce it. Schedule quarterly reviews, publish metrics on SBOM coverage and remediation times, and tie compliance to performance reviews for application owners. Otherwise, it's just another document nobody reads.
