Undantag

Ett undantag accepterar en risk under en begränsad tid: en sårbarhet som du inte kan åtgärda än, ett licensfynd i ett internt verktyg, en hemlighet i en testfixtur. Det fungerar på samma sätt för alla sorters fynd (beroenden, container-images, SAST, licenser, hemligheter, skadlig kod i beroenden, registerpaket) och för undantag från paketpolicyn.

Ett undantag börjar gälla först när en andra person godkänner det. Fram till dess förblir fyndet öppet och policyn gäller fortfarande.

Ett avfärdande är ett undantag som inte behövde godkännas. Avfärdanden, även de som gäller hela repot eller hela imagen, listas, läses och återkallas på samma ställe och via samma API som godkända undantag; se Undantag utan godkännande.

Så fungerar ett undantag

1. Begäran. Den som kan arbeta med fynd begär ett, med en motivering och ett utgångsdatum. Datumet får ligga högst så långt fram som din organisations tak tillåter (366 dagar om du inte har angett ett lägre).
2. Godkänn eller avvisa. En godkännare som inte är den som begärde beslutar, med en valfri kommentar. Godkännarna får ett mejl när en begäran kommer in, på sitt eget språk.
3. Gäller. Fyndet är avfärdat fram till utgångsdatumet. Fyndet registrerar vem som begärde (dismissed_by) och vem som godkände (dismissal_approved_by). En ny skanning behåller avfärdandet.
4. Slutet. På utgångsdatumet öppnas fyndet igen, och undantaget markeras expired.

Tillstånden är requested, approved, rejected, expired och revoked.

Vem som kan godkänna

• Som standard: organisationens ägare och personerna på listan över godkännare för paketpolicyn.
• Eller, om du anger ett team för godkännare i inställningarna: bara medlemmarna i det teamet.

Ingen kan godkänna sin egen begäran: konsolen visar ingen knapp för att godkänna, och API:t svarar self-approve. En token som inte har någon person bakom sig, och en AI-agents inloggningsuppgifter, kan inte besluta om ett undantag alls (user-identity-required).

Automatiskt återkallande

Ett godkänt undantag återkallas, och dess fynd öppnas igen direkt, när:

När godkännaren lämnar hanteras det när medlemskapet ändras; de övriga kontrollerna körs varje timme. reachability_changed återkallar också ett vanligt avfärdande som byggde på bedömningen att anropsväg saknas; se Nåbarhet.

Granskning och SIEM

Varje steg är en granskningshändelse för tenanten: code-security.exception.requested, .approved, .rejected, .revoked och .expired för fynd, och package_policy.exception.* för paketpolicyer. En händelse om återkallande innehåller orsaken och vad som ändrades. Som alla granskningshändelser når de dina SIEM-slutpunkter; filtrera på åtgärdsprefixet code-security.exception. för att bara få dessa.

I konsolen

Öppna Säkerhet › Fynd › Undantag. Sidan har:

• Väntar på godkännande: de väntande begärandena, var och en med Godkänn och Avvisa och en kommentarsruta. Dina egna begäranden visar ingen knapp för att godkänna.
• Gäller: godkända undantag, med Återkalla.
• Accepterade utan godkännande: avfärdanden, inklusive de som gäller hela repot eller hela imagen, med ett filter för typ och Återkalla. Se Undantag utan godkännande.
• Historik: avvisade, återkallade och utgångna undantag, med vem som beslutade, kommentaren och, för ett återkallande, varför.
• Begär ett undantag för ett fynd: på varje fynds sida har formuläret för att avfärda länken Begär ett undantag (godkänns av någon annan) som fyller i detta åt dig.
• Inställningar: hur länge ett undantag längst får gälla, teamet för godkännare och Avfärdanden kräver godkännande.

API

Bas-URL https://frem.sh/_app/api/v1. Se API-referensen för de fullständiga strukturerna.

scanner är en av deps, images, sast, licenses, secrets, package_malware och packages; finding_id är det id som slutpunkterna för fynd returnerar. expires_at är ett datum (YYYY-MM-DD, till och med den dagen i UTC) eller en tidpunkt enligt ISO 8601. En andra begäran för ett fynd som redan har ett väntande eller godkänt undantag svarar 409 duplicate-pending.

Begär ett undantag för ett beroendefynd:

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

