Compliancerapport

Compliancerapporten besvarer de spørgsmål, en revisor stiller om håndtering af sårbarheder: hvad var åbent, hvad blev rettet og hvor hurtigt, overholdt rettelserne dine SLA’er pr. alvorlighed, hvilke risici blev accepteret og af hvem, og hvilken politik var gældende. Du vælger perioden og eventuelt ét repository.

Du finder den under Sikkerhed › Rapporter › Compliancerapport (/<org>/_admin/security/reports/compliance). Organisationens ejere og medlemmer af organisationens Auditors-team kan åbne og downloade den.

Hvad den indeholder

Afsnit	Hvad det viser
Åbne fund	Fund, der er åbne ved periodens slutning, efter type og alvorlighed. Typer: afhængigheder, container-images (også images hentet gennem afhængighedsproxyen), IaC, licenser, SAST, secrets, malware og registry-pakker. Afviste og rettede fund tælles ikke med.
Udbedring	Pr. alvorlighed: fund åbnet, rettet og afvist i perioden, den gennemsnitlige tid fra åbnet til rettet og overholdelse af SLA. Pr. type: åbnet, rettet, afvist, den gennemsnitlige tid til rettelse og stadig åbne. Dernæst tiden til merge for de pull requests med sikkerhedsrettelser, der blev merget i perioden (median i timer, pr. kilde); den dækker hele organisationen og udelades derfor i en rapport for ét repository. Siden udbedringsmålinger definerer åbnet, rettet og tid til merge.
SLA-brud	Fund af alle typer, hvis SLA-frist udløb i perioden, mens de stadig var åbne, ved siden af de `code-security.sla.breached`-hændelser, der er registreret for afhængighedsfund (dem, der sendes til din SIEM).
Gældende undtagelser	Godkendte undtagelser, der var gældende ved periodens slutning, med hvem der anmodede om og godkendte hver enkelt, og hvornår den udløber. En undtagelse, der senere blev tilbagekaldt eller udløb, vises stadig, hvis den var gældende dengang.
Mest risikable komponenter	Op til 20 komponenter rangeret efter et antal af deres åbne advisories vægtet efter alvorlighed (kritisk 10, høj 5, middel 2, lav 1). Fra komponentoversigten.
Politikindstillinger	De indstillinger, der er gældende, når rapporten genereres: SLA-dage, scanningspolitik og tærskler for scannere, licenspolitikken med dens lister over afviste, advarede og tilladte, pakkepolitikken med dens lister over afviste og tilladte, tilstanden for modelscanning og indstillingerne for undtagelser.
Historik over fund	Hvert fund, der var åbent på et tidspunkt i perioden, med hvornår det blev åbnet, rettet eller afvist, og dets SLA-tilstand. Kun CSV.
AI-oversigt	De modelfiler, din organisation har, når rapporten genereres: hvor mange, hvor mange din politik for modelscanning blokerer eller ville blokere, hvor mange der har et afvist fund, din tilstand for modelscanning, CI-hentninger af modeller uden en fast revision og filerne pr. angivet licens. Altid for hele organisationen. CSV’en lister hver modelfil.
IaC efter benchmark og NIS2-område	De åbne IaC-fund, når rapporten genereres, grupperet efter de benchmarkkontroller, deres tjek tester, og efter NIS2-område; se nedenfor. For repositoriet, når du vælger et.

Alvorligheder følger sikkerhedsoversigten: SAST error tæller som høj og warning som middel; en forbudt licens tæller som kritisk og en begrænset som høj; secrets og malware er kritiske.

Overholdelse af SLA for en alvorlighed er de fund, der blev rettet inden for deres SLA, divideret med dem, der blev rettet inden for den, dem, der blev rettet efter den, og dem, der stadig var åbne efter fristen ved periodens slutning. En alvorlighed uden SLA har intet tal for overholdelse.

Fund, der ikke er nåbare. Hvis din organisation har slået SLA-multiplikatoren til, bruger alle SLA-tal (overholdelse, brud i perioden og hvert funds forfaldsdato) samme frist som SLA-mærkerne, sammendraget og SIEM-hændelserne om brud: et fund i en afhængighed eller et image måles kun mod den forlængede SLA, når hver aktuel række af det har vurderingen Ikke nåbar, og aldrig når dets EPSS gør en udnyttelse sandsynlig. Hvor den forlængede SLA afviger fra politikkens SLA, viser rapporten begge: “30, 60 if no call path” og hvor mange fund der blev målt mod den forlængede. CSV og JSON indeholder sla_days (den brugte frist), policy_sla_days, policy_sla_due_at og sla_multiplier pr. fund og unreachable_sla_days og stretched_sla_findings pr. alvorlighed. Med multiplikatoren på 1 ændres intet.

Fund i registry-pakker vises kun for en organisation, hvis pipeline for pakkepolitikker er slået til. Ellers udelader rapporten dem og siger det; din egen pakkepolitik og dens undtagelser listes stadig.

IaC efter benchmark og NIS2-område

