How bifrost maps to the Cyber Resilience Act

Part 2 of 3 in the Cyber Resilience Act series.

The first post in this series gave the shape of the CRA. This one gets practical: where does a runtime-driven application security platform actually fit the regulation, and where do you still need process around it?

The short version is that the CRA is two regulations stitched together. Annex I Part I is about what the product is: its design and configuration. Annex I Part II is about what you do with it over time: vulnerability handling across the declared support period. bifrost speaks to both, but in different ways.

Annex I Part I: product properties

Part I is the secure-by-default chapter. It asks that the product provide “an appropriate level of cybersecurity,” ship without known exploitable vulnerabilities, default to a secure configuration, protect confidentiality and integrity, minimise attack surface, and record relevant internal activity.

Most of these clauses translate directly into runtime security controls.

• Secure-by-default configuration and minimised attack surface. bifrost generates a tailored AppArmor profile from the observed behaviour of each container in staging. Only what was observed is allowed; everything else is denied at the kernel level. It is not a configuration choice the user has to make. It is the default once the profile is enforced.
• No known exploitable vulnerabilities at placing on the market. bifrost ingests CycloneDX or SPDX SBOMs at build time, continuously scans against CVE feeds, and correlates each vulnerability to runtime behaviour. You ship knowing not only which CVEs are present but which are reachable from real execution paths.
• Protection of confidentiality, integrity, availability, and from unauthorised access. Enforcement happens in the kernel, via AppArmor, a Linux Security Module trusted in production for 20+ years. File access, system calls, capabilities, and signals are restricted to the allowlist. An attacker who compromises the application cannot step outside it.
• Recording and monitoring of relevant internal activity. Every blocked event is a high-fidelity log entry with pod, image, profile version, attempted action and the rule that denied it. Entries flow into Slack, Microsoft Teams, generic webhooks, and SIEMs: the audit trail Part I implicitly requires.

The clause that isn’t a bifrost feature is “provide the possibility of remediating vulnerabilities through security updates.” That belongs to your release pipeline.

Annex I Part II: vulnerability handling

Part II is more demanding because it runs across the entire support period.

• Identify and document components, including a machine-readable SBOM. bifrost stores SBOMs per service and per version, supports both CycloneDX and SPDX, and lets you upload multiple SBOMs per version when a product has separate container images or dependency sets. Combined with the CVE history tracked against each version, that is the substance of what auditors will ask to see.
• Address vulnerabilities without delay. The standard objection here is “we have thousands of CVEs; we cannot patch all of them at once.” CRA does not actually ask you to. It asks you to address them, which includes mitigation and informed deprioritisation. bifrost’s reachability analysis lets you say, on the record, “this CVE exists in a code path that has never executed and is blocked by the runtime profile.” That is a defensible disposition. The vulnerabilities that are reachable get the engineering attention they need, and they do so within a queue that is small enough to actually move.
• Apply effective and regular tests and reviews. Profiles regenerate with every deployment. CVE assessments update continuously. There is no quarterly scan window where new risk accumulates unseen.
• Coordinated vulnerability disclosure policy and information sharing. This is the part of Annex I Part II where tooling supports but does not replace process. bifrost gives you the technical artefacts; you still need a published policy, an intake channel, and a disclosure cadence.

Article 13 and Annex VII: technical documentation and the support period

Article 13 obliges you to maintain technical documentation that demonstrates conformity, and to declare a support period during which Part II obligations apply. Annex VII spells out what the documentation must contain.

The pile is dominated by four things: the SBOM, the cybersecurity risk assessment, the description of security measures, and evidence those measures work. bifrost contributes directly to three of the four. SBOMs per version are stored. The runtime profile is the description of security measures, and unlike a paragraph in a policy document, it is enforced. The blocked-event log and continuous CVE timeline are the evidence those measures work. The risk assessment is still a human document, but it becomes easier to write when you can quote exposed system calls, network egress patterns, and reachable CVE counts instead of guessing.

Article 14: reporting actively exploited vulnerabilities

From 11 September 2026, the clock starts. An actively exploited vulnerability triggers a 24-hour early warning, a 72-hour main notification, and a 14-day final report once a corrective measure is available. Severe incidents follow the same 24h/72h pattern with a one-month final report.

bifrost contributes to the detection and evidence halves of that workflow. A runtime violation in production is, by definition, evidence that a vulnerability has been actively exploited, or that an attempt is being made. The blocked-event stream tells you what was attempted, on which versions of which services, in which environments, with which mitigation already in place. That is most of what the Single Reporting Platform fields ask for. bifrost does not submit on your behalf today, but it gives the on-call something to send.

What still belongs to process

Three things are not bifrost’s job: declaring and tracking the support period, running the coordinated vulnerability disclosure process end to end, and submitting the actual notifications to the ENISA Single Reporting Platform. These belong outside the runtime layer, usually solved with policy, a small internal portal, and a defined on-call workflow.

In the final post in this series, we look at what changes for a security team that runs this way.

Read next: Part 3, The outcomes of running bifrost in a CRA world.