Every release produces a set of machine-readable security documents, generated from the same component pins and CVE decisions that build the OS image. None of these artifacts is written by hand: the build tooling derives each one from the repo state, so the evidence and the image cannot drift apart. A running cluster then adds its own evidence: audit logs that record what happened on the node, at the API server, and at the cluster's front door.

The SBOM, with the triage inside it#

Each release has an SBOM (software bill of materials: the list of every component and version in the image) in SPDX 3.0.1, the latest version of the SPDX standard. The document is generated from the component pins, so every component entry carries the identity fields a reviewer or a scanner needs: the package URL, the CPE (the name CVE databases use for the component), the download location, the sha256, and the license. Because the OS is closed source, the SBOM is your evidence of what is inside: it gives a reviewer the full component inventory without repo access.

The SBOM is written with the SPDX security profile, so it also carries the vulnerability triage. For each known CVE it embeds a VEX statement (Vulnerability Exploitability eXchange: a machine-readable verdict saying whether the product is affected, not affected, under investigation, or fixed). A not_affected verdict carries the OpenVEX justification the triage decision recorded, mapped to the SPDX justification type. The point of embedding the triage: a downstream scanner that reads the SBOM honors those verdicts instead of re-flagging CVEs already triaged, so your scan results match the platform's.

The SBOM is byte-reproducible: built with a fixed timestamp, the same repo state produces the same document, so you can compare two copies with a hash.

The published release bundle also keeps a second arrangement of the same data: a clean SBOM with no vulnerability data next to a standalone OpenVEX advisory. Vulnerability verdicts change as triage progresses; the bill of materials does not. Separating them lets the SBOM be published once per release while the advisory updates with each scan, which is the separation the EU Cyber Resilience Act asks for. The advisory ships in two formats: OpenVEX and the BSI-aligned CSAF 2.0.

The stack security report#

The SBOM covers the node image. The container images the platform's cluster components deploy (the CNI, the cloud controller, the metrics stack, and so on) have their own CVEs, and the stack security report folds both into one document per release. It carries the node-image scan and the chart-image scan side by side: each CVE with its component, installed and fixed versions, its VEX verdict where one was decided, and its SLA status under the patch ladder below. One document answers "what is the security posture of this release" the way a registry page answers it for a single image.

The CVE feed#

Vulnerability data goes stale in days, so the release artifacts are refreshed by a recurring scan, not frozen at release time. The feed per release contains:

• The current report. Every open CVE across the node image and the chart images, tagged with which of the two it is in. Each entry carries the prioritization signals an auditor or a triage process needs: CVSS score and vector, EPSS (a published estimate of exploitation likelihood), whether the CVE is in the CISA KEV catalog (Known Exploited Vulnerabilities: the US cybersecurity agency's list of CVEs with confirmed exploitation in the wild), the VEX verdict where one exists, and the SLA state with its due date.
• A delta since the previous scan. CVEs added, resolved, escalated, or newly listed in the KEV catalog, so a reviewer reads what changed instead of diffing two full reports.
• A dated copy of each scan. Kept for history: you can show an auditor what was known on a given date and how long each finding stayed open.

The feed also records its own provenance: when the scan ran, which vulnerability sources it queried (OSV, NVD, the distro trackers, KEV, EPSS), how fresh the data was, and which SLA policy applied.

The patch SLA ladder#

Every open CVE gets a remediation deadline. The clock starts at the CVE's publication date, and the window depends on the effective severity:

Effective severity is not the raw CVSS score. Escalation applies before the window is chosen:

• A KEV listing overrides everything. A CVE in the CISA KEV catalog is treated as Critical regardless of its base score, because confirmed exploitation in the wild outranks a severity estimate.
• Exposure shifts the tier. A component that listens on the network moves up one tier; a component only used at build time, which never runs on the node, moves down one.

The feed reports each CVE as on track, due soon, or overdue against its deadline, and the report stamps which SLA policy computed the windows. Because nodes are immutable, meeting a deadline means shipping a patched release; your side is adopting it. See the upgrade timeline in Meet compliance requirements .

Evidence a running cluster emits#

The release artifacts prove what was shipped. A running cluster produces the records that prove what happened:

• The host audit log. auditd (the Linux audit daemon) runs on every node with an immutable ruleset and records OS-level events, including every break-glass SSH session. Local retention is size-based: a 400 MB rotating buffer on /var (8 files of 50 MB). It is a bounded hot buffer, not the system of record; long-term retention comes from shipping the stream off-node.
• The Kubernetes API audit log. The API server writes an audit log under a policy graded by sensitivity, so secret access logs more than a status read. Local retention is 90 days or about 1 GB (10 rotated files of 100 MB), whichever comes first.
• The KubeGate audit log. KubeGate is the proxy that gates the API server's load-balancer path (see Zero trust on public networks ). It writes an audit log of every gate decision, allow and deny, to /var/log/kubegate/audit.log, kept for 30 days or 100 MB per file with 3 rotated backups. Rejected connection attempts against your API server are a record you can review, not a silent drop. KubeGate also exports Prometheus metrics on a loopback endpoint on each control-plane node, so admission decisions are countable, not just logged.

All of this evidence lives on the node with the caps above, and nothing ships it off by default. Retention beyond the local caps is your side of the line: see Retrieve audit logs for shipping both logs to a SIEM and write-once storage.

What this evidence is not#

• Not a certification. The artifacts map onto the control families auditors ask about (vulnerability management, audit and accountability, provenance), but no framework body has attested them. You operate the controls and make the case to your auditor.
• Not a delivery promise. This page says what each artifact is and that the build tooling produces it per release. Distribution channels, disclosure policy, and security contacts are organizational matters outside this page.
• Not finished. The SLA ladder above is the effective posture: 72 hours for Critical, 7 days for High, 30 days for Medium, and 90 days for Low. The same windows apply to BSI C5 timelines.

Related#

• Meet compliance requirements , the shared-responsibility model and the control-family mapping this evidence feeds.
• Verify node integrity , prove a running node matches the released image the SBOM describes.
• Retrieve audit logs , ship the per-cluster evidence off-node into write-once storage.
• Zero trust on public networks , the KubeGate model behind the gate-decision log.
• Node and OS security , the control posture the release artifacts document.