We sit down with Moris Chen, ActiveState’s VP of Customer Success, to move past the legal theory and into the practical steps every development team needs to master CRA Compliance.
The EU’s Cyber Resilience Act (CRA) is no longer a distant headline. With key deadlines for vulnerability reporting and full compliance now clearly on the horizon, the pressure is mounting for engineering leaders, security teams, and developers. The law’s requirements—from 24-hour reporting of exploited vulnerabilities to ensuring security for a product’s entire lifecycle—are especially daunting for teams who rely heavily on open source software and containerized workflows.
But what does “getting compliant” actually look like on a day-to-day basis?
The legal text tells you what you must do, but the real challenge lies in the how. How do you manage vulnerabilities “without delay” when your scanner flags thousands? How do you create an accurate, living SBOM from a complex CI/CD pipeline? And how do you secure your container supply chain from end to end?
To cut through the noise and get practical answers, we sat down with Moris Chen, our VP of Customer Success. Moris and his team are on the front lines every day, talking with companies who are navigating these exact challenges. We asked him to share what they’re hearing from customers and provide a no-nonsense guide to preparing for the CRA.
Question 1: Misconceptions and Fears
Q: As VP of Customer Success, you’re on the front lines. What’s the single biggest misconception or fear you’re hearing from customers now that the Cyber Resilience Act has gone from ‘theory’ to a ‘ticking clock’?
Moris: The biggest misconception is that compliance is a binary state: you’re either compliant or you’re not. In reality, CRA readiness is a journey of continuous improvement, not a one-time checkbox. What’s causing the most concern? Teams think they need to fix everything before December 2027, and that is paralyzing. The CRA doesn’t require perfection. It requires a demonstrable process.
Question 2: Getting Started
Q: Many companies feel overwhelmed. They’re using thousands of open source components, many nested deep in their applications. What is the practical first step you recommend a development team take *today* to get a handle on their new responsibilities?
Moris: The first thing I would recommend doing is generate a complete asset inventory! Use whatever tools you have available, commercial scanners, open source tools like Syft or Trivy, even manual dependency analysis if that’s all you’ve got. You don’t need to be perfect, you just need to know what you’re actually using.
A practical workflow I recommend:
- Pick your three most critical products or services.
- Run a dependency analysis to generate a list of every open source component, including transitive dependencies.
- Export that to a spreadsheet or SBOM format(get it documented).
- Look at it. Really look at it. You’ll probably be shocked by how many components you’re using without realizing it.
- Identify the ones you didn’t know about, the ones that are end-of-life, the ones with known critical vulnerabilities.
You can’t comply with the CRA if you don’t know what you’re shipping. Start there.
Question 3: SBOMs
Q: The CRA mandates a Software Bill of Materials (SBOM). But we hear from customers that generating an SBOM is easy; maintaining it and making it accurate is the hard part. What does a ‘good’ SBOM process actually look like in practice for a CI/CD pipeline?
Moris: A good SBOM process is automated, integrated, and versioned.
- Automated: Your SBOM generation can’t be a manual step someone remembers to run every time before release. It needs to be a part of your CI/CD pipeline , every build should automatically generate an updated SBOM.
- Integrated: The SBOM reflects exactly what’s in that build, not what you think is in it, not what was in yesterday’s build. This means your SBOM tool needs to hook directly into your build process, not scan artifacts after the fact.
- Versioned: Every product release should generate its own SBOM, and store it alongside the release artifacts. If you need to investigate a vulnerability six months from now, you need to know exactly what was in version 2.3.1, not what’s in your current build.
Question 4: Handling CVEs
Q: The law’s requirement to ‘handle vulnerabilities without delay’ is a key phrase. What does this practically mean for an engineering team? How should they prioritize fixes when their scanner returns hundreds of critical vulnerabilities in their open source code?
Moris: Without delay sounds absolute, but in practice, it’s risk-based and context-dependent. The CRA doesn’t expect you to patch every CVE the moment it’s published. What it expects is that you have a defensible prioritization framework and can demonstrate you’re acting on it.
Stop relying solely on CVSS scores. A ‘critical’ vulnerability that’s not exploitable in your context is less urgent than a ‘medium’ one that’s actively being weaponized.
Prioritize based on:
- Exploitability: Is there a working exploit in the wild? Check additional resources and publicly available databases.
- Reachability: Is the vulnerable code actually called in your application? A vulnerability in a library you include but never use isn’t your top priority.
- Exposure: Is the affected component in a public-facing service or isolated behind multiple security layers?
- Patch availability: Is there a fix available? If yes, how risky is the upgrade? If not, can you mitigate it?
Question 5: Containers
Q: Let’s focus on containers. How does the CRA change how teams should think about their containerized builds? Is just scanning a ‘golden image’ in a registry enough to be compliant?
Moris: The CRA requires you to manage security throughout the entire container supply chain, from base image to application layers to runtime. The ‘golden image’ approach can work, but only if:
- Your golden images are built from verified, secure components
- You have complete SBOMs for every layer
- You have a process to rebuild and redeploy when base images are patched
- You’re monitoring what’s actually running, not just what you shipped
Think of container security like food safety. Scanning the final meal isn’t enough, you need to verify every ingredient, track where it came from, and know if any of those ingredients get recalled after you’ve served the dish.
Question 6: Reporting Deadlines
Q: That 24-hour reporting deadline for actively exploited vulnerabilities is causing a lot of anxiety. How can a manufacturer possibly know if a vulnerability in a third-party library is being exploited in the wild?
Moris: This is where external intelligence sources become critical, you can’t know this through scanning alone.
You’ll never have perfect visibility. But you can demonstrate due diligence, that you’re monitoring credible sources, acting on intelligence, and documenting your response. That’s what the CRA expects.
Question 7: Reactive vs. Proactive
Q: Given all these challenges, what’s the difference between a reactive ‘scan and patch’ approach and a proactive one? How does starting with a secure, curated catalog of open source components change a company’s entire CRA compliance posture?
Moris: In a reactive approach, teams wait for vulnerabilities to be published, scan code, patch what’s broken, and repeat.
With a proactive approach, teams start with components that are already vetted, secure, and maintained so you’re remediating exceptions rather than constantly firefighting.
Starting with a curated, secure catalog of components helps you start secure and stay secure. Instead of pulling random packages from npm, PyPI, or Maven Central where you inherit whatever vulnerabilities exist at that moment, you instead source from a catalog where:
- Components are built from source (provenance verified)
- Vulnerabilities are identified before you consume them
- Security patches are tested and validated
- SBOMs are generated automatically
At ActiveState, our catalog has 40M+ open source components that are continuously monitored, rebuilt from source when vulnerabilities are discovered, and maintained with security as a first-class concern.
Question 8: Action Plan
Q: If a CISO or Head of Engineering reading this can only get their team to do *one thing* differently this month to prepare for the CRA, what should it be?
Moris: The most important thing I would recommend they do this month is: Run a CRA readiness gap analysis!
Get your security lead, a senior developer, and someone from legal/compliance in a room and ask the below questions and document the answers honestly:
- Can we generate a complete, accurate SBOM for our flagship product right now?
- Do we know which of our open source components have unpatched critical vulnerabilities?
- Do we have a defined process for prioritizing and remediating those vulnerabilities?
- Could we report an actively exploited vulnerability to ENISA within 24 hours if we discovered it tomorrow?
- Do we have documentation that demonstrates our security-by-design practices?