Efter benchmark. Én række pr. benchmark: hvor mange af dens kontroller der har et åbent fund, hvor mange af dens kontroller fremforges tjek tester, de åbne fund og id’erne på kontrollerne med fund. Kortlægningerne er Trivys egne compliance-specifikationer (MIT) i den version, scannerne kører, for ni benchmarks: CIS Docker 1.6.0, CIS Kubernetes 1.23, RKE2 CIS 1.24, EKS CIS 1.4, NSA’s vejledning i hærdning af Kubernetes 1.0, Pod Security Standards baseline og restricted samt CIS AWS 1.2 og 1.4. Kun kontrol-id’er, alvorligheder og de tjek, der tester dem, er med; benchmarkteksten gengives ikke (CIS udgiver den under sin egen licens), og hver benchmarks navn linker til dens offentliggjorte specifikation. Der er ingen benchmark for Azure eller Google Cloud: Trivy udgiver ingen kortlægning for nogen af dem.

Efter NIS2-område. De samme fund efter den foranstaltning i NIS2 artikel 21, stk. 2, som hvert tjek vedrører: (b) håndtering af hændelser, (c) driftskontinuitet, (e) sikker konfiguration, (h) kryptografi og kryptering, (i) adgangskontrol. Denne gruppering er fremforges egen, lavet ud fra hvert tjeks titel, fordi der ikke findes nogen åben kortlægning fra disse tjek til NIS2. Den er ikke en officiel kortlægning og udtaler sig ikke om overholdelse af nogen foranstaltning.

Din organisations egne tjek tæller under NIS2-område (e), medmindre deres titel nævner et af de andre; de kortlægges ikke til nogen benchmarkkontrol. Er der ingen åbne IaC-fund, siger afsnittet det på én linje.

Formater

PDF-oversigt: hvert afsnit opsummeret på nogle få A4-sider på dit konsolsprog (engelsk, dansk, tysk, fransk, nederlandsk, norsk eller svensk).
CSV: én fil pr. afsnit (open, remediation, sla, exceptions, components, policy, findings, ai_inventory, iac_compliance), hver komplet, med stabile engelske kolonnenavne, til et regneark eller et script. iac_compliance har én række pr. benchmarkkontrol med fund og én pr. NIS2-område: grouping, framework, version, control, severity, checks (tjek-id’erne adskilt af mellemrum) og open_findings.

Hver download registreres i revisionsloggen som compliance.security_report.generated.

Perioden

Hele døgn i UTC, begge ender medregnet, højst 366 dage. Standard er de seneste 30 dage. Et fund, der blev åbnet kl. 00:00:00 på den første dag eller rettet kl. 23:59:59 på den sidste, tæller som inden for perioden.

Hvor historikken kommer fra

De fleste scannere erstatter deres fund ved hver scanning, så scannernes tabeller alene kan ikke sige, hvornår noget blev rettet. fremforge registrerer derfor hvert funds livsforløb (åbnet, rettet, afvist) én gang i døgnet for hver organisation og igen, hver gang en rapport genereres. Rapporten læser den registrering, og dens sidste afsnit, Om historikken, fortæller, hvad den kan og ikke kan vise:

Historikken begynder den dato, registreringen startede for din organisation. En rettelse før den dato tælles kun, hvor scanneren har beholdt fundet (den markerer fund, som en senere scanning ikke længere rapporterer, og fund af ondsindede pakker og registry-pakker har deres egne datoer for løsning). For et fund, der allerede var åbent, er datoen for åbning den, scanneren registrerede.
Tidspunkter for rettelser er præcise på timen eller inden for et døgn. Hvor scanneren markerede rettelsen, bruges dens tidspunkt. Hvor et fund blot forsvandt, registreres rettelsen, når den daglige registrering eller en rapport første gang ikke længere finder det.
Fund i et slettet, omdøbt eller overført repository tæller som rettet den dag, de fjernes: efter vinduet på 30 dage til gendannelse for et slettet repository, eller når det gamle navn ikke længere findes for et, der er slettet direkte, omdøbt eller overført. Se Opbevaring af dokumentation.
SAST-fund, der var åbne, før registreringen begyndte, har deres seneste scanning som dato for åbning, fordi SAST-scanneren ikke gemmer en dato for, hvornår fundet først blev set.
Afvisninger vises, som de står nu; en, der senere blev ophævet, er ikke med i rapporten.

Via 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

Kræver et token med findings:read. JSON’en er hele rapporten, inklusive history.notes. Eksempel:

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

Vedhæft den til det ugentlige sammendrag

En ejer af organisationen kan vedhæfte PDF’en til sikkerhedssammendraget: sæt flueben ved Vedhæft denne rapport som PDF til sikkerhedssammendraget nederst på rapportsiden. Det er slået fra som standard. Den vedhæftede rapport dækker sammendragets egen periode (7 dage, eller 1 dag for et dagligt abonnement) og er på hver modtagers sprog.

Via API’et: PUT /_app/api/v1/orgs/{org}/security/compliance-report/settings med {"digest_attachment": true} (policy:write); læs den med GET på samme sti (policy:read).

Branch-beskyttelse Daglig oversigt over varsler