Die container.gov.de-Compliance-Policy

Diese Seite erläutert, wie die automatisierte Compliance-Prüfung von container.gov.de funktioniert, welche Anforderungen sie stellt und warum diese Designentscheidungen so getroffen wurden.

Was ist eine Compliance-Policy?

Bevor ein Container-Image auf container.gov.de gelistet wird, durchläuft es eine automatisierte Prüfung. Diese Prüfung beantwortet eine einzige Frage:

Sind alle bekannten kritischen und hohen Schwachstellen (CVSS Score ≥ 7.0) in diesem Image explizit bewertet worden?

Die Prüfung ist in der Policy-Sprache Rego formuliert.

Die Kernregel

Die Policy container.gov.de.rego enthält eine einzige Compliance-Regel:

Ein Image ist konform, wenn keine kritische oder hohe Schwachstelle im Status "in_triage" ist.

Das bedeutet konkret:

Schwachstellen mit dem Status in_triage gelten als unbewertet
in_triage bedeutet: Die Schwachstelle wurde identifiziert, aber noch keiner Bewertung unterzogen
Alle anderen Zustände (resolved, not_affected, false_positive, exploitable) gelten als bewertet

Für mittlere (medium) und niedrige (low) Schwachstellen gilt diese Anforderung nicht – sie können weiterhin in_triage verbleiben.

Aufbau der Rego-Policy im Detail

Die Datei container.gov.de.rego enthält folgende Logik:

1. Schweregrad bestimmen

severity(vulnerability) := lower(rating.severity) if {
    some rating in vulnerability.ratings
    startswith(rating.method, "CVSS")
} else := lower(vulnerability.ratings[0].severity) if {
    count(vulnerability.ratings) > 0
}

Die Policy bevorzugt CVSS-basierte Bewertungen. Falls keine CVSS-Bewertung vorliegt, wird die erste verfügbare Bewertung verwendet.

2. Status einer Schwachstelle prüfen

is_in_triage(vulnerability) if {
    vulnerability.analysis.state == "in_triage"
}

is_false_positive(vulnerability) if {
    vulnerability.analysis.justification == "false_positive"
}

Die Policy unterscheidet zwischen:

in_triage: Schwachstelle identifiziert, aber noch nicht bewertet → unzulässig für Schwachstellen des Schweregrads critical oder high
exploitable: Schwachstelle als aktiv ausnutzbar eingestuft → wird als unbehobenes Risiko erfasst
Alle anderen Zustände: Schwachstelle explizit bewertet → zulässig

3. Kritische und hohe Schwachstellen in Triage sammeln

high_or_critical_in_triage_vulns := [vuln |
    some vuln in in_triage_vulns
    severity(vuln) in {"critical", "high"}
]

Diese Liste umfasst alle Schwachstellen, die den Schweregrad critical oder high aufweisen und sich noch im Status in_triage befinden.

4. Compliance-Entscheidung

compliant if {
    count(high_or_critical_in_triage_vulns) == 0
}

Das Image gilt als konform, wenn diese Liste leer ist – wenn also keine Schwachstelle des Schweregrads critical oder high ohne Bewertung verbleibt.

5. Ergebnis

result := {
    "compliant": compliant,
    "violations": violations,
    "cve_critical": cve_critical,
    "cve_high": cve_high,
    "cve_medium": cve_medium,
    "cve_low": cve_low,
    "cve_open": cve_open,
    "cve_false_positive": cve_false_positive,
    "last_update_unix": (last_update / 1000) / 1000,
}

Neben der compliant-Flag liefert die Policy Statistiken über den Zustand des Images wie die Anzahl offener CVEs je Schweregrad.

Warum gerade diese Regel?

Diese Designentscheidung wägt zwei Anforderungen gegeneinander ab:

Sicherheit: Alle bekannten kritischen und schwerwiegenden Schwachstellen müssen einer dokumentierten Bewertung unterzogen worden sein. Auf diese Weise wird sichergestellt, dass keine Schwachstelle ohne explizite Auseinandersetzung verbleibt – jede muss einer aktiven Entscheidung zugeführt werden.

Praktikabilität: Die Policy erfordert keine vollständige Behebung aller Schwachstellen. Eine Schwachstelle kann mit dem Status not_affected oder risk_accepted versehen werden. Dies entspricht der Realität, da Container-Images häufig CVEs in Komponenten enthalten, die im jeweiligen Einsatzkontext nicht relevant sind – etwa eine Schwachstelle in einem Webserver-Paket, das im Image nicht als Webserver genutzt wird.

Transparenz: Über das VEX-Dokument ist jede Bewertungsentscheidung für alle Nutzerinnen und Nutzer des Images öffentlich nachvollziehbar – es ist attestiert, welche Schwachstellen aus welchen Gründen als nicht sicherheitsrelevant eingestuft wurden.

Was die Policy nicht prüft

Die Policy prüft ausschließlich die Schwachstellenbewertung. Sie prüft nicht:

Ob das Image nach der Härtungs-Checkliste gebaut wurde
Ob eine SBOM vorhanden ist (empfohlen, aber nicht erzwungen)
Ob das Image signiert ist (empfohlen, aber nicht erzwungen)
Die konkrete Konfiguration des Containers (non-root, read-only-filesystem etc.)

Diese Maßnahmen sind in der Härtungs-Checkliste dokumentiert und stellen aktuell nur eine Empfehlung für Maintainer dar.