CRA Compliance Template for Open Source Dependencies

The EU Cyber Resilience Act (CRA) imposes a five-year vulnerability management obligation on manufacturers using open source components in their products. If your team builds commercial software with open source libraries, you need a documented process for tracking, patching, and coordinating with upstream maintainers. Only 41% of manufacturers expect to be fully compliant by the December 2027 deadline.

This template provides a framework for managing these relationships. It's designed for compliance teams and engineering managers to demonstrate CRA readiness without overhauling how your team works with open source.

Purpose of the Template

This template serves as a coordination agreement between your organization and the open source projects you depend on. It documents:

• The components you're using and in which products
• Your vulnerability notification preferences
• How you'll contribute security fixes upstream
• Your support timeline commitments

The CRA requires manufacturers to fix vulnerabilities in their open source dependencies for up to five years after product release. You need more than just a package.json file; you need a documented relationship with maintainers.

Prerequisites

Before customizing this template, ensure you have:

1. An SBOM for each product: You can't manage dependencies you haven't inventoried. Generate a CycloneDX or SPDX SBOM from your build pipeline.

2. Identified critical dependencies: Focus on components that handle authentication, cryptography, network protocols, or data parsing.

3. Internal ownership assignments: Assign someone on your team to monitor each critical dependency's security advisories and coordinate patches.

4. A vulnerability disclosure process: You need a security.txt file and a documented process for receiving and triaging reports. If you don't have this, start with RFC 9116.

The Template

# Open Source Dependency Coordination Agreement

**Manufacturer:** [Your Company Name]  
**Product(s):** [Product name(s) and version range]  
**Dependency:** [Library name and version range]  
**Upstream Project:** [Project URL and primary contact]  
**Internal Owner:** [Name and email]  
**Agreement Date:** [Date]  
**Review Cycle:** [Quarterly/Semi-annual]

## 1. Dependency Usage

We incorporate [library name] in the following products:

- [Product A] v[X.Y] - [Brief description of how it's used]
- [Product B] v[X.Y] - [Brief description of how it's used]

**Distribution model:** [Embedded/Dynamically linked/Containerized]  
**User-facing functionality:** [Yes/No - brief explanation]

## 2. Security Communication

**Vulnerability notifications:**  
We monitor: [GitHub Security Advisories/Mailing list/Other]  
Preferred contact method: [Email/Private issue/Security mailing list]  
Response SLA: [24 hours for critical, 72 hours for high]

**Our disclosure timeline:**  
We commit to coordinated disclosure with [30/60/90] day embargo periods for vulnerabilities we discover in your project.

**Security contact:**  
Primary: [[email protected]]  
Escalation: [[email protected]]

## 3. Contribution Commitments

**Security patches:**  
When we patch a vulnerability in your project, we commit to:
- Submit the patch upstream within [timeframe]
- Include test cases demonstrating the fix
- Provide detailed vulnerability analysis if not already public

**Maintenance contributions:**  
We will contribute [X hours per quarter / specific features] to:
- [Specific maintenance areas: CI/CD, documentation, test coverage]

**Funding:**  
[We participate in GitHub Sponsors/OpenSSF Alpha-Omega/Other program]  
OR  
[We're evaluating funding options and will revisit by [date]]

## 4. Support Timeline

**Product support period:** [5 years from release date per CRA requirements]  
**Dependency version policy:** We will upgrade to new versions within [timeframe] of release, or maintain security patches for the version we ship.

**End-of-life notification:**  
If we discontinue a product, we will notify you [90 days] in advance and clarify our ongoing security obligations.

## 5. Compliance Artifacts

We maintain the following documentation for CRA compliance:

- SBOM updated with each product release
- Vulnerability response log (internal)
- Patch deployment timeline (internal)
- Security testing results for dependency integration

We can provide attestation of our security practices upon request.

## 6. Review and Updates

We will review this agreement [quarterly/semi-annually] and update it when:
- We add new products using this dependency
- The dependency's security contact changes
- Our internal ownership changes
- Regulatory requirements change

**Next review date:** [Date]

---

**Manufacturer signature:** [Name, Title, Date]  
**Upstream acknowledgment (optional):** [Name, Title, Date]

Customization Guidance

Section 1 (Dependency Usage): Be specific about how you're using the library. For example, "We use libcurl for all HTTPS requests in our API gateway" is clearer than "We use libcurl for network operations." This helps maintainers understand the security implications of changes.

Section 2 (Security Communication): Align with the project's existing security process. If they use GitHub Security Advisories, don't ask them to email you. If they lack a documented process, suggest one and offer to help implement it.

Section 3 (Contribution Commitments): Be realistic. Promising 40 hours per quarter of maintenance work when you have a small team isn't sustainable. Start with what you can deliver, then increase it. Given that 66% of manufacturers are still unfamiliar with the CRA, being specific about your commitments sets you apart.

Section 4 (Support Timeline): The five-year obligation is non-negotiable under CRA. If you're shipping embedded devices with longer lifespans, adjust accordingly. Document your version upgrade policy, will you backport security fixes to the version you shipped, or require customers to upgrade?

Section 5 (Compliance Artifacts): You don't need to share your internal vulnerability response logs with maintainers, but you should document that they exist. This section is primarily for your compliance team's records.

Validation Steps

1. Legal review: Have your legal team review the contribution commitments and support timeline sections. Some organizations have policies about contributing to projects with specific licenses.

2. Engineering review: Your security team and the engineers who work with this dependency should confirm the commitments are achievable.

3. Maintainer feedback: Send the draft to the upstream project's security contact. Ask, "Does this match how you prefer to work with commercial users?" Many maintainers appreciate manufacturers who document their relationship rather than treating open source as a free support desk.

4. Tooling integration: Add the internal owner and review dates to your vulnerability management system. If you're using Dependabot, Snyk, or similar tools, configure alerts to route to the right person.

5. Audit trail: Store signed copies in your compliance documentation system. When auditors ask, "How do you manage open source security?" you can provide the folder of coordination agreements.

This template won't make CRA compliance easy, but it offers a documented starting point for the manufacturer-maintainer relationship the regulation expects. Adapt it to your organization's size and risk tolerance, then use it consistently across your critical dependencies.

EU Cyber Resilience Act