How bifrost works
Learn, prioritise, protect, answer. What happens under the hood, step by step.
Learn
Deploy the agent
Install the bifrost agent into your Kubernetes clusters with one Helm chart. No code changes. No sidecars. The agent runs as a DaemonSet on every node, and a first assessment of CVE exploitability follows in under 10 minutes, from your SBOMs, the CVE data and each workload's deployment spec.
Learn and evaluate
Add one label and one annotation to a deployment and bifrost starts learning. In pre-production, it learns every new build: for each container, which environment it runs in and how it is configured, what it contains, which CVEs it carries, with the SBOM re-scanned several times a day, and the syscalls, files and connections it uses doing its job. Then bifrost evaluates that behaviour against its own knowledge of how services built on each framework behave: it surfaces weaknesses, including behaviour the profile has to allow, and assesses how fully it has captured the workload.
Prioritise
Assess and prioritise
bifrost ingests the SBOM for the application code and the container image at each build and correlates every CVE against the behaviour it has learned and evaluated. The first assessment sharpens into one verdict per CVE: reachable, mitigated by the profile, or never loaded. One view across every environment and service, with no manual triaging. What reaches you is the reachable list, with the evidence behind each verdict.
Protect
Generate security profiles
For every build sent to production, bifrost generates a tailored security profile from learned behaviour and its built-in knowledge. Each profile defines exactly what that container version is allowed to do, and nothing more. A fresh profile with every build, so there are no hand-written rules to maintain: manual regimes run anywhere from ~200 to 10,000 rules. Profiles are human-readable and fully reviewable.
Enforce
Rollout is a ramp, and your team decides when each workload moves along it: observe while bifrost learns, detect to see deviations reported, enforce to have the kernel block every operation outside the profile. In enforce mode, exploits that need those operations are blocked even before a patch exists, including exploits not yet discovered; patching still matters for what the profile allows. With every new build, bifrost regenerates the profile.
Answer
The next CVE, assessed against what bifrost already knows
When a new CVE is disclosed, bifrost assesses it against the workload context it already holds, and the answer leads with protection status. If an enforced profile blocks what the exploit needs, the CVE is mitigated by the profile, with the evidence, and the patch can wait for the normal window. Then the scope (which services, clusters and environments carry it), the exposure (whether the code is loaded) and the next action, with remediation steps where one is needed. No rebuild and no new scan of the workload: every build is tracked into every environment, and every active SBOM is re-scanned through the day. Verdicts and blocked actions go back to whoever writes the next change, in Slack, Microsoft Teams or a webhook.
Runtime detection and prevention
Ground truth, enforced
Every workload's security profile rolls out in three modes, and enforce is the destination. Your team decides when each workload moves along the ramp: learning in pre-production, detecting deviations in staging, enforcing in production.
Observe.
New workloads start in observe mode. bifrost learns and evaluates what the workload does, and nothing is blocked.
Detect.
The profile is applied. Deviations are detected and reported with pod, image and the attempted action, not blocked. A stop on the way to enforce, to check the profile against real traffic before you switch.
Enforce.
Default-deny. Anything outside the profile is refused before it runs and reported as a high-signal event, with pod, image and the attempted action. Move a workload back to observe at any time with one annotation.
In the annotation, the three modes are audit, complain and enforce.
How it is built
bifrost sits where the code runs: a profile per workload, built from what the workload does and bifrost's own knowledge, and enforced by the kernel.
- An agent as a DaemonSet
- Installed with Helm. One label and one annotation per workload, and no code changes.
- Enforced by the kernel
- Each security profile is enforced by the Linux Security Module, as an AppArmor profile, not by a sidecar or a proxy.
- Under 1% CPU overhead
- In production, on the workloads it protects. The agent observes behavioural signals only, never application data.
- First CVE assessment in under 10 minutes
- From one Helm chart to a first assessment of CVE exploitability. It sharpens into verdicts as bifrost learns, and every build gets a fresh profile.
AI assesses, the kernel enforces. AI assesses each workload's behaviour for weaknesses, and how a CVE's exploit would meet what its profile allows. The profile and its enforcement are deterministic: no model decides at runtime whether an operation runs.
Technical deep dive
A closer look at each stage of the bifrost pipeline.
Runtime data collection
The bifrost agent collects detailed behavioural data: system calls (execve, open, connect, bind, mmap), file I/O, network activity, process creation, environment variables, loaded libraries.
What is NOT collected:
Application data, PII, request payloads, database contents, API responses. The agent observes behavioural signals only, not information flows. Data is aggregated and anonymised.
Under 1% CPU overhead in production.
SBOM integration
bifrost ingests SBOM data to understand the dependency landscape. Supported formats: CycloneDX (XML/JSON) and SPDX. Integration with SBOM generators happens automatically in CI/CD.
The SBOM provides precise information about every dependency, version, and known CVE. bifrost correlates this against runtime behaviour to give each CVE its verdict.
Continuous re-evaluation:
Every active SBOM is re-scanned through the day. As CVE databases update, every verdict is re-evaluated without a new build or a new scan on your side.
The CVE correlation engine
Every CVE gets exactly one verdict. The correlation engine reaches it in three stages:
Scan the SBOM
Re-scan every active SBOM through the day to surface the CVEs in the image and the code, per environment.
Reachability analysis
Cross-reference vulnerable code paths with the behaviour bifrost has learned and evaluated. If a vulnerable library is never called or a feature is never configured, the CVE is never loaded, and the verdict carries the evidence behind it.
Mitigation assessment
AI assesses how the CVE's exploit would meet what the profile allows. If it needs binary execution and the profile does not allow it, the CVE is mitigated by the profile. The assessment informs the verdict; the kernel enforces the profile, deterministically.
Result: every CVE carries one of three verdicts:
Reachable in this workload's use and not mitigated. Needs attention.
The exploit needs something the workload never does, and the enforced profile refuses it before it runs. Patch in your normal window.
The code path never runs, and the evidence shows why.
Teams work the reachable list, up to 90% fewer CVEs to triage, and each verdict carries the evidence behind it.
A lookup, not a war room
Protection status first, then scope and next action. See it on your stack: a 30-minute demo, or 14 days on your own cluster.