Purpose of the Template
Your dependency management policy must be robust to prevent the next supply chain incident from affecting your production environment. This template establishes governance controls for evaluating, approving, and monitoring open source dependencies. These controls could have flagged Moq version 4.20.0 before it exfiltrated developer emails from 10,356 installations.
Use this policy to:
- Define approval workflows for new dependencies and version updates
- Set automated scanning requirements to catch behavioral changes
- Establish rollback procedures when a trusted package violates its contract
- Document accountability for dependency decisions
This isn't a checkbox exercise. When a package with 475 million downloads suddenly starts sending developer data to third-party services, you need a decision framework that works at 3 AM.
Prerequisites
Before implementing this policy:
Technical requirements:
- Software Composition Analysis (SCA) tool integrated into your CI/CD pipeline (Snyk, GitHub Advanced Security, or equivalent)
- Package manager lockfiles enforced across all repositories
- Build-time scanning capability that catches code execution during installation
- Centralized dependency inventory (SBOM generation from each build)
Organizational requirements:
- Designated dependency review team (minimum: one security engineer, one senior developer)
- Defined risk tolerance for dependency age, maintainer count, and license types
- Incident response plan that includes supply chain compromise scenarios
- Authority to block builds that violate policy
If you're working toward SOC 2 Type II compliance, this policy supports CC6.8 (logical and physical access controls) and CC7.2 (system monitoring). For ISO 27001:2022, it addresses A.8.30 (outsourced development).
The Template
# Open Source Dependency Review Policy
Version: 1.0
Effective: [DATE]
Owner: [Security Engineering Team]
## 1. Scope
This policy applies to all open source packages, libraries, and frameworks incorporated into [ORGANIZATION] applications, regardless of deployment environment.
## 2. Approval Requirements
### 2.1 New Dependencies
Any package not currently in the approved dependency inventory requires review before first use.
**Review criteria:**
- [ ] Package has >1 active maintainer OR is backed by a recognized foundation/organization
- [ ] Most recent release within 12 months
- [ ] No critical or high-severity vulnerabilities in current version
- [ ] License compatible with [ORGANIZATION] license policy
- [ ] Repository shows >100 stars OR >50 dependent projects
- [ ] No history of removed versions due to security incidents
**Approval authority:**
- Standard packages: Security Engineer + Team Lead
- Packages with native code execution: Security Architect required
- Packages accessing network/filesystem at build time: CISO approval required
### 2.2 Version Updates
**Minor/patch updates:** Automatic if SCA scan passes
**Major updates:** Require review using Section 2.1 criteria
### 2.3 Expedited Review Process
For critical security patches, Security Engineer may approve immediately with post-implementation review within 48 hours.
## 3. Automated Scanning Requirements
### 3.1 Pre-Commit
- Lockfile changes trigger dependency diff report
- New dependencies blocked until approval recorded in [APPROVAL_SYSTEM]
### 3.2 Build Time
- SCA scan must complete before artifact creation
- Build fails on:
- Critical vulnerabilities (CVSS ≥9.0)
- High vulnerabilities (CVSS ≥7.0) in packages with network access
- Any dependency not in approved inventory
- Behavioral anomalies (network calls, file access during install)
### 3.3 Runtime Monitoring
- Weekly SCA rescans of production dependencies
- Automatic ticket creation for new vulnerabilities
- Monthly dependency inventory review
## 4. Behavioral Red Flags
The following behaviors in dependencies require immediate investigation:
**Build-time execution:**
- Network requests during package installation
- File system access outside package directory
- Environment variable reading beyond standard build variables
- Obfuscated or encrypted code sections
**Runtime concerns:**
- Telemetry not documented in package README
- Data transmission to undocumented endpoints
- Dynamic code loading from external sources
**Investigation procedure:**
1. Quarantine affected builds (halt deployments using this version)
2. Security Engineer reviews package source and behavior
3. If malicious: Initiate incident response, notify affected teams
4. If unclear: Contact maintainer, await clarification before proceeding
## 5. Incident Response
### 5.1 Compromised Dependency Detected
1. **Immediate (0-1 hour):**
- Block affected package version in all package managers
- Identify all applications using compromised version
- Halt builds and deployments for affected applications
2. **Short-term (1-24 hours):**
- Assess data exposure (what could the package access?)
- Roll back to last known-good version OR remove dependency
- Scan logs for indicators of compromise
- Notify compliance team if personal data potentially affected
3. **Recovery (24-72 hours):**
- Deploy fixed version to all environments
- Document lessons learned
- Update approval criteria based on incident characteristics
### 5.2 Communication
- Internal: Security team notifies affected engineering teams within 1 hour
- External: Legal/compliance determines notification requirements
- Public: No public statements without executive approval
## 6. Exceptions
All exceptions require documented business justification and compensating controls.
**Approval authority:** CISO or delegate
**Duration:** Maximum 90 days, with required re-review
**Documentation:** Exception ticket must include:
- Business justification
- Specific risks accepted
- Compensating controls implemented
- Remediation timeline
## 7. Policy Review
This policy undergoes review:
- Annually (scheduled)
- After any supply chain security incident
- When SCA tooling changes significantly
How to Customize It
Section 2.1 thresholds: Adjust the "100 stars OR 50 dependent projects" based on your risk tolerance. More conservative teams might require both conditions. Organizations with mature security programs might add "security audit completed within 24 months."
Section 2.3 approval authority: Map these roles to your actual org chart. In smaller teams, "Security Engineer" and "Security Architect" might be the same person. The key principle: build-time code execution requires elevated review because that's where Moq's exfiltration happened.
Section 3.2 CVSS thresholds: These represent a balanced starting point. If you're in a highly regulated industry, consider failing builds on CVSS ≥7.0 across the board. If you have strong runtime protections, you might accept higher thresholds with documented compensating controls.
Section 4 behavioral monitoring: Your SCA tool determines what's detectable. Snyk's build-time analysis caught Moq's email exfiltration because it monitored git config access during installation. Document what your specific tooling can detect, then set alerts accordingly.
Section 5.1 timelines: These assume 24/7 on-call coverage. Adjust to your actual response capacity, but don't pad them excessively—supply chain incidents spread fast.
The [APPROVAL_SYSTEM] placeholder: This could be Jira tickets, a dedicated GRC tool, or even a Git repository with approval records. Whatever you choose, make it auditable and searchable.
Validation Steps
Week 1: Baseline scan
Run your SCA tool against all repositories and generate your current dependency inventory. You'll likely find packages that wouldn't pass the policy—that's expected. Document these as pre-existing exceptions with remediation dates.
Week 2: Test the workflow
Have a developer propose a new dependency. Walk through the approval process end-to-end. Time how long it takes. If approval takes more than 2 business days, your criteria are probably too complex.
Week 3: Break the build
Intentionally introduce a dependency with a known critical vulnerability. Verify that your build pipeline blocks it. If it doesn't, your SCA integration needs work before this policy goes live.
Week 4: Simulate an incident
Pick a current dependency and pretend it's compromised. Execute Section 5.1 steps. Can you actually identify all affected applications within an hour? Can you roll back within 24 hours? If not, fix your dependency tracking before the next real incident.
Quarterly: Measure effectiveness
- Mean time to approve new dependencies
- Percentage of builds blocked by policy
- False positive rate on behavioral monitoring
- Number of exceptions granted vs. remediated
If more than 20% of dependency requests become exceptions, your criteria are misaligned with your actual risk tolerance. Adjust accordingly.
The Moq incident demonstrates that trust in open source maintainers isn't enough. Your policy should assume that any package—even one with 475 million downloads—might violate that trust tomorrow.
