CVE prioritisation from the runtime up
Runtime security for containerised workloads. From the runtime up.
bifrost turns runtime behaviour into CVE verdicts and kernel-enforced protection. It learns and evaluates what each workload does, prioritises the vulnerabilities that need attention, and blocks operations outside its enforced security profile. When a new CVE is disclosed, bifrost assesses exposure and protection using the workload context it already holds.
Up to 90% fewer CVEs to triage
Under 1% CPU overhead in production
< 10 min to a first CVE exploitability assessment
Every build gets a fresh profile and refreshed verdicts
Learn
Every container, down to what it does when it runs
bifrost learns what deploys where, down to each container underpinning every service you run. For every container it learns five things: which environment it runs in and how it is configured, where it was built, what it contains, which CVEs it carries, and the syscalls, files and connections it uses doing its job. Then it evaluates that behaviour against its own knowledge, which grows with every service and framework, to surface weaknesses and assess how fully it has captured the workload. That understanding becomes the verdict on every CVE, the security profile for every workload, and the starting point when the next CVE is disclosed.
- One label and one annotation: every build is observed in pre-production, with no code changes
- Behaviour learned and evaluated per container: system calls, file access, process activity and network connections
- Every environment a build passes through is in the picture, from staging to production
- Weaknesses surfaced before production, including behaviour the profile must allow: if your app reads /etc/passwd, the profile allows it and bifrost flags it to keep tabs on


Prioritise
Every verdict carries its evidence
Every CVE gets a verdict against what actually runs: reachable, mitigated by the profile, or never loaded. Every verdict comes from the same place as the protection: what the workload actually did when it ran. One view across every environment and every service, from staging to production. No manual triaging: what reaches you is a short list, and each verdict arrives with the evidence behind it.
- SBOMs ingested every deploy: always an up-to-date picture of what's live
- SBOMs re-scanned through the day: new CVEs matched against your inventory automatically
- Every build tracked into every environment: for a given CVE you see which services and clusters carry it, so you know where to fix first
- The evidence behind each verdict: the behaviour learned and evaluated, the profile applied, the package loaded or not
- Development and security work from the same facts: what is reachable and not yet protected
Protect
Close the attack window
An enforced profile blocks exploits that need operations outside it, even before a patch exists. bifrost generates each workload's security profile from its learned behaviour and built-in knowledge, fresh with every build, so nobody writes, tests and updates rules by hand: manual regimes run from ~200 to 10,000 rules. Protection is a ramp, and your team decides when each workload moves: observe, where bifrost learns and nothing is blocked; detect, where the profile is applied and deviations are reported; and enforce, the destination, where anything outside the profile is refused before it runs, including what an exploit not yet discovered would need. Patching still matters for what the profile allows.
- A profile per build, regenerated automatically from learned behaviour and built-in knowledge: no profiles written by hand
- Every blocked event raises an alert with its full context: what happened, in which workload, and why it fell outside the profile. Nothing reaches a human without its context
- SIEM-ready integrations: pipe alerts straight into your SOC workflow
Under the hood: each security profile is an AppArmor profile, enforced by the Linux kernel's security module rather than by a sidecar or a proxy.

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. Protection status comes first: if an enforced profile blocks what the exploit needs, the CVE is mitigated by the profile, with the evidence. Then scope, exposure 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.
Workloads understood. CVEs prioritised. Boundaries enforced. New vulnerabilities assessed. Teams decide when to enforce; bifrost automates the recurring work.
Where you start decides what you can know
Scan-led workflows start from build contents and known vulnerabilities. Without runtime context, your team still has to establish which findings matter. bifrost starts from runtime and works up: knowledge, verdicts, protection, answers.
| Capability | Scanners (start from the build) | bifrost (starts from runtime) |
|---|---|---|
| CVE detection | Yes: finds every known CVE in the image | Yes: SBOMs ingested every deploy, re-scanned through the day |
| Reachability | Not from runtime: findings arrive without evidence of how the workload runs | Yes: every CVE gets a verdict against what actually runs |
| Mitigation | No: the only remedy is a patch | Yes: in enforce mode, the profile blocks operations the workload never needs |
| Prioritisation | By severity scores, without runtime context | By verdict: reachable, mitigated by the profile, or never loaded |
| Noise | High: hundreds or thousands of findings | Low: a short reachable list, with the evidence attached |
| Updates | Periodic scans | Every build, plus SBOMs re-scanned through the day |
Two other starting points. Detect-and-respond tools start from suspicious activity and the response it needs: an essential layer, but responding to an event is not the same as constraining what a workload can do before it is exploited. Hand-maintained rules start from what someone writes, tests and updates as the software changes, anywhere from ~200 to 10,000 rules; bifrost regenerates each profile with every build.
Built for production
Designed for production clusters: a DaemonSet per node, kernel-level enforcement, and under 1% CPU overhead.
Enforcement
AppArmor LSM
Deployment
DaemonSet
Setup
One Helm chart
Performance impact
< 1% CPU
SBOM formats
CycloneDX, SPDX
CVE discovery
SBOM scanned several times a day
Data residency
Swedish and EU hosting
Lock-in
None: standard AppArmor profiles
Platform architecture
Pre-prod clusters
Production clusters
bifrost Engine (EU hosted)
Integrations
Built for security-conscious teams
Built on research, engineered for production, hosted where your data belongs.
Research-founded
Born from a joint EU research project at Lund University, then shaped into a product by engineers with real-world production experience. Research depth, practical edge.
Sovereign by choice
Run bifrost where your compliance posture demands, from a Swedish-owned sovereign cloud outside US jurisdiction to your own infrastructure. GDPR-compliant by design.
Swedish-owned
Researched, developed, and funded by Swedish individuals. Patented runtime profiling technology, built in Sweden for European and global teams.
Kernel-level enforcement
Built on AppArmor, a Linux Security Module trusted in production for 20+ years. Enforcement sits in the kernel, below the application, with no sidecar or proxy in the request path.
Data residency
Your data stays where you want it
Run bifrost in the jurisdiction and ownership model your compliance posture demands. Same platform, four deployment options, from a sovereign European cloud to your own infrastructure.
Swedish hosted
Managed service on Swedish-owned and controlled cloud.
- Outside US jurisdiction
- Data stays in Sweden
- Full data sovereignty
European hosted
EU region of a global hyperscaler.
- Familiar, proven scalability
- EU data residency
- GDPR-compliant processing
Private cloud
Single-tenant, managed by bifrost in your infrastructure.
- Dedicated single-tenant instance
- Runs in your own infrastructure
- Fully managed by bifrost
On-premise
Runs entirely in your environment
- Data never leaves your network
- Air-gap compatible
- Self-hosted by your organisation
Not sure which fits? Talk to us about your residency requirements
What your vendor review will ask
What the agent collects, where your data lives, and how bifrost itself is secured. Built with data minimisation and privacy at its core.
Data minimisation
The bifrost agent collects behavioural metadata: system calls, file access patterns, network connections, never application data or personal information.
EU data residency
All data is processed and stored within the EU. GDPR-compliant by design.
Encryption
All data in transit and at rest is encrypted.
Minimal-privilege agent
The bifrost agent runs as a read-only DaemonSet with minimal privileges. No access to your application data.
Audit evidence
Enforcement keeps a record as it runs: security profiles, enforcement records and CVE verdicts that support audit preparation.
ISO 27001
ISO 27001 certification in progress. Contact us for our current security documentation.
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.