Gå til hovedinnhold

SLA for utbedring

Hvert åpent funn (SAST, avhengigheter, containerimager, skadevare) har en SLA-merkelapp ved siden av alvorlighetsgraden. Merkelappen beregnes ut fra én inndata – hvor gammelt funnet er – og én innstilling – organisasjonens SLA-policy per alvorlighetsgrad.

Standardverdier

Alle organisasjoner får disse målene rett ut av boksen:

AlvorlighetsgradStandard-SLA
Critical7 dager
High30 dager
Medium90 dager
Lowingen SLA

Standardverdiene følger vanlige rytmer for patching i store virksomheter, slik de er omtalt i NIST SP 800-40r4 og lignende rammeverk. Stram dem inn hvis revisjonskravene dine krever det.

Tilstander merkelappen kan vise

Fargen på merkelappen viser tilstanden, og teksten viser dagene.

  • Within (grønn) – innenfor SLA-en, mindre enn 80 % av veien til fristen. Merkelappen viser alderen på funnet mot SLA-en, for eksempel 12 d / 30 d.
  • Approaching (gul) – mellom 80 % og 100 % av fristen. Planlegg en retting denne uken. Merkelappen viser dagene som er igjen, for eksempel 5 d igjen.
  • Breached (rød) – fristen er passert. Telles i den ukentlige oppsummeringen og i flisen «SLA-brudd» på oversikten. Merkelappen viser hvor langt fristen er overskredet, for eksempel 3 d over SLA.
  • Ingen SLA (grå) – alvorlighetsgraden har ingen policy knyttet til seg (standard for low). Merkelappen viser Ingen SLA.

Terskelen på 80 % av fristen for approaching er bevisst valgt – de fleste rettelser krever reelt arbeid med å sette i gang, gjennomgå og rulle ut, og et varsel før fristen gir deg den tiden.

Sette policy per organisasjon

SLA-en per organisasjon redigeres under Sikkerhet › Prioriter › SLA for utbedring (/<org>/_admin/security/prioritise/sla). Velg en strammere frist per alvorlighetsgrad – brudd-beregningen leser raden security_sla_policy for organisasjonen umiddelbart, uten ny skanning. Standardverdiene over gjelder til du overstyrer dem. Trenger du en egen SLA som ikke er tidsbasert (for eksempel virkedager eller helligdagskalendere), åpne en supporthenvendelse.

Funn som ikke er nåbare (valgfri multiplikator)

For funn i avhengigheter og containerimager beregner fremforge en vurdering av nåbarhet. Organisasjonen din kan forlenge SLA-en for funn som er vurdert not reachable (unreachable) med en heltallsfaktor fra 1 til 4. Multiplikatoren settes på den samme siden, Sikkerhet › Prioriter › SLA for utbedring. Standardverdien 1 betyr av.

VurderingSLA
Ingen kallsti (unreachable)Full SLA × multiplikatoren
Nåbar, ukjent eller ikke analysertAlltid full SLA
Kjent utnyttet: oppført av EU (ENISA EUVD) eller USA (CISA KEV)Full SLA, uansett alvorlighetsgrad og vurdering
Critical med EPSS blant de øverste 10 %Full SLA, uansett vurdering

Fristen regnes alltid fra da funnet ble sett første gang. Finner en senere skanning en kallsti, eller kan den ikke avgjøre, gjelder full SLA igjen med en gang, slik at et funn kan gå rett til Breached. En forlenget merkelapp viser ×2 (eller ×3, ×4), og verktøytipset viser begge fristene. Når multiplikatoren er på, forklarer verktøytipset på en merkelapp med full SLA hvorfor den ikke er forlenget. Funn fra SAST, lisenser, secrets og skadevare har ingen vurdering og beholder full SLA.

Multiplikatoren endrer bare fristene. Det som blokkerer en pull request, er uendret, og ingen funn skjules eller avvises.

Funn på beskyttede release-brancher viser også en frist fra denne policyen, men de telles ikke med i SLA-brudd, SLA-flisen eller noen SLA-måling.

Om omfanget av SLA-en. Tabellen over er klokken for utbedring av funn – hvor lang tid du har på å lukke et funn i koden din. Den er forskjellig fra to andre SLA-er som er dokumentert andre steder hos fremforge:

  • SLA for patching av plattform-CVE-er (Critical 48 t / High 72 t / Medium 7 d) gjelder hvor raskt fremforge patcher sin egen stack – se forpliktelsene for plattformsikkerhet under Sikkerhet og forsyningskjede.
  • SLA for sårbarhetsrapportering (Critical rettet innen 24 t / offentliggjort 30 d etter retting osv.) gjelder sårbarheter i selve fremforge som er rapportert av forskere – se Sårbarhetsrapportering.

Via REST-API

SLA-policyen kan settes gjennom det offentlige API-et – nyttig når du vil håndheve samme praksis i mange organisasjoner fra et konfigurasjonsskript eller en compliance-pipeline.

  • Oppdater policy PUT /_app/api/v1/orgs/:slug/security/sla-policy med body: { "critical_sla_days": 3, "high_sla_days": 14, "medium_sla_days": 60, "low_sla_days": null, "unreachable_sla_multiplier": 2 }

Hvert dagfelt godtar 1–365 dager, eller null for å la en alvorlighetsgrad være uten SLA; et dagfelt som mangler, er null. unreachable_sla_multiplier godtar et heltall fra 1 (av) til 4; i motsetning til dagfeltene beholdes den lagrede verdien hvis feltet utelates. GET /_app/api/v1/orgs/:slug/security returnerer policyen. Hver endring revisjonslogges som code-security.sla_policy.updated, med forrige multiplikator når den ble endret. Krever et personlig tilgangstoken (PAT) med scopet policy:write:

curl -X PUT \
  -H "Authorization: Bearer ${FREMFORGE_PAT}" \
  -H "Content-Type: application/json" \
  -d '{"critical_sla_days":3,"high_sla_days":14,"medium_sla_days":60,"low_sla_days":null}' \
  https://frem.sh/_app/api/v1/orgs/acme/security/sla-policy

Se referansen for det offentlige REST-API-et for hele OpenAPI-spesifikasjonen.

Compliance-rapporten måler SLA-etterlevelse over en periode du velger: funn rettet innenfor SLA-en, rettet etter den og fortsatt åpne etter fristen, per alvorlighetsgrad. Når multiplikatoren er på, måles hvert funn mot den samme fristen som merkelappen viser, og policy-SLA-en vises ved siden av den forlengede.

Hvordan brudd påvirker andre sider

  • Widgeten for åpne sikkerhets-PR-er på /<org>/_admin/overview fremhever først anbefalingen med høyest alvorlighetsgrad som har brutt fristen.
  • Den ukentlige oppsummeringen teller brudd i hovedsammendraget.
  • SIEM-videresending sender revisjonshendelsen code-security.sla.breached første gang et funn passerer fristen. Når multiplikatoren er på, har hendelsen for et forlenget funn også med full_sla_days og unreachable_sla_multiplier.

Tallet i oppsummeringen, flisen på oversikten og SIEM-hendelsen bruker alle de samme fristene som merkelappene, inkludert multiplikatoren. Findings-API-et returnerer dem også, som et sla-objekt på hvert funn i avhengigheter og imager (state, sla_days, due_at, full_sla_days, full_due_at, unreachable_multiplier, exempt). exempt er known_exploited (med exempt_sources: euvd, cisa_kev) eller exploit_likely (critical, EPSS blant de øverste 10 %) når en påslått multiplikator ikke ble brukt av den grunnen, ellers null.

Se også