How bifrost works
Learn, prioritise, protect, answer. What happens under the hood, step by step.
Learn
Deploy the agent
Install the lightweight bifrost agent into your Kubernetes clusters with Helm. No code changes. No sidecars. The agent runs as a DaemonSet on every node, ready to learn. Setup takes minutes.
Observe and learn
Add one label and one annotation to a deployment and bifrost starts learning. In pre-production, every new build is observed. For each container, bifrost learns 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.
Prioritise
Correlate and verdict
bifrost ingests the SBOM for the application code and the container image at each build and correlates every CVE against what the container actually does. Every CVE gets a verdict: 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 what it has learned. 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
Profiles are enforced at the kernel level. Rollout is a ramp: observe while bifrost learns, detect to see deviations reported, enforce to block anything outside the profile, from zero-days and supply-chain attacks to ransomware and container escapes. When you deploy the next build, the profile updates with it. Your protection evolves with your application.
Answer
When the next CVE is discovered, bifrost knows your exposure
When a new CVE is discovered, bifrost already knows where it is: which services and clusters carry it, in which environments, and whether the code is actually loaded. Then it tells you what to do about it. If the security profile already blocks the exploit path, the answer is protected, with the evidence, and the fix can wait for the normal patch window. If not, you get the remedies. No new build or scan is needed: every build is tracked into every environment, and every active SBOM is re-scanned through the day.
Runtime detection and prevention
Detect and prevent at runtime, on a safe ramp
Every workload's security profile is rolled out in three modes, and enforce is the destination. The bifrost engine guides each workload along the ramp across the software development lifecycle: learning in pre-production, detecting deviations in staging, enforcing in production.
Observe.
New workloads start in observe mode. bifrost learns 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 blocked and reported as a high-signal event. Move a workload back to observe at any time with one annotation.
In the annotation, the three modes are audit, complain and enforce.
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 observed runtime behaviour. If a vulnerable library is never called or a feature is never configured, the CVE is never loaded.
Mitigation assessment
Check whether the security profile blocks the exploit path. If a CVE needs binary execution and the profile does not allow it, the CVE is mitigated by the profile.
Result: every CVE carries one of three verdicts:
Reachable in this workload's use and not mitigated. Needs attention.
The security profile blocks the exploit path.
The code path never runs.
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
The next CVE, answered from what bifrost already knows. See it on your stack: a 30-minute demo, or 14 days on your own cluster.