Compliance-Bericht

Der Compliance-Bericht beantwortet die Fragen, die eine Prüferin oder ein Prüfer zum Schwachstellenmanagement stellt: was offen war, was wie schnell behoben wurde, ob die Korrekturen deine SLAs pro Schweregrad eingehalten haben, welche Risiken von wem akzeptiert wurden und welche Richtlinie galt. Du wählst den Zeitraum und optional ein Repository.

Du findest ihn unter Sicherheit › Berichte › Compliance-Bericht (/<org>/_admin/security/reports/compliance). Owner der Organisation und Mitglieder des Teams Auditors der Organisation können ihn öffnen und herunterladen.

Was er enthält

Abschnitt	Was er zeigt
Offene Befunde	Befunde, die am Ende des Zeitraums offen sind, nach Typ und Schweregrad. Typen: Abhängigkeiten, Container-Images (einschließlich Images, die über den Abhängigkeits-Proxy abgerufen wurden), IaC, Lizenzen, SAST, Secrets, Malware und Registry-Pakete. Verworfene und behobene Befunde werden nicht gezählt.
Behebung	Pro Schweregrad: im Zeitraum geöffnete, behobene und verworfene Befunde, die mittlere Zeit von der Öffnung bis zur Behebung und die SLA-Einhaltung. Pro Typ: geöffnet, behoben, verworfen, die mittlere Behebungszeit und noch offen. Dann die Zeit bis zum Merge der im Zeitraum gemergten Pull Requests für Sicherheitskorrekturen (Median in Stunden, pro Quelle); sie umfasst die gesamte Organisation und fehlt deshalb in einem Bericht für ein einzelnes Repository. Die Seite Behebungskennzahlen definiert geöffnet, behoben und Zeit bis zum Merge.
SLA-Verstöße	Befunde jedes Typs, deren SLA-Frist im Zeitraum ablief, während sie noch offen waren, neben den für Abhängigkeitsbefunde aufgezeichneten Ereignissen `code-security.sla.breached` (denen, die an dein SIEM gesendet werden).
Geltende Ausnahmen	Genehmigte Ausnahmen, die am Ende des Zeitraums gelten, jeweils mit Antragsteller, Genehmigendem und Ablaufdatum. Eine später widerrufene oder abgelaufene Ausnahme erscheint trotzdem, wenn sie damals galt.
Riskanteste Komponenten	Bis zu 20 Komponenten, gereiht nach einer nach Schweregrad gewichteten Zahl ihrer offenen Advisorys (kritisch 10, hoch 5, mittel 2, niedrig 1). Aus dem Komponenteninventar.
Richtlinieneinstellungen	Die Einstellungen, die bei der Erstellung des Berichts gelten: SLA-Tage, Scan-Richtlinie und Scanner-Schwellen, die Lizenzrichtlinie mit ihren Sperr-, Warn- und Erlaubnislisten, die Paketrichtlinie mit ihren Sperr- und Erlaubnislisten, der Modus des Modellscans und die Ausnahmeeinstellungen.
Befundverlauf	Jeder Befund, der irgendwann im Zeitraum offen war, mit dem Zeitpunkt seiner Öffnung, Behebung oder Verwerfung und seinem SLA-Status. Nur CSV.
KI-Inventar	Die Modelldateien, die deine Organisation bei der Erstellung des Berichts hält: wie viele, wie viele deine Richtlinie für den Modellscan blockiert oder blockieren würde, wie viele einen verworfenen Befund haben, dein Modus für den Modellscan, die CI-Modellabrufe ohne feste Revision und die Dateien pro angegebener Lizenz. Immer für die gesamte Organisation. Die CSV listet jede Modelldatei.
IaC nach Benchmark und NIS2-Bereich	Die offenen IaC-Befunde bei der Erstellung des Berichts, gruppiert nach den Benchmark-Kontrollen, die ihre Prüfungen testen, und nach NIS2-Bereich; siehe unten. Für das Repository, wenn du eines wählst.

Die Schweregrade folgen der Sicherheitsübersicht: SAST error zählt als hoch und warning als mittel; eine verbotene Lizenz zählt als kritisch und eine eingeschränkte als hoch; Secrets und Malware sind kritisch.

