Undtagelser

En undtagelse accepterer en risiko i en begrænset periode: en sårbarhed, du ikke kan rette endnu, et licensfund på et internt værktøj, en secret i en testfixture. Den virker på samme måde for alle slags fund (afhængigheder, container-images, SAST, licenser, secrets, malware i afhængigheder, registry-pakker) og for undtagelser fra pakkepolitikker.

En undtagelse træder først i kraft, når en anden person godkender den. Indtil da forbliver fundet åbent, og politikken gælder stadig.

En afvisning er en undtagelse, der ikke krævede godkendelse. Afvisninger, også dem for hele et repository eller hele et image, vises, læses og tilbagekaldes samme sted og gennem det samme API som godkendte undtagelser; se Undtagelser uden godkendelse.

Sådan virker en undtagelse

Anmodning. Alle, der kan arbejde med fund, kan anmode om en med en begrundelse og en udløbsdato. Datoen må højst ligge din organisations loft ude i fremtiden (366 dage, medmindre du sætter et lavere).
Godkend eller afslå. En anden godkender end den, der anmoder, træffer afgørelsen, eventuelt med en kommentar. Godkenderne får en e-mail, når der kommer en anmodning, på deres eget sprog.
I kraft. Fundet er afvist indtil udløbsdatoen. Fundet registrerer, hvem der anmodede (dismissed_by), og hvem der godkendte (dismissal_approved_by). En ny scanning bevarer afvisningen.
Afslutningen. På udløbsdatoen åbnes fundet igen, og undtagelsen markeres som expired.

Tilstandene er requested, approved, rejected, expired og revoked.

Hvem der kan godkende

Som standard: organisationens ejere og personerne på listen over godkendere for pakkepolitikker.
Eller, hvis du angiver et godkenderteam i indstillingerne: kun medlemmerne af det team.

Ingen kan godkende deres egen anmodning: konsollen viser dem ingen knap til at godkende, og API’et svarer self-approve. Et token uden en person bag og en AI-agents legitimationsoplysninger kan slet ikke træffe afgørelse om en undtagelse (user-identity-required).

Automatisk tilbagekaldelse

En godkendt undtagelse tilbagekaldes, og dens fund åbnes igen med det samme, når:

Udløser	Årsag til tilbagekaldelse
Nogen tilbagekalder den manuelt	`manual`
Fundets alvorlighed stiger over det, der blev godkendt	`severity_raised`
En ny sårbarhed dukker op på den samme komponent (samme pakke og version eller samme image-pakke)	`new_vulnerability`
Godkenderen forlader organisationen	`approver_left`
Undtagelsen byggede på en vurdering af ikke nåbar, og en senere scanning finder fundet nåbart eller kan ikke afgøre det	`reachability_changed`

Når godkenderen forlader organisationen, handles der, i det øjeblik medlemskabet ændres; de øvrige tjek kører hver time. reachability_changed tilbagekalder også en almindelig afvisning, der byggede på en vurdering af, at der ikke er nogen kaldesti; se Nåbarhed.

Revision og SIEM

Hvert trin er en revisionshændelse for tenanten: code-security.exception.requested, .approved, .rejected, .revoked og .expired for fund og package_policy.exception.* for pakkepolitikker. En hændelse for tilbagekaldelse har sin årsag og det, der ændrede sig. Som alle revisionshændelser når de dine SIEM-endpoints; filtrér på handlingspræfikset code-security.exception. for kun at modtage disse.

I konsollen

Åbn Sikkerhed › Fund › Undtagelser. Siden har:

Venter på godkendelse: de verserende anmodninger, hver med Godkend og Afvis (afslå) og et kommentarfelt. Dine egne anmodninger viser ingen knap til at godkende.
I kraft: godkendte undtagelser med Tilbagekald.
Accepteret uden godkendelse: afvisninger, også dem for hele et repository eller image, med et filter for type og Tilbagekald. Se Undtagelser uden godkendelse.
Historik: afslåede, tilbagekaldte og udløbne undtagelser med, hvem der traf afgørelsen, kommentaren og, for en tilbagekaldelse, hvorfor.
Anmod om en undtagelse for et fund: på ethvert funds side har formularen til afvisning et link, Anmod om en undtagelse, som udfylder dette for dig.
Indstillinger: hvor længe en undtagelse højst må gælde, godkenderteamet og Afvisninger kræver godkendelse.

API

Basis-URL https://frem.sh/_app/api/v1. Se API-referencen for de fulde formater.

