Your open source dependencies won't document themselves. Yet many engineering teams treat the EU Cyber Resilience Act like it's someone else's problem until their first audit request arrives.
The CRA fundamentally changes how you manage open source components. It's not just about scanning for CVEs anymore. You're now responsible for maintaining an exploitability assessment for every vulnerability in your supply chain, tracking maintainer accountability, and proving you have a process for responding to security disclosures.
Here's where teams consistently stumble, and how to fix it before your compliance manager asks questions you can't answer.
Why These Mistakes Keep Happening
The CRA doesn't map cleanly to existing security workflows. You've spent years building processes around vulnerability scanning and patch management. The CRA demands something different: continuous documentation of your decision-making process, evidence that you evaluated each vulnerability's exploitability, and a defensible audit trail showing you didn't just ignore findings.
Most teams discover these gaps when they're asked to prove compliance retroactively. By then, you're reconstructing decisions from memory and hoping your Git history tells a coherent story.
Mistake 1: Treating VEX Documents as Optional
Why it happens: VEX (Vulnerability Exploitability eXchange) feels like extra paperwork. Your scanner already flags vulnerabilities. Why add another documentation layer?
The consequence: When an auditor asks why you shipped code containing CVE-2024-XXXXX, "it's not exploitable in our context" isn't sufficient. Without a VEX statement documenting your analysis at the time you made that decision, you have no evidence that you performed due diligence. You're exposed to liability claims and potential regulatory action.
The fix: Generate VEX documents automatically as part of your build pipeline. When your scanner identifies a vulnerability that you determine isn't exploitable in your deployment context, emit a VEX statement explaining why. Tools like Gemara can integrate this into your existing workflow without requiring manual documentation for every finding. Store these statements alongside your SBOMs. Your future self (and your auditors) will thank you.
Mistake 2: Assuming Your SBOM Covers CRA Requirements
Why it happens: You're already generating Software Bills of Materials. That should be enough, right?
The consequence: SBOMs inventory components. The CRA requires you to demonstrate that you assessed each component's security posture and have a plan for addressing vulnerabilities. An SBOM without accompanying security metadata is like a parts list without assembly instructions. You can't prove you made informed decisions about what you shipped.
The fix: Pair every SBOM with security attestations. When you add a dependency, document:
- Your assessment of the maintainer's security practices
- Whether the project has a documented vulnerability disclosure process
- Your plan for monitoring security advisories
- Your rollback strategy if a critical vulnerability emerges
Use Sigstore to cryptographically sign these attestations. This creates an immutable record that you performed your due diligence at the time you made the decision, not after someone questioned it.
Mistake 3: Ignoring the Maintainer Liability Shift
Why it happens: You're downstream. Security is the upstream maintainer's responsibility, isn't it?
The consequence: The CRA makes you accountable for security issues in your dependencies, regardless of whether you wrote the code. If a vulnerability in an open source library you depend on causes a security incident, you can't deflect blame to the maintainer. You're responsible for your dependency choices and your response time.
The fix: Maintain a risk register for your critical dependencies. For each one, document:
- Maintainer responsiveness to past security issues
- Average time-to-patch for vulnerabilities
- Whether the project has commercial support options
- Your contingency plan if the maintainer abandons the project
Review this register quarterly. When a high-risk dependency shows declining maintenance activity, start evaluating alternatives before you're forced to make an emergency decision.
Mistake 4: Using AI Tools Without Understanding Their Security Implications
Why it happens: AI-powered code assistants increase developer velocity. The security team can evaluate them later.
The consequence: AI tools introduce two distinct risk vectors. First, they may suggest vulnerable code patterns or outdated libraries. Second, they become part of your supply chain. If an AI model is compromised or manipulated, it could inject vulnerabilities across your entire codebase. You're now responsible for securing both the tool and its outputs.
The fix: Treat AI coding assistants as untrusted input sources. Implement:
- Automated security scanning of all AI-suggested code before it reaches production
- A whitelist of approved AI tools with documented security assessments
- Regular audits of what your AI tools are suggesting (track and review rejected suggestions, not just accepted ones)
- Training for developers on recognizing AI-generated security anti-patterns
Document your AI tool evaluation process. When an auditor asks how you ensure AI-suggested code meets security requirements, you need a better answer than "we trust the model."
Mistake 5: Waiting for Regulatory Enforcement to Start
Why it happens: The CRA's enforcement timeline seems distant. You'll adapt when you have to.
The consequence: Retroactive compliance is expensive and error-prone. You can't reconstruct your security decision-making process from six months ago with any reliability. You'll spend audit prep time explaining gaps instead of demonstrating controls.
The fix: Implement CRA-aligned processes now:
- Add VEX generation to your CI/CD pipeline this sprint
- Start signing your SBOMs and security attestations
- Build your dependency risk register before your next quarterly review
- Document your AI tool security evaluation process
These aren't future requirements. They're operational security practices that make your team more effective today. The CRA just makes them mandatory.
Prevention Checklist
Weekly:
- Review new dependencies added to your projects
- Generate VEX statements for vulnerability scanner findings you're not patching
- Update your dependency risk register for any security advisories
Monthly:
- Audit AI tool suggestions that were rejected by developers
- Verify all SBOMs have corresponding security attestations
- Review maintainer responsiveness for critical dependencies
Quarterly:
- Re-evaluate high-risk dependencies for alternatives
- Test your vulnerability disclosure response process
- Update your AI tool security assessment documentation
Before each release:
- Confirm all components have current VEX statements or patches
- Sign your SBOM with Sigstore
- Document any accepted security risks with business justification
The CRA doesn't require perfection. It requires evidence that you're making informed security decisions and can defend them. Start building that evidence trail now, while you still have time to do it deliberately.