Ett licensundantag för paketpolicyn:

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

Inställningar som kod

PUT /orgs/{org}/exceptions/settings är en vanlig idempotent skrivning, så taket och teamet för godkännare kan ligga i ditt konfigurationsrepo bredvid resten av organisationens inställningar:

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

Undantag utan godkännande

Knappen för att avfärda ett fynd är sättet för en enda person att acceptera det. Den registrerar vem som avfärdade och varför, och kan ha ett utgångsdatum. Det finns ingen andra person, så det är ett undantag utan godkännande. Använd ett godkänt undantag när du behöver fyra ögon, eller slå på Avfärdanden kräver godkännande så att varje avfärdande av någon som inte är godkännare går genom ett sådant.

Det finns tre sorter, som var och en listas under Accepterade utan godkännande i konsolen och av GET /orgs/{org}/exceptions?approval=none:

Varje post har "approval": "none", "status": "approved" (gäller) och samma fält som alla undantag: justification är avfärdandets orsak, requested_by den som avfärdade och expires_at dess utgångsdatum eller null. Med approval=all har godkända undantag "approval": "required". Utan parametern approval är listan exakt som den var tidigare.

Ett avfärdande som har löpt ut listas inte: det dagliga utgångsjobbet öppnar dess fynd igen. Inte heller listas: fynd som ett godkänt undantag avfärdade (undantaget är posten), fynd som försvann av sig själva, och licensfynd som din lista över tillåtna licenser avfärdar, eftersom den listan styr dem.

Återkalla öppnar fynden igen direkt, och ett fynd med hög eller kritisk allvarlighetsgrad ger varning igen. Att återkalla ett avfärdande för hela repot eller hela imagen tar också bort beslutet, så att senare skanningar slutar bära det; det kräver policy:write, precis som DELETE /orgs/{org}/code-security/deps/repo-dismissals/{id}. Varje återkallande granskas: code-security.<scanner>.dismissal_revoked, eller code-security.deps.repo_dismissal_revoked och 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"

Avfärdanden kräver godkännande

En inställning per organisation, avstängd som standard. När den är på avfärdar ett avfärdande av ett fynd för beroende, SAST, hemlighet, container-image, licens eller skadlig kod i beroenden ingenting om det görs av någon som inte är godkännare. I stället:

• får varje öppet fynd en begäran om undantag, med avfärdandets orsak som motivering och dess utgångsdatum (din organisations tak om avfärdandet saknade ett);
• förblir fyndet öppet, och godkännarna får ett mejl;
• godkänner eller avvisar en godkännare som inte är den som avfärdade det i kön. Ett godkännande avfärdar fyndet med båda namnen, precis som vilket annat undantag som helst. Ingen kan godkänna sitt eget avfärdande.

Ett avfärdande på en skyddad release-branch är ett undantag med id:t branch.<finding id> och scope branch. Det går inte genom den här kön än: så länge inställningen är på kan bara en godkännare avfärda på en release-branch, och alla andra får 403 approval-required.

Godkännare avfärdar fortfarande direkt. I konsolen tar ett avfärdande som skickades för godkännande dig till kön för undantag med ett meddelande. Via API:t svarar då varje slutpunkt för att avfärda och för att avfärda i bulk 202 i stället för 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 listar fynd som inte köades: not-found (inte öppet, eller inte ditt) eller duplicate-pending (det har redan ett väntande eller godkänt undantag). Ett avfärdande av ett enskilt fynd svarar i stället 404 eller 409 duplicate-pending för dessa. Ett utgångsdatum bortom ditt tak avvisas med 400 invalid-expires-at.

Ett fynd av skadlig kod i en uppladdad fil (Säkerhet › Fynd › Skanning av uppladdningar) har ingen orsak eller något utgångsdatum att skicka genom kön. Så länge inställningen är på kan bara en godkännare avfärda ett sådant; alla andra får 403 not-an-approver.

Slå på den under Säkerhet › Fynd › Undantag › Inställningar, via API:t:

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. Att slå på eller av den skriver granskningshändelserna exceptions.dismissal_approval.enabled och .disabled. En begäran som skapats från ett avfärdande är den vanliga händelsen code-security.exception.requested med "via": "dismissal". Begäranden som redan väntar finns kvar i kön när du stänger av inställningen, och kan fortfarande godkännas.