CRACI til PSIRT-teams og produktsikkerhedsledere

Problemet, en PSIRT-chef har

En produktsikkerhedsleder står til ansvar for svar, som PSIRT'et ikke selv producerer. Når en CVE lander i et udbredt bibliotek, stiller kunder, ledere og i stigende grad myndigheder de samme spørgsmål inden for få timer: Er vi ramt, i hvilke produkter og versioner, siden hvornår, og hvornår bliver det rettet?

Svarene afhænger af inventaret, og inventaret kommer som regel fra scannere, der læser lockfiles eller manifester bagefter. De angiver udviklingsafhængigheder, der aldrig leveres, og overser pakker, buildet downloadede på en anden måde. Så beder PSIRT'et engineering-teams om at tjekke manuelt, og svaret kommer efter flere dage, med forbehold.

FIRST PSIRT Services Framework kalder et inventar over produktkomponenter "essential to quickly identify affected products for inherited vulnerabilities". Det er i det inventar, CRACI starter. Det fulde billede af rollen finder du i hvad er et PSIRT.

Hvad CRACI giver et PSIRT

Et inventar registreret fra buildet

CRACI kører dine GitHub Actions-builds på sine egne runnere og registrerer de pakker, hvert job faktisk hentede, inklusive transitive afhængigheder, pakker gendannet fra CI-caches og afhængigheder, som ingen lockfile angiver. Det er en registrator, ikke en scanner. Hver SBOM har en fuldstændighedsstatus, så en delvis registrering er markeret som delvis, og SBOM'er eksporteres som CycloneDX eller SPDX.

Løbende overvågning af det leverede

Overvågede SBOM'er genvurderes løbende, efterhånden som nye sårbarheder offentliggøres, og fund samles på tværs af builds og repositories. En CVE, der offentliggøres næste måned, matches mod de releases, du allerede har leveret, ikke kun det næste build. Kendte ondsindede releases med en offentliggjort CVE markeres som enhver anden sårbarhed.

Ramte produkter, versioner og perioder

Build-historikken viser hvert tidligere build med dets SBOM, og hvilke builds der indeholdt en sårbar afhængighed, direkte eller transitiv, så du kender den periode, du var ramt i, inden for din opbevaringsperiode. Inventaroversigten viser præcis, hvilke softwareversioner der er udrullet til hvilke produkter. Tilsammen gør de "er vi ramt?" til et opslag.

Indkøbte komponenter

Produkter består sjældent kun af din egen kode. Leverandørers SBOM'er kan tilføjes, så tredjepartskomponenter overvåges sammen med dine egne builds.

Triage, videresendelse og VEX

Sikkerhedsteams triagerer opdagede sårbarheder og sender dem til de teams, der ejer rettelsen, hvilket passer til den distribuerede PSIRT-model, hvor produktteams står for afhjælpningen. CRACI understøtter VEX. Se VEX for, hvordan erklæringer om "ikke ramt" sparer et PSIRT og dets kunder for arbejde.

Hold en rettet CVE ude af senere builds

Policy gates kan blokere et build på baggrund af fund, herunder builds, der indeholder en bestemt CVE. Når en PSIRT-sag er lukket, forhindrer en gate på den CVE, at den sårbare version i det stille vender tilbage i en senere release.

Dokumentation til audits og kunder

API'et returnerer SBOM'er, netværkstraces og provenance for hvert build, så registreringen bag en advisory eller et audit-svar er tilgængelig uden for brugerfladen. Hvor EU's Cyber Resilience Act gælder, indsender CRACI også de krævede underretninger til myndighederne på producentens vegne; forpligtelsen forbliver hos producenten. Se hvad er CRA.

Hvor CRACI passer ind i PSIRT-processen

PSIRT-fase	Hvad CRACI bidrager med
Forberedelse	En SBOM pr. build, registreret mens det kører, med en fuldstændighedsstatus
Opdagelse	Løbende genvurdering af overvågede SBOM'er, inklusive leverandørers SBOM'er
Verifikation	Hvilke builds, versioner og produkter der indeholder komponenten, og siden hvornår
Afhjælpning	Triage til det ansvarlige team; policy gates, der holder CVE'en ude af senere builds
Release og offentliggørelse	VEX-understøttelse; SBOM-eksport; API-adgang til build-registreringen

Faserne følger livscyklussen for sårbarhedsstyring.

Det, CRACI ikke gør

• Reachability-analyse. CRACI viser, at en sårbar pakke var i buildet, ikke om din kode kalder den sårbare funktion.
• Scanning af kildekode. SAST og secrets-scanning er uden for scope; der findes mange gode værktøjer, der gør det ved siden af CRACI.
• Andre CI-systemer end GitHub Actions. GitHub Actions i dag; andre CI-systemer er på roadmappen.
• Compliance på dine vegne. CRACI leverer dokumentationen; at opfylde NIS2, CRA eller et andet rammeværk forbliver din organisations proces.

CRACI til PSIRT-teams: ofte stillede spørgsmål

Er CRACI et PSIRT-værktøj?

CRACI dækker den del af PSIRT-arbejdet, der afhænger af at vide, hvad du leverer: SBOM'er fra buildet, løbende overvågning af dem, hvilke builds og produkter der indeholder en sårbar komponent, og triage til det ansvarlige team. Din offentliggørelseskanal og din advisory-proces bygger på den registrering.

Hvordan ved CRACI, hvad der er i et produkt?

Builds kører på CRACI's GitHub Actions-runnere, og CRACI registrerer de pakker, hvert job faktisk hentede, inklusive transitive afhængigheder, pakker gendannet fra CI-caches og afhængigheder, som ingen lockfile angiver. Det er en registrator, ikke en scanner. Hver SBOM har en fuldstændighedsstatus, så du ved, hvornår registreringen er delvis.

Kan CRACI fortælle os, hvilke tidligere releases der var ramt af en CVE?

Ja, inden for din opbevaringsperiode. Build-historikken viser hvert tidligere build og dets SBOM, og hvilke builds der indeholdt en sårbar afhængighed, direkte eller transitiv, så du kender den periode, du var ramt i. Inventaroversigten viser, hvilke softwareversioner der er udrullet til hvilke produkter.

Dækker CRACI komponenter, vi køber af leverandører?

Du kan tilføje leverandørers SBOM'er, så indkøbte komponenter overvåges sammen med dine egne builds.

Understøtter CRACI VEX?

Ja. CRACI understøtter VEX til at registrere, hvordan en kendt sårbarhed påvirker dit produkt. Se VEX for statusser og formater og CSAF for, hvordan advisories indeholder dem.

Hvilke CI-systemer understøtter CRACI?

GitHub Actions i dag. Andre CI-systemer er på roadmappen.