Die SLA-Einhaltung für einen Schweregrad ist die Zahl der innerhalb ihrer SLA behobenen Befunde, geteilt durch die innerhalb der SLA behobenen, die danach behobenen und die am Ende des Zeitraums noch über die SLA hinaus offenen. Ein Schweregrad ohne SLA hat keinen Einhaltungswert.

Befunde, die nicht erreichbar sind. Hat deine Organisation den SLA-Multiplikator eingeschaltet, verwendet jeder SLA-Wert (Einhaltung, Verstöße im Zeitraum und das Fälligkeitsdatum jedes Befunds) dieselbe Frist wie die SLA-Markierungen, die Zusammenfassung und die SIEM-Ereignisse zu Verstößen: Ein Abhängigkeits- oder Image-Befund wird nur dann an der verlängerten SLA gemessen, wenn jede aktuelle Zeile davon das Urteil Nicht erreichbar trägt, und nie, wenn sein EPSS eine Ausnutzung wahrscheinlich macht. Wo die verlängerte SLA von der SLA der Richtlinie abweicht, zeigt der Bericht beide: „30, 60 ohne Aufrufpfad“ und wie viele Befunde an der verlängerten gemessen wurden. CSV und JSON enthalten pro Befund sla_days (die verwendete Frist), policy_sla_days, policy_sla_due_at und sla_multiplier und pro Schweregrad unreachable_sla_days und stretched_sla_findings. Mit dem Multiplikator 1 ändert sich nichts.

Befunde zu Registry-Paketen erscheinen nur für eine Organisation, deren Pipeline für Paketrichtlinien eingeschaltet ist. Andernfalls lässt der Bericht sie aus und sagt das; deine eigene Paketrichtlinie und ihre Ausnahmen werden trotzdem aufgeführt.

IaC nach Benchmark und NIS2-Bereich

Nach Benchmark. Eine Zeile pro Benchmark: wie viele seiner Kontrollen einen offenen Befund haben, wie viele seiner Kontrollen die Prüfungen von fremforge testen, die offenen Befunde und die IDs der Kontrollen mit Befunden. Die Zuordnungen sind Trivys eigene Compliance-Spezifikationen (MIT), in der Version, die die Scanner ausführen, für neun Benchmarks: CIS Docker 1.6.0, CIS Kubernetes 1.23, RKE2 CIS 1.24, EKS CIS 1.4, der NSA Kubernetes Hardening Guide 1.0, Pod Security Standards baseline und restricted sowie CIS AWS 1.2 und 1.4. Enthalten sind nur Kontroll-IDs, Schweregrade und die Prüfungen, die sie testen; der Text der Benchmarks wird nicht wiedergegeben (CIS veröffentlicht ihn unter einer eigenen Lizenz), und der Name jedes Benchmarks verlinkt auf seine veröffentlichte Spezifikation. Es gibt keinen Benchmark für Azure oder Google Cloud: Trivy veröffentlicht für keine der beiden eine Zuordnung.

Nach NIS2-Bereich. Dieselben Befunde nach der Maßnahme aus NIS2 Artikel 21 Absatz 2, die jede Prüfung betrifft: (b) Bewältigung von Sicherheitsvorfällen, (c) Aufrechterhaltung des Betriebs, (e) sichere Konfiguration, (h) Kryptografie und Verschlüsselung, (i) Zugriffskontrolle. Diese Gruppierung ist fremforges eigene, erstellt aus dem Titel jeder Prüfung, weil es keine offene Zuordnung dieser Prüfungen zu NIS2 gibt. Sie ist keine offizielle Zuordnung und sagt nichts über die Erfüllung einer Maßnahme aus.

Die eigenen Prüfungen deiner Organisation zählen unter NIS2-Bereich (e), sofern ihr Titel keinen der anderen nennt; sie entsprechen keiner Benchmark-Kontrolle. Gibt es keine offenen IaC-Befunde, sagt der Abschnitt das in einer Zeile.

Formate

PDF-Zusammenfassung: jeder Abschnitt zusammengefasst auf wenigen A4-Seiten, in der Sprache deiner Konsole (Englisch, Dänisch, Deutsch, Französisch, Niederländisch, Norwegisch oder Schwedisch).
CSV: eine Datei pro Abschnitt (open, remediation, sla, exceptions, components, policy, findings, ai_inventory, iac_compliance), jeweils vollständig, mit stabilen englischen Spaltennamen, für eine Tabellenkalkulation oder ein Skript. iac_compliance hat eine Zeile pro Benchmark-Kontrolle mit Befunden und eine pro NIS2-Bereich: grouping, framework, version, control, severity, checks (die IDs der Prüfungen, durch Leerzeichen getrennt) und open_findings.

