Unntak

Et unntak godtar en risiko for en begrenset periode: en sårbarhet du ikke kan rette ennå, et lisensfunn på et internt verktøy, en secret i en testfixture. Det fungerer på samme måte for alle typer funn (avhengigheter, containerimager, SAST, lisenser, secrets, skadevare i avhengigheter, registerpakker) og for unntak fra pakkepolicyer.

Et unntak trer i kraft bare når en annen person godkjenner det. Inntil da forblir funnet åpent, og policyen gjelder fortsatt.

En avvisning er et unntak som ikke trengte godkjenning. Avvisninger, også de som gjelder hele repositoryet eller hele imaget, listes, leses og tilbakekalles på samme sted og gjennom det samme API-et som godkjente unntak; se Unntak uten godkjenning.

Slik fungerer et unntak

1. Forespørsel. Alle som kan arbeide med funn, kan be om et unntak, med en begrunnelse og en utløpsdato. Datoen kan ligge høyst så langt frem som organisasjonens øvre grense (366 dager, med mindre du setter en lavere).
2. Godkjenn eller avvis. En annen godkjenner enn den som ba om unntaket, bestemmer, med en valgfri kommentar. Godkjennerne får e-post når en forespørsel kommer inn, på sitt eget språk.
3. I kraft. Funnet er avvist til utløpsdatoen. Funnet registrerer hvem som ba om det (dismissed_by) og hvem som godkjente (dismissal_approved_by). En ny skanning beholder avvisningen.
4. Slutten. På utløpsdatoen åpnes funnet igjen, og unntaket merkes expired.

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

Hvem kan godkjenne

• Som standard: organisasjonens eiere og personene på listen over godkjennere for pakkepolicyer.
• Eller, hvis du navngir et godkjennerteam i innstillingene: bare medlemmene av det teamet.

Ingen kan godkjenne sin egen forespørsel: konsollen viser dem ingen Approve-knapp, og API-et svarer self-approve. Et token uten en person bak, og legitimasjonen til en AI-agent, kan ikke avgjøre et unntak i det hele tatt (user-identity-required).

Automatisk tilbakekalling

Et godkjent unntak tilbakekalles, og funnet åpnes igjen med en gang, når:

At godkjenneren forlater organisasjonen, håndteres i det medlemskapet endres; de andre sjekkene kjører hver time. reachability_changed tilbakekaller også en vanlig avvisning som bygde på en vurdering om at det ikke finnes noen kallsti; se Nåbarhet.

Revisjon og SIEM

Hvert steg er en revisjonshendelse for organisasjonen: code-security.exception.requested, .approved, .rejected, .revoked og .expired for funn, og package_policy.exception.* for pakkepolicyer. En tilbakekallingshendelse inneholder årsaken og hva som endret seg. Som alle revisjonshendelser når de SIEM-endepunktene dine; filtrer på handlingsprefikset code-security.exception. for å motta bare disse.

I konsollen

Åpne Sikkerhet › Funn › Unntak. Siden har:

• Venter på godkjenning: forespørslene som venter, hver med Approve og Reject og et kommentarfelt. Dine egne forespørsler viser ingen Approve-knapp.
• Gjeldende: godkjente unntak, med Revoke.
• Godtatt uten godkjenning: avvisninger, inkludert de som gjelder hele repositoryet eller hele imaget, med et filter for type og Revoke. Se Unntak uten godkjenning.
• Historikk: avviste, tilbakekalte og utløpte unntak, med hvem som bestemte, kommentaren og, for en tilbakekalling, hvorfor.
• Be om et unntak for et funn: på siden til et hvilket som helst funn har avvisningsskjemaet en Request an exception-lenke som fyller ut dette for deg.
• Innstillinger: hvor lenge et unntak høyst kan gjelde, godkjennerteamet og Dismissals require approval.

API

Basis-URL https://frem.sh/_app/api/v1. Se API-referansen for de fullstendige formatene.

scanner er én av deps, images, sast, licenses, secrets, package_malware og packages; finding_id er den id-en endepunktene for funn returnerer. expires_at er en dato (YYYY-MM-DD, til og med den dagen UTC) eller et ISO 8601-tidspunkt. En ny forespørsel for et funn som allerede har et ventende eller godkjent unntak, besvares med 409 duplicate-pending.

Be om et unntak for et avhengighetsfunn:

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"}'

