Why runtime security is still hard

Anomaly detection at usable noise levels is still inaccessible to most Kubernetes practitioners.

• Every component update implies effort, maintenance, and re-testing.
• Seccomp and AppArmor are powerful but have their own lifecycles. When their rules are too restrictive, they break production — and operators turn them off.
• Achieving the right level of abstraction has been hard.
• False positives drown analysts; missed detections create risk.

We need to 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 plus local tuning. Local sign-off ensures rules can always be fitted on-site.

This is why we created a transferable profile that starts at the "medium" that ports across almost all cloud systems: the Linux ABI.  

What’s in an SBoB? 

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

 These describe process, file opens, endpoint/methods, capabilities (syscalls are discouraged) and FQDNs.  The fields will all be well defined as well as the meaning of the omissions in an upcoming Specification. We are aiming at an OpenStandard, that is at all times backed and evaluated in practise and at scale (CNCF Kubescape can run on up to 10.000 nodes).

# --- ApplicationProfile ---
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

The important part is, that any human user (unfortunate enough to be confronted with yamls on a daily base) can read the above file.

Signing Pieces: chain against tampering

Profiles are expected to be signed before distribution. NetworkNeighbors specifically are expected to be bundled: e.g. a DynamoDB endpoint signed by AWS, or a Stripe API endpoint signed by Stripe and the customers private endpoint signed by themselves.

Users can then tune locally and keyless sign again after testing in their local environment (e.g., for incident response). At deploy time, CNCF Kubescape verifies the signatures using annotations: tampered or unsigned profiles are rejected/alerted. Alerts are fired if signatures become invalid.

Signing and verification are implemented using cosign and sigstore. They are stored as annotations 

Why SBoBs (Bill of Behavior) Work Where Others Didn’t

We propose that 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, and rule policies can be edited by hand without learning any tools
• GitOps-native — integrate with Flux, ArgoCD, standard K8s 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

Where we stand and what's next

At the conference, we co-presented our work to the EU audience, got plenty of feedback and have since started the upstreaming (merging the code that makes the above possible from the feature-fork to the CNCF project main).

The feature is still very actively being tested in the fork, as it forms the foundation of the Sovereign SOC: the above Alerts are the triggers for the protocol capture described in our previous post.   

When will a formal specification be released?

We are working towards a summer 2026 release of v0.0.1 of an OpenStandard, currently testing 5 real-life applications against it.

Show me the code

https://www.github.com/kubescape/storage (feature fork at https://www.github.com/k8sstormcenter/storage)

https://www.github.com/kubescape/node-agent (feature fork at https://www.github.com/k8sstormcenter/node-agent)