Metode og sti	Scope	Hvad den gør
`GET /orgs/{org}/exceptions`	`findings:read`	Alle undtagelser, der er godkendt af en anden person, nyeste først. Filtrér med `status` (kommasepareret), `kind` (`finding` eller `package`) og `scanner`. Tilføj `approval=none` for undtagelser uden godkendelse eller `approval=all` for begge.
`POST /orgs/{org}/exceptions`	`findings:write`	Anmod om en. For et fund: `scanner`, `finding_id`, `justification`, `expires_at`. For en pakkepolitik: `"kind": "package"` og felterne for en undtagelse fra en pakkepolitik.
`GET /orgs/{org}/exceptions/{id}`	`findings:read`	Én undtagelse, godkendt eller ej.
`POST /orgs/{org}/exceptions/{id}/approve`	`findings:write`	Godkend, eventuelt med `{"comment": "..."}`.
`POST /orgs/{org}/exceptions/{id}/reject`	`findings:write`	Afslå, eventuelt med en kommentar.
`POST /orgs/{org}/exceptions/{id}/revoke`	`findings:write`	Træk en anmodning tilbage, eller tilbagekald en undtagelse. En for hele et repository eller image kræver `policy:write`.
`GET`, `PUT /orgs/{org}/exceptions/settings`	`policy:read`, `policy:write`	`max_days` (1 til 366), `approver_team` (et teamnavn eller `null` for ejere plus godkenderlisten) og `dismissals_require_approval` (`true` eller `false`).

scanner er en af deps, images, sast, licenses, secrets, package_malware og packages; finding_id er det id, som endpoints for fund returnerer. expires_at er en dato (YYYY-MM-DD, til og med den dag UTC) eller et ISO 8601-tidspunkt. En ny anmodning for et fund, der allerede har en verserende eller godkendt undtagelse, besvares med 409 duplicate-pending.

Anmod om en undtagelse for et fund i en afhængighed:

curl -sS -X POST https://frem.sh/_app/api/v1/orgs/acme/exceptions \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" -H 'Content-Type: application/json' \
  -d '{"scanner":"deps","finding_id":"<id>","justification":"Not reachable from user input; fixed by the framework upgrade.","expires_at":"2026-12-31"}'

En licensundtagelse for pakkepolitikken:

curl -sS -X POST https://frem.sh/_app/api/v1/orgs/acme/exceptions \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" -H 'Content-Type: application/json' \
  -d '{"kind":"package","scope":"package","rule_kind":"licence","rule_selector":"GPL-3.0-only","pkg_type":"npm","name":"left-pad","justification":"Internal tool, never distributed.","expires_at":"2026-12-31"}'

Indstillinger som kode

PUT /orgs/{org}/exceptions/settings er en almindelig idempotent skrivning, så loftet og godkenderteamet kan ligge i dit konfigurationsrepository sammen med resten af din organisations indstillinger:

curl -sS -X PUT https://frem.sh/_app/api/v1/orgs/acme/exceptions/settings \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" -H 'Content-Type: application/json' \
  -d '{"max_days": 90, "approver_team": "security"}'

Undtagelser uden godkendelse

Knappen til at afvise et fund er måden, én person kan acceptere det på. Den registrerer, hvem der afviste og hvorfor, og kan have en udløbsdato. Der er ingen anden person, så det er en undtagelse uden godkendelse. Brug en godkendt undtagelse, når du har brug for fire øjne, eller slå Afvisninger kræver godkendelse til, så enhver afvisning fra en, der ikke er godkender, skal igennem en.

Der er tre slags, som hver vises under Accepteret uden godkendelse i konsollen og af GET /orgs/{org}/exceptions?approval=none:

Slags	`scope`	`id`	Hvad den dækker
Afvisning	`finding`	`dismissal.<scanner>.<hash>`	Ét fund. Id’et er det samme på tværs af nye scanninger. `findings_count` angiver, hvor mange scanningsresultater den dækker nu, for eksempel det samme fund på flere pull requests.
Afvisning af en afhængighed for hele repositoryet	`repo`	`repo.<uuid>`	Én advisory i én pakke og ét manifest i alle senere scanninger af repositoryet.
Afvisning for hele imaget	`image`	`image.<uuid>`	Ét fund i et container-image i alle senere scanninger af imaget.

