Samsvarsrapport

Samsvarsrapporten svarer på spørsmålene en revisor stiller om sårbarhetshåndtering: hva som var åpent, hva som ble rettet og hvor raskt, om rettelsene holdt SLA-ene per alvorlighetsgrad, hvilke risikoer som ble godtatt og av hvem, og hvilken policy som gjaldt. Du velger perioden og eventuelt ett repository.

Du finner den under Sikkerhet › Rapporter › Samsvarsrapport (/<org>/_admin/security/reports/compliance). Eiere av organisasjonen og medlemmer av organisasjonens Auditors-team kan åpne og laste den ned.

Hva den inneholder

Seksjon	Hva den viser
Åpne funn	Funn som er åpne ved slutten av perioden, etter type og alvorlighetsgrad. Typer: avhengigheter, containerimager (inkludert imager som er hentet gjennom avhengighetsproxyen), IaC, lisenser, SAST, secrets, skadevare og registerpakker. Avviste og rettede funn telles ikke.
Utbedring	Per alvorlighetsgrad: funn som ble åpnet, rettet og avvist i perioden, gjennomsnittlig tid fra åpnet til rettet, og SLA-etterlevelse. Per type: åpnet, rettet, avvist, gjennomsnittlig tid til rettelse, og fortsatt åpne. Deretter tiden til merge for pull requests med sikkerhetsrettelser som ble merget i perioden (median i timer, per kilde); den dekker hele organisasjonen og utelates derfor fra en rapport for ett repository. Siden om utbedringsmålinger definerer åpnet, rettet og tid til merge.
SLA-brudd	Funn av alle typer der SLA-fristen passerte i perioden mens de fortsatt var åpne, ved siden av hendelsene `code-security.sla.breached` som er registrert for funn i avhengigheter (de som sendes til SIEM-en din).
Gjeldende unntak	Godkjente unntak som gjelder ved slutten av perioden, med hvem som ba om og hvem som godkjente hvert av dem, og når det utløper. Et unntak som ble tilbakekalt eller utløp senere, vises likevel hvis det gjaldt da.
Mest risikable komponenter	Opptil 20 komponenter rangert etter et alvorlighetsvektet antall åpne sårbarhetsvarsler (critical 10, high 5, medium 2, low 1). Fra komponentoversikten.
Policyinnstillinger	Innstillingene som gjelder når rapporten genereres: SLA-dager, skannepolicy og terskler for skannere, lisenspolicyen med blokkerings-, advarsels- og tillatelseslister, pakkepolicyen med blokkerings- og tillatelseslister, modusen for skanning av modeller og innstillingene for unntak.
Funnhistorikk	Alle funn som var åpne på et tidspunkt i perioden, med når de ble åpnet, rettet eller avvist, og SLA-tilstanden. Bare i CSV.
AI-oversikt	Modellfilene organisasjonen din har når rapporten genereres: hvor mange, hvor mange policyen for skanning av modeller blokkerer eller ville blokkert, hvor mange som har et avvist funn, modusen for skanning av modeller, pull av modeller i CI uten fast revisjon, og filene per deklarert lisens. Alltid for hele organisasjonen. CSV-en lister alle modellfiler.
IaC etter benchmark og NIS2-område	De åpne IaC-funnene når rapporten genereres, gruppert etter benchmark-kontrollene sjekkene deres tester, og etter NIS2-område; se under. For repositoryet når du velger ett.

Alvorlighetsgradene følger sikkerhetsoversikten: SAST error teller som high og warning som medium; en forbudt lisens teller som critical og en begrenset lisens som high; secrets og skadevare er critical.

SLA-etterlevelse for en alvorlighetsgrad er funnene som ble rettet innenfor SLA-en, delt på dem som ble rettet innenfor den, dem som ble rettet etter den, og dem som fortsatt var åpne etter fristen ved slutten av perioden. En alvorlighetsgrad uten SLA har ikke noe tall for etterlevelse.

Funn som ikke er nåbare. Hvis organisasjonen din har slått på SLA-multiplikatoren, bruker alle SLA-tall (etterlevelse, brudd i perioden og fristen for hvert funn) den samme fristen som SLA-merkelappene, oppsummeringen og SIEM-hendelsene for brudd: et funn i en avhengighet eller et image måles mot den forlengede SLA-en bare når alle gjeldende rader for det har vurderingen not reachable, og aldri når EPSS-verdien gjør det sannsynlig at det blir utnyttet. Der den forlengede SLA-en avviker fra policyens SLA, viser rapporten begge: «30, 60 if no call path» og hvor mange funn som ble målt mot den forlengede. CSV og JSON har sla_days (fristen som ble brukt), policy_sla_days, policy_sla_due_at og sla_multiplier per funn, og unreachable_sla_days og stretched_sla_findings per alvorlighetsgrad. Med multiplikatoren på 1 endres ingenting.

Funn i registerpakker vises bare for en organisasjon der pakkepolicy-pipelinen er slått på. Ellers utelater rapporten dem og sier fra om det; din egen pakkepolicy og unntakene for den listes likevel.

