25.3 Open Source Consumption Policies¶

Every modern software organization uses open source—the question is whether that use is governed or ungoverned. Without explicit policies, developers make independent decisions about what to include, leading to inconsistent security practices, license compliance gaps, and accumulation of unmaintained dependencies. A developer who adds a convenient library today may create a vulnerability response burden for years to come.

Open source consumption policies establish organizational standards for how open source is evaluated, approved, and managed. Effective policies balance developer productivity with security and legal requirements, providing clear guidance without creating friction that drives workarounds. The goal isn't to restrict open source use—it's to ensure that use is informed, intentional, and manageable.

This section provides guidance on developing and implementing open source consumption policies that work in practice.

Defining Acceptable Use of Open Source¶

Policies begin with scope: what constitutes open source, where can it be used, and what general principles apply?

Policy framework structure:

# Open Source Consumption Policy

# 1. Purpose and Scope
   - What this policy covers
   - Who must follow it
   - How it relates to other policies

## 2. Definitions
   - Open source software
   - Dependencies (direct, transitive)
   - License categories
   - Risk classifications

## 3. General Principles
   - Open source is permitted and encouraged
   - Use must be intentional and documented
   - Security and license compliance are required
   - All dependencies are subject to this policy

## 4. Approval Requirements
   - What requires approval
   - Approval workflow by risk level
   - Roles and responsibilities

## 5. Prohibited Components
   - Prohibited licenses
   - Prohibited packages
   - How prohibitions are determined

## 6. Exception Process
   - When exceptions are available
   - How to request exceptions
   - Approval authority
   - Documentation requirements

## 7. Ongoing Obligations
   - Vulnerability monitoring
   - Update requirements
   - License compliance

## 8. Enforcement
   - How policy is enforced
   - Consequences of violations
   - Tooling and automation

Scope definition:

General principles to establish:

## General Principles

1. OPEN SOURCE IS WELCOME. This organization encourages responsible 
   use of open source software. Open source enables productivity, 
   innovation, and collaboration.

2. USE MUST BE INTENTIONAL. Every open source component should be 
   deliberately chosen, not accidentally included. Developers should 
   understand what they're adding and why.

3. SECURITY IS REQUIRED. Open source components must be evaluated 
   for security and monitored for vulnerabilities throughout their 
   use. Components with unaddressed critical vulnerabilities may 
   not be used in production.

4. LICENSE COMPLIANCE IS REQUIRED. All open source use must comply 
   with applicable license terms. Some licenses are incompatible 
   with our business model and are prohibited.

5. TRANSITIVE DEPENDENCIES COUNT. This policy applies to all 
   components, including those brought in as dependencies of 
   dependencies.

Approval Processes for New Dependencies¶

Not every dependency needs the same scrutiny. Approval workflows should be proportional to risk.

Approval workflow design:

Tiered approval based on risk:

Automated approval criteria (low-risk fast path):

# Example automated approval criteria
auto_approve:
  license:
    - `MIT`
    - `Apache-2.0`
    - `BSD-2-Clause`
    - `BSD-3-Clause`
    - `ISC`
  security:
    max_critical_vulnerabilities: 0
    max_high_vulnerabilities: 0
    max_age_of_high_vulnerability_days: 30
  maintenance:
    min_commits_last_year: 1
    min_contributors: 1
    max_years_since_release: 2
  adoption:
    min_weekly_downloads: 1000
    min_dependent_packages: 10

Manual review triggers:

Require human review when: - License is copyleft (GPL, LGPL, AGPL) - License is not in approved list - Critical or high vulnerabilities exist - Package is new (< 6 months old) - Package has very few users (< 100 downloads/week) - Package has no recent maintenance (> 2 years) - Package was recently transferred or ownership changed - Package name is similar to popular package (potential typosquatting)

Approval workflow implementation:

Developer adds dependency
        │
        ▼
┌───────────────────┐
│ Automated checks  │
│ (SCA tool scans)  │
└─────────┬─────────┘
          │
    ┌─────┴─────┐
    │           │
    ▼           ▼
 Passes      Flags
    │        raised
    │           │
    ▼           ▼
