Most enterprises use open source extensively but govern it poorly. Developers pull in dependencies freely while legal worries about license exposure and security worries about unvetted components. The result is tension, shadow IT in dependency form, and risk that nobody can quantify.
An open-source policy bridges this gap. Done right, it enables developers to use open source confidently while giving the organization visibility and control. Done wrong, it becomes a bureaucratic gate that developers route around. Here is a template that targets the sweet spot.
Why You Need a Policy
Even if your organization is not in a regulated industry, you need a documented open-source policy for:
- License compliance. Some open-source licenses (AGPL, SSPL) can impose obligations on your proprietary code. Without a policy, developers might unknowingly introduce license conflicts.
- Security governance. A policy establishes standards for vetting, monitoring, and remediating open-source vulnerabilities.
- Procurement and M&A. Buyers and investors want to see that open-source risk is managed. An undocumented approach raises red flags during due diligence.
- Regulatory requirements. Frameworks like NIST SSDF, SOC 2, and ISO 27001 expect documented controls around third-party software.
The Policy Template
Section 1: Purpose and Scope
State the policy's intent clearly:
This policy governs the selection, approval, use, and ongoing management of open-source software components within [Organization Name]. It applies to all software developed internally, all contractor-developed software, and all acquired software that will be deployed in production environments.
Define what counts as "open source" for your organization. The standard definition from the Open Source Initiative is a good baseline, but also clarify edge cases: source-available licenses, community editions of commercial products, and open-source components embedded in commercial libraries.
Section 2: License Classification
Categorize licenses by risk level:
Approved (use freely):
- MIT
- Apache 2.0
- BSD 2-Clause and 3-Clause
- ISC
- CC0 / Public Domain
Conditional (requires review):
- LGPL 2.1 and 3.0 (review linking approach)
- MPL 2.0 (review file-level obligations)
- EPL 2.0 (review compatibility with your license stack)
Restricted (requires legal approval):
- GPL 2.0 and 3.0
- AGPL 3.0
- SSPL
- EUPL
- Any license with network-use disclosure requirements
Unknown or Custom Licenses: Require legal review before use.
This classification should be enforced in your SCA tooling. When a developer adds a dependency with an AGPL license, the policy dictates that legal reviews it before the code merges.
Section 3: Component Selection Criteria
When evaluating a new open-source component, developers should assess:
Security health:
- Does the project have a documented security policy (SECURITY.md)?
- How quickly does the project respond to reported vulnerabilities?
- Are there unaddressed critical vulnerabilities in the current version?
- Does the project use dependency scanning and SAST in their CI?
Maintenance vitality:
- When was the last release?
- How many active maintainers?
- What is the issue response time?
- Is the project part of a foundation or backed by an organization?
Community and adoption:
- Download counts and usage metrics.
- Number of dependent projects.
- Quality of documentation.
- Availability of commercial support options.
Technical fit:
- Does it do one thing well, or is it a sprawling framework bringing hundreds of transitive dependencies?
- Is it actively maintained for the language version and platform you use?
- What is the migration path if you need to replace it?
For critical components (authentication libraries, cryptographic implementations, database drivers), require a formal evaluation document. For utility libraries, a lightweight checklist is sufficient.
Section 4: Approval Workflow
Tier 1: Auto-approved. Components with approved licenses, more than 1,000 GitHub stars, active maintenance within the last 6 months, and no known critical vulnerabilities. These can be added without review.
Tier 2: Team lead approval. Components with conditional licenses, fewer community signals, or non-critical known vulnerabilities. The team lead reviews the selection criteria and documents the decision.
Tier 3: Security and legal review. Components with restricted licenses, known critical vulnerabilities with no patch, custom licenses, or components that will handle sensitive data (authentication, cryptography, data processing).
Automate tier classification where possible. Your SCA tool should flag tier 2 and 3 components during the PR review process.
Section 5: Vulnerability Management
Define how vulnerabilities in open-source dependencies are handled:
Detection: All production codebases must have continuous dependency scanning enabled. Scans must run on every build and on a weekly schedule for monitoring drift.
Remediation SLAs:
| Severity | Public-Facing | Internal | |----------|--------------|----------| | Critical | 48 hours | 7 days | | High | 7 days | 14 days | | Medium | 30 days | 60 days | | Low | 90 days | Next quarter |
Exception process: When remediation is not feasible within the SLA (no patch available, breaking changes required), a risk exception must be documented including:
- The specific vulnerability and affected component.
- Why remediation cannot meet the SLA.
- Compensating controls in place.
- Planned remediation date.
- Risk owner sign-off.
Exceptions must be reviewed quarterly.
Section 6: Inventory and Tracking
The organization must maintain a current inventory of all open-source components in use. This inventory must include:
- Component name, version, and license.
- Which projects use the component.
- Whether the component is direct or transitive.
- Known vulnerabilities.
SBOMs must be generated for every production release and stored for the lifecycle of that release plus two years.
Section 7: Contributing to Open Source
If the organization allows employees to contribute to open-source projects:
- Contributions must not include proprietary code, algorithms, or trade secrets.
- Contributions to projects with CLA (Contributor License Agreement) require legal review.
- Employees should contribute on company time using company accounts, not personal accounts, for work-related contributions.
Section 8: Compliance and Auditing
The security team will audit open-source policy compliance quarterly, checking:
- Percentage of projects with active dependency scanning.
- Vulnerability remediation SLA compliance rates.
- License compliance status.
- SBOM generation coverage.
Audit findings are reported to the CISO and engineering leadership.
Implementation Tips
Roll out gradually. Enforce the policy on new projects first, then progressively apply it to existing codebases. Demanding immediate compliance across hundreds of legacy projects is a recipe for mass exception requests.
Automate enforcement. Every policy requirement that can be checked by a tool should be. Manual policy compliance does not scale.
Keep it living. Review and update the policy annually at minimum. License interpretations evolve, new license types appear, and your organization's risk appetite changes.
Communicate the "why." Developers follow policies they understand. A lunchtime talk explaining why AGPL matters or how a dependency vulnerability led to an incident is more effective than a PDF on the intranet.
How Safeguard.sh Helps
Safeguard.sh operationalizes your open-source policy by automating license classification, enforcing vulnerability remediation SLAs through policy gates, and maintaining a real-time inventory of every open-source component across your projects. It turns your policy document into executable rules that are checked on every build, so compliance is continuous rather than periodic. For teams implementing their first open-source policy, Safeguard.sh provides the enforcement engine that makes the policy meaningful.