IaC etter benchmark og NIS2-område

Etter benchmark. Én rad per benchmark: hvor mange av kontrollene som har et åpent funn, hvor mange av kontrollene fremforges sjekker tester, de åpne funnene og ID-ene til kontrollene med funn. Koblingene er Trivys egne samsvarsspesifikasjoner (MIT), i den versjonen skannerne kjører, for ni benchmarker: CIS Docker 1.6.0, CIS Kubernetes 1.23, RKE2 CIS 1.24, EKS CIS 1.4, NSAs veiledning for herding av Kubernetes 1.0, Pod Security Standards baseline og restricted, og CIS AWS 1.2 og 1.4. Bare kontroll-ID-er, alvorlighetsgrader og sjekkene som tester dem, er tatt med; teksten i benchmarkene gjengis ikke (CIS publiserer den under sin egen lisens), og navnet på hver benchmark lenker til den publiserte spesifikasjonen. Det finnes ingen benchmark for Azure eller Google Cloud: Trivy publiserer ingen kobling for noen av dem.

Etter NIS2-område. De samme funnene etter tiltaket i NIS2 artikkel 21(2) hver sjekk berører: (b) hendelseshåndtering, (c) kontinuitet i virksomheten, (e) sikker konfigurasjon, (h) kryptografi og kryptering, (i) tilgangskontroll. Denne grupperingen er fremforges egen, laget ut fra tittelen på hver sjekk, fordi det ikke finnes noen åpen kobling fra disse sjekkene til NIS2. Den er ikke en offisiell kobling og sier ingenting om etterlevelse av noe tiltak.

Organisasjonens egne sjekker telles under NIS2-område (e) med mindre tittelen nevner et av de andre; de er ikke koblet til noen benchmark-kontroll. Uten åpne IaC-funn sier seksjonen det på én linje.

Formater

PDF-sammendrag: alle seksjoner oppsummert på noen få A4-sider, på konsollspråket ditt (engelsk, dansk, tysk, fransk, nederlandsk, norsk eller svensk).
CSV: én fil per seksjon (open, remediation, sla, exceptions, components, policy, findings, ai_inventory, iac_compliance), hver fullstendig, med stabile engelske kolonnenavn, for et regneark eller et skript. iac_compliance har én rad per benchmark-kontroll med funn og én per NIS2-område: grouping, framework, version, control, severity, checks (sjekk-ID-ene, adskilt med mellomrom) og open_findings.

Hver nedlasting registreres i revisjonsloggen som compliance.security_report.generated.

Perioden

Hele døgn i UTC, begge ender inkludert, høyst 366 dager. Standard er de siste 30 dagene. Et funn som ble åpnet kl. 00:00:00 den første dagen eller rettet kl. 23:59:59 den siste, regnes som innenfor perioden.

Hvor historikken kommer fra

De fleste skannere erstatter funnene sine ved hver skanning, så skannertabellene alene kan ikke si når noe ble rettet. fremforge registrerer derfor livsløpet til hvert funn (åpnet, rettet, avvist) én gang i døgnet for alle organisasjoner, og på nytt hver gang en rapport genereres. Rapporten leser denne registreringen, og den siste seksjonen, Om historikken, sier hva den kan og ikke kan vise:

Historikken begynner den datoen registreringen startet for organisasjonen din. En rettelse før den datoen telles bare der skanneren beholdt funnet (den markerer funn som en senere skanning ikke lenger rapporterer, og funn om ondsinnede pakker og registerpakker beholder sine egne datoer for løsning). For et funn som allerede var åpent, er åpningsdatoen den skanneren registrerte.
Tidspunktene for rettelser er nøyaktige til timen eller innenfor et døgn. Der skanneren markerte rettelsen, brukes tidspunktet derfra. Der et funn bare forsvant, registreres rettelsen når den daglige registreringen, eller en rapport, for første gang ikke lenger finner det.
Funn i et slettet, omdøpt eller overført repository telles som rettet den dagen de fjernes: etter gjenopprettingsvinduet på 30 dager for et slettet repository, eller når det gamle navnet ikke lenger finnes, for et repository som er slettet direkte, omdøpt eller overført. Se Oppbevaring av bevis.
SAST-funn som var åpne før registreringen begynte, har den siste skanningen som åpningsdato, fordi SAST-skanneren ikke beholder en dato for første gang funnet ble sett.
Avvisninger vises slik de står nå; en avvisning som ble opphevet senere, 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

Krever et token med findings:read. JSON-en er hele rapporten, inkludert 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

Legg den ved den ukentlige oppsummeringen

En eier av organisasjonen kan legge PDF-en ved sikkerhetsoppsummeringen: kryss av for Attach this report as a PDF to the security digest nederst på rapportsiden. Det er av som standard. Den vedlagte rapporten dekker oppsummeringens egen periode (7 dager, eller 1 dag for et daglig abonnement) og er på språket til hver mottaker.

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

Regelbaserte rettelser Lisensskanning