Hver post har "approval": "none", "status": "approved" (i kraft) og de samme felter som enhver undtagelse: justification er afvisningens begrundelse, requested_by den, der afviste, og expires_at dens udløbsdato eller null. Med approval=all har godkendte undtagelser "approval": "required". Uden parameteren approval er listen præcis, som den var før.

En afvisning, der er udløbet, vises ikke: det daglige udløbsjob genåbner dens fund. Heller ikke vist: fund, som en godkendt undtagelse har afvist (undtagelsen er posten), fund, der forsvandt af sig selv, og licensfund, som din tilladelsesliste for licenser afviser, og som den liste styrer.

Tilbagekald genåbner fundene med det samme, og et højt eller kritisk fund udløser en advarsel igen. Tilbagekalder du en for hele et repository eller image, slettes afgørelsen også, så senere scanninger ikke længere bærer den; det kræver policy:write ligesom DELETE /orgs/{org}/code-security/deps/repo-dismissals/{id}. Hver tilbagekaldelse revideres: code-security.<scanner>.dismissal_revoked eller code-security.deps.repo_dismissal_revoked og code-security.images.repo_dismissal_revoked.

curl -sS "https://frem.sh/_app/api/v1/orgs/acme/exceptions?approval=none&scanner=deps" \
  -H "Authorization: Bearer $FREMFORGE_TOKEN"

curl -sS -X POST "https://frem.sh/_app/api/v1/orgs/acme/exceptions/dismissal.deps.3f1c0a9e5b7d2c4e6f8a0b1c/revoke" \
  -H "Authorization: Bearer $FREMFORGE_TOKEN"

Afvisninger kræver godkendelse

En indstilling pr. organisation, som er slået fra som standard. Når den er slået til, afviser en afvisning af et fund i en afhængighed, SAST, en secret, et container-image, en licens eller malware i en afhængighed ingenting, hvis den foretages af en, der ikke er godkender. I stedet:

får hvert åbent fund en anmodning om en undtagelse med afvisningens begrundelse som begrundelse og dens udløbsdato (din organisations loft, hvis afvisningen ikke havde nogen);
forbliver fundet åbent, og godkenderne får en e-mail;
godkender eller afslår en godkender ud over den, der afviste, den i køen. En godkendelse afviser fundet med begge navne, præcis som enhver anden undtagelse. Ingen kan godkende deres egen afvisning.

En afvisning på en beskyttet release-branch er en undtagelse med id’et branch.<finding id> og scopet branch. Den går endnu ikke gennem denne kø: mens indstillingen er slået til, kan kun en godkender afvise på en release-branch, og alle andre får 403 approval-required.

Godkendere afviser stadig direkte. I konsollen sender en afvisning, der gik til godkendelse, dig til køen af undtagelser med en meddelelse. Over API’et svarer alle endpoints til afvisning og masseafvisning så 202 i stedet for 200:

{
  "dismissed": false,
  "status": "pending_approval",
  "pending_count": 1,
  "exceptions": [
    { "id": "<exception id>", "finding_id": "<finding id>", "status": "pending_approval", "expires_at": "2027-10-11T15:00:00.000Z" }
  ],
  "skipped": []
}

skipped angiver fund, der ikke blev sat i kø: not-found (ikke åbent eller ikke dit) eller duplicate-pending (det har allerede en verserende eller godkendt undtagelse). En afvisning af et enkelt fund svarer i stedet 404 eller 409 duplicate-pending i de tilfælde. En udløbsdato ud over dit loft afvises med 400 invalid-expires-at.

Et malwarefund på en uploadet fil (Sikkerhed › Fund › Malwarescanning af uploads) har ingen begrundelse eller udløbsdato at sende gennem køen. Mens indstillingen er slået til, kan kun en godkender afvise et; alle andre får 403 not-an-approver.

Slå den til under Sikkerhed › Fund › Undtagelser › Indstillinger eller over API’et:

curl -sS -X PUT https://frem.sh/_app/api/v1/orgs/acme/exceptions/settings \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" -H 'Content-Type: application/json' \
  -d '{"dismissals_require_approval": true}'

eller med exception_settings i Terraform-modulet. At slå den til eller fra skriver revisionshændelserne exceptions.dismissal_approval.enabled og .disabled. En anmodning, der stammer fra en afvisning, er den almindelige hændelse code-security.exception.requested med "via": "dismissal". Anmodninger, der allerede venter, bliver i køen, når du slår den fra, og kan stadig godkendes.

Udbedringsmålinger Anonyme tal