Auto-approve  Manual review
              required
                  │
            ┌─────┴─────┐
            │           │
            ▼           ▼
         Approved    Denied
            │           │
            ▼           ▼
         Proceed    Exception
                    process

Roles in approval process:

Prohibited Licenses and Packages¶

Some licenses and packages should not be used. Clear prohibition criteria prevent case-by-case debates.

License prohibition criteria:

Example license policy:

## License Categories

### Approved (no additional review)
MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, Unlicense, CC0-1.0

### Conditionally Approved (review required)
LGPL-2.1, LGPL-3.0, MPL-2.0, EPL-2.0
- May be used with documented compliance plan

### Prohibited
GPL-2.0, GPL-3.0, AGPL-3.0, SSPL
- May not be used in distributed products
- May not be used in customer-facing services (AGPL/SSPL)
- Exceptions require VP-level approval

### Requires Investigation
Any license not listed above, no license, custom license
- Must be reviewed by Legal/OSPO before use

Package prohibition criteria (risk-based):

Maintaining prohibition lists:

• Subscribe to threat intelligence feeds for malicious packages
• Integrate with security tooling that maintains block lists
• Review and update lists quarterly
• Document rationale for each prohibition
• Establish process for challenging prohibitions

Exception Handling and Risk Acceptance¶

No policy covers every situation. Exceptions allow legitimate edge cases while maintaining accountability.

Exception process:

## Exception Request Process

1. DETERMINE IF EXCEPTION IS NEEDED
   - Is the component actually prohibited, or just flagged for review?
   - Can an alternative component satisfy the requirement?
   - Is the use case temporary or permanent?

2. DOCUMENT THE REQUEST
   Complete exception request form including:
   - Component name and version
   - Policy provision requiring exception
   - Business justification
   - Risk assessment
   - Proposed mitigations
   - Requested duration

3. SUBMIT FOR APPROVAL
   - License exceptions: Legal/OSPO approval required
   - Security exceptions: Security team approval required
   - Both: Both approvals required

4. APPROVAL AUTHORITY
   - Low risk exceptions: Manager level
   - Medium risk exceptions: Director level
   - High risk exceptions: VP/CISO level

5. DOCUMENTATION AND TRACKING
   - Approved exceptions recorded in central registry
   - Expiration date set (max 12 months for security exceptions)
   - Renewal review required before expiration

6. MONITORING
   - Exceptions monitored for continued validity
   - Changed circumstances may invalidate exception

Exception request template:

## Open Source Exception Request

**Date**: [Date]
**Requestor**: [Name, Team]
**Manager**: [Name]

### Component Information
- Package name: 
- Version: 
- Package URL: 
- License: 

### Policy Exception Required
- [ ] License (specify which license and policy provision)
- [ ] Security (specify vulnerability or security concern)
- [ ] Maintenance (specify maintenance concern)

### Business Justification
Why is this component needed? What alternatives were considered?

### Risk Assessment
What risks does this exception create? Who is affected?

### Proposed Mitigations
What controls will reduce the risk?

### Duration
How long is this exception needed?
- [ ] Permanent
- [ ] Time-limited: [End date and planned resolution]

### Approval
- [ ] Security: _____________ Date: _______
- [ ] Legal/OSPO: _____________ Date: _______
- [ ] Management: _____________ Date: _______

Conditions for exception approval:

• Clear business justification exists
• Alternatives were genuinely considered
• Mitigations reduce risk to acceptable level
• Duration is defined (prefer time-limited)
• Monitoring is in place
• Renewal review is scheduled

Policy Communication and Training¶

Policies that developers don't know about won't be followed. Communication and training are essential.

Communication approaches:

Training content:

1. Awareness (all developers, 30 min):
2. Why we have this policy
3. What it requires (high level)
4. Where to find details

5. Who to ask for help

6. Practical (developers adding dependencies, 1 hour):

7. How to evaluate dependencies
8. How approval process works
9. Using tooling effectively

10. Common scenarios and solutions

11. Role-specific (approvers, 2 hours):

12. Evaluation criteria in depth
13. Making approval decisions
14. Documenting rationale
15. Exception handling