Jeder Download wird im Audit-Log als compliance.security_report.generated erfasst.

Der Zeitraum

Ganze Tage in UTC, beide Enden eingeschlossen, höchstens 366 Tage. Standard sind die letzten 30 Tage. Ein Befund, der am ersten Tag um 00:00:00 geöffnet oder am letzten um 23:59:59 behoben wurde, zählt zum Zeitraum.

Woher der Verlauf stammt

Die meisten Scanner ersetzen ihre Befunde bei jedem Scan, sodass die Scanner-Tabellen allein nicht sagen können, wann etwas behoben wurde. fremforge zeichnet deshalb den Lebenszyklus jedes Befunds (geöffnet, behoben, verworfen) einmal täglich für jede Organisation auf und zusätzlich jedes Mal, wenn ein Bericht erstellt wird. Der Bericht liest diese Aufzeichnung, und sein letzter Abschnitt, Zum Verlauf, nennt, was sie zeigen kann und was nicht:

Der Verlauf beginnt an dem Tag, an dem die Aufzeichnung für deine Organisation begann. Eine Behebung vor diesem Tag zählt nur, wo der Scanner den Befund behalten hat (er markiert Befunde, die ein späterer Scan nicht mehr meldet, und Befunde zu schädlichen Paketen und Registry-Paketen behalten ihr eigenes Behebungsdatum). Für einen Befund, der schon offen war, gilt das Öffnungsdatum, das der Scanner erfasst hat.
Behebungszeiten sind auf die Stunde oder auf einen Tag genau. Wo der Scanner die Behebung markiert hat, wird seine Zeit verwendet. Wo ein Befund einfach verschwunden ist, wird die Behebung erfasst, wenn die tägliche Aufzeichnung oder ein Bericht ihn zum ersten Mal nicht mehr findet.
Die Befunde eines gelöschten, umbenannten oder übertragenen Repositorys zählen an dem Tag als behoben, an dem sie entfernt werden: nach dem 30-tägigen Wiederherstellungsfenster für ein gelöschtes Repository oder sobald der alte Name nicht mehr existiert, wenn es endgültig gelöscht, umbenannt oder übertragen wurde. Siehe Aufbewahrung von Nachweisen.
SAST-Befunde, die vor Beginn der Aufzeichnung offen waren, tragen ihren letzten Scan als Öffnungsdatum, weil der SAST-Scanner kein Datum des ersten Auftretens speichert.
Verwerfungen werden so gezeigt, wie sie jetzt stehen; eine später aufgehobene ist nicht im Bericht.

Über die REST-API

GET /_app/api/v1/orgs/{org}/security/compliance-report
    ?from=2026-09-01&to=2026-09-30
    &repo=web                          optional, a repository of the org
    &format=json | pdf | csv           default json
    &section=open|remediation|sla|exceptions|components|policy|findings|ai_inventory|iac_compliance   with format=csv
    &lang=en|da|de|fr|nl|sv            PDF language; else Accept-Language, else English

Erfordert ein Token mit findings:read. Das JSON ist der gesamte Bericht, einschließlich history.notes. Beispiel:

curl -H "Authorization: Bearer ${FREMFORGE_TOKEN}" \
  "https://frem.sh/_app/api/v1/orgs/acme/security/compliance-report?from=2026-07-01&to=2026-09-30&format=pdf&lang=da" \
  -o compliance-report.pdf

An die wöchentliche Zusammenfassung anhängen

Ein Owner der Organisation kann das PDF an die Sicherheitszusammenfassung anhängen: Setze unten auf der Berichtsseite das Häkchen bei Diesen Bericht als PDF an die Sicherheitszusammenfassung anhängen. Standardmäßig ist das aus. Der angehängte Bericht deckt den eigenen Zeitraum der Zusammenfassung ab (7 Tage oder 1 Tag bei einem täglichen Abonnement) und ist in der Sprache der jeweiligen Empfängerin oder des jeweiligen Empfängers.

Über die API: PUT /_app/api/v1/orgs/{org}/security/compliance-report/settings mit {"digest_attachment": true} (policy:write); lies den Wert mit GET auf demselben Pfad (policy:read).

Branch-Schutz Lizenzrichtlinie