fusioncore.ai fusioncore.ai

← Blog

Instant Kubernetes Runtime Anomaly Detection Via SBOBs (Bill of Behavior)

Conference poster: Instant Kubernetes Runtime Anomaly Detection Via SBOBs (Bill of Behavior). Constanze Roedig, fusioncore.ai & SBA-Research; Matthias Bertschy, ARMO. KubeCon EU 2026, CNCF Kubescape + K8sstormcenter. ⤢ click to enlarge

Constanze Roedig — fusioncore.ai & SBA-Research · Matthias Bertschy — ARMO
KubeCon EU 2026 · CNCF Kubescape + K8sstormcenter

1. Why runtime security is still hard

Anomaly detection at reasonable noise-levels is inaccessible to most Kubernetes practitioners due to maintenance effort:

  • Each component update implies effort, maintenance, and re-testing.
  • Seccomp / AppArmor are powerful but have different lifecycles.
  • If rules are too restrictive, they break production thus people switch them off. Achieving the right level of abstraction has been hard.
  • False positives drown analysts; missed detections create risk.

SBoBs shift the burden of secure-by-default baselines to the producer or vendor of the software — the party that knows normal behaviour best. Users inherit profiles and rule updates directly. Scale is achieved through shared, human-readable profiles and local tuning. Local sign-off ensures rules can always be fitted on-site.

2. What’s in an SBoB?

Human-readable CRDs — gitOps-friendly, no extra tools needed:

  • ApplicationProfile captures process, file opens, endpoint methods and capabilities.
  • NetworkNeighborhood captures FQDN locking.
  • Rules capture the interpretation of a signal.
    All are signable.
spec:
  containers:
  - name: payment-app
    capabilities: [CAP_SETGID, CAP_SETPCAP, CAP_SETUID]
    endpoints:
    - endpoint: ":0/api/data"           # wildcard port
      methods: [GET, POST]
      direction: outbound
    execs:
    - args:
      - /usr/bin/touch
      - '*'                              # argument wildcard
      path: /usr/bin/touch
    opens:
    - flags: [O_RDONLY, O_WRONLY, O_CREAT]
      path: /*                           # path wildcard
    syscalls:
    - accept4
    - access
    - arch_prctl

Wildcards, CIDR ranges and rule policies can be edited by hand without learning any tools.

We expect that (if anyone other than us) uses SBOBs, we will call them something more academic. For now, we are primarily interested in understanding what makes user accept such profiles.

3. Signing pieces: chain against tampering

Profiles are expected to be signed before distribution. NetworkNeighbors specifically are expected to be bundled: a DynamoDB endpoint signed by AWS, or a Stripe API endpoint signed by Stripe and the customer’s private endpoint signed by the customer.

Users can then tune locally and keyless sign again after testing in their local environment, e.g. for incident response. At deploy time, node-agent verifies the signatures using annotations: tampered or unsigned profiles are rejected. Alerts fire if signatures become invalid.

Signed SBoB profile deploys to storage; node-agent DaemonSet verifies signatures and watches the target application via eBPF hooks; AlertManager and webhook outputs; tamper attempts on profile and rules are rejected.
ApplicationProfile/Rules CRD is sanitized to canonical JSON SHA-256, then signed either keyless (OIDC + Fulcio + Rekor) or key-based (ECDSA P-256). The signed profile carries signature annotations, is deployed, and verified by the node-agent — accepted or rejected.

Signing and verification are implemented using cosign and sigstore. They are stored as annotations on the CRDs. For airgapped, CI or local signing, a standard key can be used.

4. Why SBoBs work where others didn’t

SBoBs deliver what SELinux and AppArmor never could:

  • Sufficiently specific — neither block apps nor drown analysts in noise.
  • Human-readable — insightful even without extra tools.
  • Human-editable YAML — wildcards, CIDR ranges, rule policies edited by hand.
  • GitOps-native — integrate with Flux, ArgoCD, standard Kubernetes workflows.
  • Scalable rule maintenance — vendors ship profile baselines; users inherit updates and only maintain local tuning and sign-off.
  • Piece-wise signable — verifiable chains for external dependencies at runtime.
  • Effort tunable — level of sophistication up to the user.

6. Show me the code

Funding & licence

This work was supported by the netidee programme of the Internet Foundation Austria. Antrag Nr. 7918, project SovereignSOC, Fördernehmer: SBA Research, Key Researcher: Dr. Constanze Roedig.

© 2026 Dr. Constanze Roedig. All rights reserved. No part of this post may be reproduced, redistributed or used to train derivative models without prior written permission. Code referenced from any linked repositories is licensed separately under Apache 2.0 and/or GPL v2 (see each repo for its declared licence).

Repository: github.com/k8sstormcenter .

← All posts