Reducing friction through communication:

• Explain the "why" behind requirements
• Provide examples of what's typically approved
• Offer quick paths for common cases
• Make help easy to find
• Respond quickly to questions

Organizations that frame policies around enablement rather than restriction typically see better adoption. Leading with "here's how this makes your job easier" rather than "here's what you're not allowed to do" creates a more collaborative relationship with development teams.

Enforcement Mechanisms and Tooling¶

Policy without enforcement is suggestion. Tooling makes enforcement practical and consistent.

Tooling for enforcement:

Enforcement point strategy:

Development     Pull Request     Build          Deploy
    │               │              │              │
    ▼               ▼              ▼              ▼
┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│IDE scan │    │PR checks│    │CI gates │    │Admission│
│(advise) │    │(warn)   │    │(block)  │    │control  │
└─────────┘    └─────────┘    └─────────┘    └─────────┘
   Soft           Soft           Hard           Hard

Progressive enforcement:

Handling existing violations:

For organizations implementing policy on existing codebases:

1. Baseline scan: Document current state
2. Triage: Categorize violations by severity
3. Remediation plan: Prioritize critical issues
4. Grandfather with timeline: Allow existing violations temporarily with remediation deadlines
5. Prevent new violations: Enforce policy on new additions immediately
6. Track progress: Report on remediation status

Policy Template Elements¶

Starting from scratch is difficult. Templates provide structure to customize.

Essential policy elements:

# Open Source Software Policy

## 1. Purpose
This policy establishes requirements for the evaluation, approval, 
and management of open source software at [Organization].

## 2. Scope
This policy applies to all open source software used in:
- Products delivered to customers
- Internal applications and tools
- Development and build infrastructure
- [Other scope as appropriate]

## 3. Roles and Responsibilities
- **Developers**: Evaluate, request approval, maintain dependencies
- **Team Leads**: Approve medium-risk requests, ensure compliance
- **Security Team**: Review security concerns, maintain tooling
- **Legal/OSPO**: Review license concerns, maintain approved lists
- **Management**: Approve exceptions, ensure resources

## 4. Approved Licenses
[List of approved licenses and conditions]

## 5. Prohibited Licenses
[List of prohibited licenses and rationale]

## 6. Approval Process
[Workflow description, approval criteria, timelines]

## 7. Security Requirements
- No components with unpatched critical vulnerabilities
- Monitor for new vulnerabilities continuously
- Remediate per vulnerability SLAs
- [Additional security requirements]

## 8. Exception Process
[How to request exceptions, approval authority, documentation]

## 9. Enforcement
[How policy is enforced, tooling, consequences]

## 10. Policy Maintenance
- Reviewed annually
- Updated as needed for new threats or business requirements
- Questions directed to [contact]

Effective Date: [Date]
Policy Owner: [Role/Name]

Recommendations¶

We recommend the following approach to open source consumption policies:

1. Start with principles, not prohibitions: Lead with why open source is valuable and how to use it well. Policies framed as enablement get better adoption than those framed as restriction.

2. Tier approval requirements to risk: Not every dependency needs the same scrutiny. Automate approval for low-risk components; focus human review on high-risk cases.

3. Be specific about prohibited licenses: Vague guidance creates inconsistency. Clearly categorize licenses as approved, conditionally approved, or prohibited.

4. Create workable exception processes: Exceptions will be needed. Make the process clear, documented, and appropriately authorized—not so burdensome that developers work around it.

5. Communicate and train effectively: Policies developers don't understand won't be followed. Invest in communication, training, and accessible documentation.

6. Enforce through tooling: Manual policy enforcement doesn't scale. Integrate policy checks into the development workflow through SCA tools, registry controls, and CI/CD gates.

7. Start with monitoring before blocking: When implementing new policies, begin with visibility to understand the landscape before enforcement that disrupts development.

8. Review and update regularly: The open source landscape changes. Review policies annually and update when new threats, licenses, or business requirements emerge.

Effective open source policies enable responsible use rather than preventing use entirely. The goal is informed, intentional consumption of open source—capturing its benefits while managing its risks.