TYPO3 on Kubernetes under IT-Grundschutz, part 4: No CVEs above 7

01 — What “above 7” actually means

CVSS scores from 7.0 count as HIGH, from 9.0 as CRITICAL. In practice, “no CVEs above 7” means: no finding of severity HIGH or CRITICAL. Scanners filter by these severities directly. They use the rating of the respective data source, which can differ from the CVSS score.

The second restriction matters just as much: only findings that have a fix. A gate that also counts unfixable CVEs blocks releases without anyone being able to act. What the team then mainly learns is to work around the gate. Unfixable findings belong in the risk assessment and in monitoring, not in the pipeline's traffic light.

Two places need a scan. The container image carries operating system packages and the runtime. The application brings its own dependencies, for TYPO3 in composer.lock and often in package-lock.json for the frontend as well.

02 — Gate one: the image

After the build, a job scans the finished image, typically with Trivy. A second job, the verdict, reads the report and decides. The split has a reason: the scan collects facts, the verdict applies rules. That way the rule can change without touching the scan.

The verdict knows three modes:

• report: findings are only reported.
• warn: the job turns yellow, the pipeline stays green.
• block: the pipeline turns red, there is no release.

Justified exceptions live in a VEX document following OpenVEX. It names the CVE, the affected package and the reason, for example that the vulnerable code is never executed in the image. That beats an ignore list. Every exception carries a justification and can be reviewed.

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.org/vex/typo3-runtime",
  "author": "Platform Team",
  "timestamp": "2026-10-08T00:00:00Z",
  "version": 1,
  "statements": [{
    "vulnerability": {"name": "CVE-2026-00000"},
    "products": [{"@id": "pkg:apk/wolfi/example@1.2.3"}],
    "status": "not_affected",
    "justification": "vulnerable_code_not_in_execute_path"
  }]
}

There is often a baseline as well: findings that already existed when the gate was introduced and are accepted deliberately. It is a transition, not a permanent state. The goal is an empty baseline.

03 — Gate two: the application's dependencies

The image scan does not see the application at all, because its code is not in the image (part 3). So a second scan runs directly on the lock files, already in the merge request:

trivy fs --scanners vuln \
  --severity HIGH,CRITICAL \
  --ignore-unfixed \
  --exit-code 1 .

When it finds something, the fix is usually short. Either an update exists, or a transitive dependency can be raised on purpose. With npm that works through overrides, with Composer through an explicit requirement on the fixed version. Afterwards, only the affected package should change in the lock file.

One property is worth knowing up front: a newly published CVE can block a merge even though nobody changed any code. That is exactly the point of the gate. It only works if updates arrive quickly, though. Automated dependency updates are therefore not a convenience but a precondition. How that works across many repositories is covered in the post on pinup.

04 — After the release: rescan and deadlines

An image that is clean today can carry a known vulnerability tomorrow. Many CVEs are published only after the release. The scan at build time is therefore not enough.

A daily job scans the digests that actually run in the cluster. Not the tags, because a tag can move. New findings raise an alert with a deadline, for example 24 hours for CRITICAL and 7 days for HIGH. This is where patch and change management under OPS.1.1.3 takes over.

From warn to block

Putting a gate straight into block often stops every pipeline at once. This order has proven itself:

1. Introduce the gate in warn mode and measure.
2. Work findings down until the baseline is empty.
3. Switch individual repositories to block.
4. Once almost all are clean, make block the default and only track exceptions.

Every exception gets a reason and a date. An exception without a reason is not risk management, it is a gate somebody switched off.

How it maps to IT-Grundschutz

The gate covers several requirements from SYS.1.6: using secure images (SYS.1.6.A6), distributing them (SYS.1.6.A12), releasing them (SYS.1.6.A13) and updating them (SYS.1.6.A14). The deadlines after the release belong to OPS.1.1.3.

Conclusion

“No CVEs above 7” only becomes a property of the platform once a violation prevents a release. That takes two scans, a clear threshold for fixable findings, justified exceptions and a rescan for everything already running. The rollout works best in steps: measure first, then switch it on.

The series continues with part 5: mTLS on every hop. Back to part 3: code as a signed artefact.