Et lisensunntak for pakkepolicyen:

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"}'

Innstillinger som kode

PUT /orgs/{org}/exceptions/settings er en vanlig idempotent skriving, så den øvre grensen og godkjennerteamet kan ligge i konfigurasjonsrepositoryet ditt sammen med resten av organisasjonens innstillinger:

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"}'

Unntak uten godkjenning

Avvisningsknappen på et funn er måten én person kan godta det på. Den registrerer hvem som avviste og hvorfor, og kan ha en utløpsdato. Det er ingen annen person involvert, så det er et unntak uten godkjenning. Bruk et godkjent unntak når du trenger fire øyne, eller slå på Dismissals require approval for at hver avvisning fra noen som ikke er godkjenner, skal gå gjennom en godkjenning.

Det finnes tre typer, og hver av dem listes under Accepted without approval i konsollen og av GET /orgs/{org}/exceptions?approval=none:

Hver oppføring har "approval": "none", "status": "approved" (i kraft) og de samme feltene som alle unntak: justification er årsaken til avvisningen, requested_by hvem som avviste, og expires_at utløpsdatoen eller null. Med approval=all har godkjente unntak "approval": "required". Uten approval-parameteren er listen nøyaktig som før.

En avvisning som har løpt ut, listes ikke: den daglige utløpsjobben åpner funnene igjen. Heller ikke listet: funn som et godkjent unntak har avvist (unntaket er oppføringen), funn som har forsvunnet av seg selv, og lisensfunn som lisenstillatelseslisten din avviser, siden det er den listen som styrer dem.

Tilbakekall åpner funnene igjen med en gang, og et høyt eller kritisk funn varsler på nytt. Å tilbakekalle en avvisning for hele repositoryet eller hele imaget sletter også avgjørelsen, så senere skanninger slutter å ta den med; det krever policy:write, som DELETE /orgs/{org}/code-security/deps/repo-dismissals/{id}. Hver tilbakekalling 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"

Avvisninger krever godkjenning

En innstilling per organisasjon, av som standard. Når den er på, avviser en avvisning av et funn for en avhengighet, SAST, en secret, et containerimage, en lisens eller skadevare i en avhengighet ingenting når den kommer fra noen som ikke er godkjenner. I stedet:

• får hvert åpent funn en forespørsel om unntak, med avvisningens årsak som begrunnelse og dens utløpsdato (organisasjonens øvre grense når avvisningen ikke hadde noen);
• forblir funnet åpent, og godkjennerne får e-post;
• godkjenner eller avviser en godkjenner som ikke er personen som avviste, den i køen. Godkjenning avviser funnet med begge navnene, nøyaktig som ethvert annet unntak. Ingen kan godkjenne sin egen avvisning.

En avvisning på en beskyttet utgivelsesbranch er et unntak med ID-en branch.<finding id> og scopet branch. Den går ikke gjennom denne køen ennå: mens denne innstillingen er på, kan bare en godkjenner avvise på en utgivelsesbranch, og alle andre får 403 approval-required.

Godkjennere avviser fortsatt direkte. I konsollen blir du ført til unntakskøen med en melding når en avvisning er sendt til godkjenning. Over API-et svarer da hvert endepunkt for avvisning og masseavvisning 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 lister funn som ikke ble lagt i køen: not-found (ikke åpent, eller ikke ditt) eller duplicate-pending (det har allerede et ventende eller godkjent unntak). En avvisning av ett enkelt funn svarer i stedet 404 eller 409 duplicate-pending for disse. En utløpsdato utover den øvre grensen din avvises med 400 invalid-expires-at.

Et skadevarefunn på en opplastet fil (Sikkerhet › Funn › Skadevareskanning av opplastinger) har ingen årsak eller utløpsdato å sende gjennom køen. Mens innstillingen er på, kan bare en godkjenner avvise et slikt funn; alle andre får 403 not-an-approver.

Slå den på under Sikkerhet › Funn › Unntak › Innstillinger, 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-modulen. Å slå den på eller av skriver revisjonshendelsene exceptions.dismissal_approval.enabled og .disabled. En forespørsel laget fra en avvisning er den vanlige code-security.exception.requested-hendelsen med "via": "dismissal". Forespørsler som allerede venter, blir liggende i køen når du slår den av, og kan fortsatt godkjennes.