For compliance and GRC teams
Continuous enforcement, continuous proof
bifrost enforces a security profile for every workload at the kernel. That enforcement produces its own record: profiles, violation logs, SBOM histories and CVE timelines, generated continuously rather than assembled once per audit. One record, and it maps to the requirements in every framework you answer to.
What you're up against
Evidence assembled by hand, once per audit, across a growing pile of frameworks. These are the ones your bifrost evidence maps to.
SOC 2
Trust services criteria
PCI DSS
v4.0 requirements
HIPAA
Technical safeguards
ISO 27001
Annex A controls
GDPR
Article 32 security
NIST CSF
Protect and detect
NIS2
Art. 21 measures
DORA
ICT risk management
CRA
Cyber Resilience Act
Example: the Cyber Resilience Act
Vulnerability handling under the CRA, evaluated on every build
The CRA asks software makers to know their components, keep an SBOM, find and fix vulnerabilities without delay, test their products regularly, and report actively exploited vulnerabilities within 24 hours. Each of those is a question bifrost evaluates continuously, from what it already knows about every build.
An SBOM per build, re-scanned through the day, answers the inventory requirement. A verdict on every CVE, with the reachable ones first, answers remediation without delay. Profiles learned in pre-production and enforced in production answer regular testing and secure-by-default. And when a CVE is exploited in the wild, the exposure report for the notification is already there.
Evidence, not certification: bifrost produces the record. How it maps to each obligation is a decision for you and your auditor.
What changes with bifrost
bifrost is not a compliance tool. It enforces a security profile per workload at the kernel, and the evidence that enforcement produces maps to requirements that several of your frameworks share. One control, enforced once, feeds many frameworks.
A security profile per workload, enforced at the kernel
bifrost learns what each workload does, the syscalls, files, network connections and capabilities it uses doing its job, and generates its profile from that. In production the profile is enforced at the kernel: anything outside it is blocked. A fresh profile with every build, so nothing rots.
Every CVE with a verdict, in runtime context
An SBOM per workload, re-scanned through the day, and every CVE verdicted against what actually runs: reachable, mitigated by the profile, or never loaded. Up to 90% fewer CVEs to triage, and every verdict keeps its evidence.
Drift detection and change management
Runtime behaviour is compared with the approved profile continuously. A new binary, an unexpected file write, a connection that was never part of the job: each is reported as drift with its deployment context, and blocked once the workload is in enforce mode.
Deviations blocked and reported, with their context
In enforce mode, anything outside the profile is blocked at the kernel, and every blocked action becomes an event with its context: pod, image, profile, the attempted action and what was denied. It feeds your SIEM and alerting, so nothing reaches a human without its context.
Evidence that maps to your frameworks
One view of the evidence enforcement produces, set against the requirements in your frameworks. Export profiles, violation logs, SBOM histories and CVE timelines whenever an auditor, a regulator or a customer asks.
Third-party software and the supply chain
The same profiles apply to vendor and third-party workloads. With the SBOM alongside, you know what third-party code is running, what it is allowed to do, and which of its CVEs are reachable in your environment.
What you can show
Profiles, violation logs, SBOM histories and CVE timelines are a consequence of enforcement, not something assembled by hand before an audit. The order matters: enforcement comes first, and the evidence follows from it.
Profiles are documented
Every workload's profile is stored as code: a readable statement of what it is allowed to do, versioned with every build.
Enforcement is automatic
Profiles are enforced at the kernel on every deploy, with no manual step to forget. The one decision left to you is the switch from observe to enforce.
Everything is logged
Every blocked action and every deviation is recorded with its context and timestamp, from the first deploy onwards.
Reports are ready
Export the evidence against the requirements in your frameworks, whenever the auditor or the regulator asks.
Sample audit evidence
Illustrative example
# Runtime profile for payment-service
Profile: payment-service-v2.3.1
Status: Enforcing
Last updated: 2025-02-04T10:30:00Z
# Blocked actions (last 24h)
Blocked: 47 unauthorised syscalls
Blocked: 12 unauthorised file access
Blocked: 3 unauthorised network connections
# Maps to
SOC 2 CC6.1: evidence attached
PCI DSS 7.1: evidence attached
HIPAA §164.312(a): evidence attached
Framework coverage
The evidence one enforced control produces, set against the requirements several frameworks share.
SOC 2 and ISO 27001
Evidence for the logical access, monitoring and change management requirements.
NIS2 and DORA
Evidence for the EU's ICT risk management and incident reporting requirements.
PCI DSS and Cyber Resilience Act
Evidence for secure-by-default configuration and component traceability across the lifecycle.
Evidence that generates itself
See how runtime profiles, violation logs and CVE timelines map to your frameworks.