CRACI for PSIRT-team og produktsikkerhetsledere

Problemet en PSIRT-leder har

En produktsikkerhetssjef står ansvarlig for svar PSIRT-et ikke kan produsere alene. Når en CVE dukker opp i et mye brukt bibliotek, stiller kunder, ledere og i økende grad myndigheter de samme spørsmålene i løpet av timer: Er vi berørt, i hvilke produkter og versjoner, siden når, og når blir det rettet?

Svarene avhenger av inventaret, og inventaret kommer vanligvis fra skannere som leser lockfiler eller manifester i etterkant. De lister utviklingsavhengigheter som aldri leveres, og overser pakker bygget lastet ned på annen måte. Så PSIRT-et ber utviklingsteamene sjekke for hånd, og svaret kommer etter flere dager, med forbehold.

FIRST PSIRT Services Framework kaller et inventar over produktkomponenter avgjørende for raskt å kunne identifisere berørte produkter ved nedarvede sårbarheter. Det inventaret er der CRACI begynner. Hele bildet av rollen finner du i hva er et PSIRT.

Dette gir CRACI et PSIRT

Et inventar registrert fra bygget

CRACI kjører GitHub Actions-byggene dine på sine egne runnere og registrerer pakkene hver jobb faktisk hentet, inkludert transitive avhengigheter, pakker gjenopprettet fra CI-cacher og avhengigheter ingen lockfile viser. CRACI er en opptaker, ikke en skanner. Hver SBOM har en fullstendighetsstatus, så en delvis registrering merkes som delvis, og SBOM-er eksporteres som CycloneDX eller SPDX.

Kontinuerlig overvåking av det som er levert

Overvåkede SBOM-er vurderes kontinuerlig på nytt etter hvert som nye sårbarheter publiseres, og funn samles på tvers av bygg og repositorier. En CVE som publiseres neste måned, matches mot utgivelsene du allerede har levert, ikke bare det neste bygget. Kjente ondsinnede utgivelser med en publisert CVE flagges som enhver annen sårbarhet.

Berørte produkter, versjoner og perioder

Byggehistorikken viser hvert tidligere bygg med SBOM-en det har, og hvilke bygg som inneholdt en sårbar avhengighet, direkte eller transitiv, så du vet i hvilken periode du var berørt, innenfor oppbevaringstiden din. Inventarvisningen viser nøyaktig hvilke programvareversjoner som er rullet ut til hvilke produkter. Sammen gjør de «er vi berørt?» til et oppslag.

Innkjøpte komponenter

Produkter består sjelden bare av din egen kode. SBOM-er fra leverandører kan legges til, så tredjepartskomponenter overvåkes sammen med dine egne bygg.

Prioritering, ruting og VEX

Sikkerhetsteam prioriterer oppdagede sårbarheter og sender dem til teamene som eier rettingen, noe som passer den distribuerte PSIRT-modellen der produktteam står for rettingen. CRACI støtter VEX. Se VEX for hvordan erklæringer om ikke berørt sparer et PSIRT og kundene for arbeid.

Slik holder du en rettet CVE ute av senere bygg

Policy gates kan blokkere et bygg på grunn av funn, inkludert bygg som inneholder en bestemt CVE. Etter at en PSIRT-sak er lukket, stopper en gate på den CVE-en den sårbare versjonen fra å snike seg tilbake i en senere utgivelse.

Bevis for revisjoner og kunder

API-et returnerer SBOM-er, nettverksspor og provenance for hvert bygg, så dokumentasjonen bak en advisory eller et revisjonssvar er tilgjengelig utenfor brukergrensesnittet. Der EUs Cyber Resilience Act gjelder, sender CRACI også inn de påkrevde varslene til myndighetene på vegne av produsenten; plikten forblir hos produsenten. Se hva er CRA.

Hvor CRACI passer inn i PSIRT-prosessen

PSIRT-stadium	Dette bidrar CRACI med
Forberedelse	En SBOM per bygg, registrert mens det kjører, med en fullstendighetsstatus
Oppdagelse	Kontinuerlig ny vurdering av overvåkede SBOM-er, inkludert SBOM-er fra leverandører
Verifisering	Hvilke bygg, versjoner og produkter som inneholder komponenten, og siden når
Retting	Prioritering til det ansvarlige teamet; policy gates som holder CVE-en ute av senere bygg
Utgivelse og offentliggjøring	VEX-støtte; SBOM-eksport; API-tilgang til byggeregistreringen

Stadiene følger livssyklusen for sårbarhetshåndtering.

Dette gjør ikke CRACI

• Reachability-analyse. CRACI viser at en sårbar pakke var i bygget, ikke om koden din kaller den sårbare funksjonen.
• Skanning av kildekode. SAST og skanning etter hemmeligheter er utenfor omfanget; det finnes mange gode verktøy som gjør det ved siden av CRACI.
• Andre CI-systemer enn GitHub Actions. GitHub Actions i dag; andre CI-systemer står på veikartet.
• Samsvar på dine vegne. CRACI leverer bevisene; å oppfylle NIS2, CRA eller et annet rammeverk forblir organisasjonens egen prosess.

CRACI for PSIRT-team: ofte stilte spørsmål

Er CRACI et PSIRT-verktøy?

CRACI dekker den delen av PSIRT-arbeidet som avhenger av å vite hva du leverer: SBOM-er fra bygget, kontinuerlig overvåking av dem, hvilke bygg og produkter som inneholder en sårbar komponent, og prioritering til det ansvarlige teamet. Kanalen din for offentliggjøring og advisory-prosessen bygger på denne registreringen.

Hvordan vet CRACI hva som er i et produkt?

Bygg kjører på CRACIs GitHub Actions-runnere, og CRACI registrerer pakkene hver jobb faktisk hentet, inkludert transitive avhengigheter, pakker gjenopprettet fra CI-cacher og avhengigheter ingen lockfile viser. CRACI er en opptaker, ikke en skanner. Hver SBOM har en fullstendighetsstatus, så du vet når registreringen er delvis.

Kan CRACI fortelle oss hvilke tidligere utgivelser som ble berørt av en CVE?

Ja, innenfor oppbevaringstiden din. Byggehistorikken viser hvert tidligere bygg og SBOM-en det har, og hvilke bygg som inneholdt en sårbar avhengighet, direkte eller transitiv, så du vet i hvilken periode du var berørt. Inventarvisningen viser hvilke programvareversjoner som er rullet ut til hvilke produkter.

Dekker CRACI komponenter vi kjøper fra leverandører?

Du kan legge til SBOM-er fra leverandører, så innkjøpte komponenter overvåkes sammen med dine egne bygg.

Støtter CRACI VEX?

Ja. CRACI støtter VEX for å registrere hvordan en kjent sårbarhet berører produktet ditt. Se VEX for statusene og formatene, og CSAF for hvordan advisories formidler dem.

Hvilke CI-systemer støtter CRACI?

GitHub Actions i dag. Andre CI-systemer står på veikartet.