Udbedringsmålinger

Udbedringsmålinger viser, om funktionerne til triage og rettelse gør deres arbejde for din organisation. Siden måler succeskriterierne for nåbarhed og sikkerhedsrettelser på dine egne fund over de seneste 30 eller 90 dage og sammenligner hver periode med det samme antal dage lige før den.

Du finder den under Sikkerhed › Rapporter › Udbedringsmålinger (/<org>/_admin/security/reports/remediation). Organisationens ejere og medlemmer af organisationens Auditors-team kan åbne den. Vælg Seneste 30 dage eller Seneste 90 dage øverst på siden.

Hvert tal handler kun om din organisation. Intet sammenlignes med eller beregnes ud fra andre organisationer.

Samme side har kortet Bidrag med anonyme tal: et tilvalg, slået fra som standard, der anonymt lægger din organisations tal til de tal, fremforge offentliggør. Se Anonyme tal.

Hvad den viser

Sådan laves tallene

• Unikke fund. Et afhængighedsfund er ét pr. repository, pakke og advisory, uanset hvor mange branches eller pull requests der rapporterer det. De åbne afhængighedsfund tælles på samme måde på hver dag i udviklingen.
• Det daglige øjebliksbillede tages én gang i døgnet kun for din organisation, ud fra samme optælling som dækningstallene ovenfor, og kombineres aldrig med andre organisationers data. Det gemmes lige så længe som din indstilling for historik over fund, når du har sat en, ellers i 18 måneder, og slettes, når din organisation slettes. Et legal hold bevarer det.
• Vurderinger er ikke afvisninger. Et fund, der ikke er nåbart, forbliver åbent og tælles som åbent overalt. Se nåbarhed.
• Pull requests med sikkerhedsrettelser tælles efter den dato, rettelsen blev anmodet om. En pull request, der stadig venter på gennemgang, sænker mergeraten, indtil den merges eller lukkes.
• Tid til rettelse og SLA-overskridelser kommer fra historikken over fund, som begynder, da sporingen af din organisations historik startede (siden angiver datoen). Et fund, der allerede var åbent på den dato, tælles fra det tidspunkt, det først blev gemt.
• Hvad der tæller som åbnet og rettet (tid til rettelse efter type):
  • Åbnet er, når fundet først blev set på standardbranchen. Et fund, som kun en pull request rapporterer, tælles ikke.
  • Rettet er den første scanning, der ikke længere rapporterer det. For et fund, hvis scanner markerer det som løst, er det præcist; ellers er det den daglige opdatering af historikken, der først manglede det, så højst et døgn for sent.
  • En afvisning er ikke en rettelse. Afviste fund tælles for sig, med mediandagene fra åbnet til afvist.
  • Et fund, der kommer tilbage, starter forfra. Det tælles fra, da det dukkede op igen, ikke fra første gang det viste sig.
  • IaC-fund har haft deres egen type siden 24. oktober 2026; før det blev de talt med container-images. Historik fra før den dato blev flyttet til IaC, hvor scannerens egen registrering af fundet stadig findes.
• Tid til merge er fra pull requesten blev åbnet, til den blev merget, for pull requests merget i perioden. Pull requests, der stadig er åbne eller er lukket uden merge, tælles ikke.
• SLA-frister er de samme gældende frister som i SLA-mærkerne og i compliancerapporten, inklusive en længere SLA for fund, der ikke er nåbare, når din SLA-politik sætter en multiplikator. Et fund overskrider sin SLA, når fristen udløber, mens det hverken er rettet eller afvist.

API

De samme tal kan hentes fra API’et med et token, der 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 afsnittene ovenfor som reachability, autofix, time_to_fix, time_to_fix_by_type, time_to_merge, known_exploited og sla plus window og targets. Procenter er tal fra 0 til 100 med én decimal, eller null, når der ikke er noget at dividere med. Se OpenAPI-specifikationen for skemaet.