Målinger av utbedring

Målinger av utbedring viser om funksjonene for triagering og rettelser gjør jobben sin for organisasjonen din. Siden måler suksessmålene for nåbarhet og sikkerhetsrettelser på dine egne funn, over de siste 30 eller 90 dagene, og sammenligner hver periode med like mange dager rett før.

Du finner den under Sikkerhet › Rapporter › Utbedringstall (/<org>/_admin/security/reports/remediation). Eiere av organisasjonen og medlemmer av organisasjonens team Auditors kan åpne den. Velg Siste 30 dager eller Last 90 days øverst på siden.

Hvert tall gjelder bare organisasjonen din. Ingenting sammenlignes med eller beregnes ut fra andre organisasjoner.

Samme side har kortet Bidra med anonyme tall: et tilvalg, av som standard, som legger organisasjonens tellinger anonymt til tallene fremforge publiserer. Se Anonyme tellinger.

Hva den viser

Hvordan tallene lages

• Unike funn. Et avhengighetsfunn er ett per repository, pakke og sårbarhetsvarsel, uansett hvor mange brancher eller pull requests som rapporterer det. De åpne avhengighetsfunnene telles på samme måte hver dag i utviklingen.
• Det daglige øyeblikksbildet tas én gang om dagen bare for organisasjonen din, fra samme telling som dekningstallene over, og kombineres aldri med andre organisasjoners data. Det beholdes like lenge som innstillingen for funnhistorikk når du har satt en, ellers i 18 måneder, og slettes når organisasjonen slettes. En rettslig tilbakeholdelse (legal hold) beholder det.
• Vurderinger er ikke avvisninger. Et funn som ikke er nåbart, forblir åpent og telles som åpent overalt. Se nåbarhet.
• Pull requests med sikkerhetsrettelser telles etter datoen rettelsen ble bedt om. En pull request som fortsatt venter på gjennomgang, senker merge-raten til den er merget eller lukket.
• Tid til utbedring og SLA-brudd kommer fra funnhistorikken, som starter da organisasjonen begynte å spore historikk (siden oppgir datoen). Et funn som allerede var åpent på den datoen, telles fra da det først ble lagret.
• Hva som regnes som åpnet og rettet (tid til utbedring etter type):
  • Åpnet er da funnet først ble sett på standardbranchen. Et funn som bare en pull request rapporterer, telles ikke.
  • Rettet er den første skanningen som ikke lenger rapporterer det. For et funn som skanneren markerer som løst, er det eksakt; ellers er det den daglige oppdateringen av historikken som først manglet det, så høyst én dag for sent.
  • En avvisning er ikke en rettelse. Avviste funn telles for seg, med mediantallet dager fra åpnet til avvist.
  • Et funn som kommer tilbake, starter på nytt. Det telles fra da det dukket opp igjen, ikke fra første gang.
  • IaC-funn har hatt sin egen type siden 24. oktober 2026; før det ble de telt sammen med containerimager. Historikk fra før den datoen ble flyttet til IaC der skannerens egen oppføring av funnet fortsatt finnes.
• Tid til merge er fra pull requesten ble åpnet til den ble merget, for pull requests som ble merget i perioden. Pull requests som fortsatt er åpne eller ble lukket uten merge, telles ikke.
• SLA-frister er de samme gjeldende fristene som i SLA-merkelappene og samsvarsrapporten, inkludert en lengre SLA for funn som ikke er nåbare når SLA-policyen din setter en multiplikator. Et funn bryter SLA-en når fristen passeres mens det verken er rettet eller avvist.

API

De samme tallene er tilgjengelige fra API-et med et token som har scopet findings:read:

curl -H "Authorization: Bearer $FREMFORGE_TOKEN" \
  "https://frem.sh/_app/api/v1/orgs/<org>/code-security/remediation-metrics?days=30"

days er 30 (standard) eller 90. Svaret har seksjonene over som reachability, autofix, time_to_fix, time_to_fix_by_type, time_to_merge, known_exploited og sla, pluss window og targets. Prosenter er tall fra 0 til 100 med én desimal, eller null når det ikke er noe å dele på. Se OpenAPI-spesifikasjonen for skjemaet.