En kritisk sårbarhet publiceras, säkerhetsmeddelandet sprids och inom en timme frågar någon i företagets chatt: är vi drabbade? Log4Shell gjorde frågan berömd. CVE-2021-44228 påverkade Log4j Core från 2.0-beta9 upp till 2.15.0, ett bibliotek som låg flera lager ner i beroendeträdet hos otaliga Java-produkter, och de flesta team fick lära sig den hårda vägen var det fanns.

Frågan låter enkel. Egentligen är det tre frågor:

  1. Finns den sårbara komponenten i något vi bygger eller levererar?
  2. Om den gör det, kan den utnyttjas i vår produkt?
  3. Sedan när, och i vilka releaser?

De flesta processer besvarar de två första. Den tredje är den som kunder, revisorer och tillsynsmyndigheter ställer härnäst, och den är svårast att besvara i efterhand.

Steg 1: Ta reda på om komponenten finns

Företag kommer oftast fram till ett svar på ett av fyra sätt, ungefär i mognadsordning.

Fråga runt och sök. Någon skriver på Slack, utvecklare söker efter paketnamnet i sina repon och lockfiler, och ett kalkylblad samlar svaren. Det är fortfarande den vanligaste metoden. Den är långsam, den beror på vem som svarar, och den missar allt som inte deklareras i en fil: beroenden till beroenden, vendorerade bibliotek, basavbilder och verktyg som installeras under bygget.

Kontrollera skannerpanelerna. Beroendeskannrar flaggar CVE:n per repo inom några timmar. Det går snabbare, men en skanner rapporterar om koden framför sig i dag, oftast standardgrenen. Den säger inte vilka releaser dina kunder kör, eller vad ett bygge för tre månader sedan faktiskt drog in.

Sök i en SBOM-inventering. Team som har en SBOM (software bill of materials) för varje release kan ställa en enda fråga över alla: vilka produkter och versioner innehåller de berörda versionerna av det här paketet? Det är den första metoden som ger svar för programvara du har levererat, inte bara programvara i repot.

Matcha löpande. När SBOM:er bevakas mot sårbarhetsdata finns listan över berörda produkter innan någon frågar. Chattråden börjar med svaret i stället för frågan.

Kvaliteten på varje metod beror på vad inventeringen faktiskt innehåller. De vanliga blinda fläckarna är:

  • Transitiva beroenden. Det sårbara paketet är sällan ett du själv har lagt till. Det kommer in tre eller fyra nivåer ner.
  • Allt som manifestet inte deklarerar. Paket som installeras av byggskript, npx-verktyg, Dockerfile-steg, återställda cachar och vendorerad C- och C++-kod.
  • Gamla releaser. En gren som inte längre går att bygga kan inte skannas om, men produkten som byggdes från den kan fortfarande vara ute hos användarna.

Steg 2: Avgör om det spelar någon roll

En komponent kan finnas där utan att vara en verklig risk, så nästa steg är triagering:

  • Version och konfiguration. Ligger versionen exakt inom det berörda intervallet? Är den sårbara funktionen inkompilerad och aktiverad?
  • Nåbarhet. Anropar din kod över huvud taget den sårbara funktionen?
  • Exponering. Går komponenten att nå från nätverket eller från opålitlig indata, eller används den bara vid bygget?
  • Skyddsåtgärder. Finns det sandlådor, en nätverksbegränsning eller en konfiguration som stoppar exploiten?
  • Tecken på utnyttjande. CVSS anger allvarlighetsgraden, EPSS uppskattar sannolikheten att en CVE utnyttjas inom de närmaste 30 dagarna, och CISA:s Known Exploited Vulnerabilities catalog listar dem som redan utnyttjas i verkligheten. Tillsammans avgör de vad som granskas först.

Steg 3: Registrera beslutet

Resultatet registreras per produkt och version, allt oftare som ett VEX-uttalande (Vulnerability Exploitability eXchange). CISA:s minimikrav för VEX definierar fyra statusar: not affected, affected, fixed och under investigation. Ett uttalande om not affected måste ange varför, till exempel att den sårbara koden inte finns eller inte kan nås av en angripare.

Den registreringen matar allt som följer: rättningen och de releaser som innehåller den, säkerhetsmeddelandet till kunderna och varje rapport som en tillsynsmyndighet väntar sig. Enligt EU:s Cyber Resilience Act måste en tillverkare till exempel skicka en tidig varning om en aktivt utnyttjad sårbarhet i sin produkt inom 24 timmar från att ha fått kännedom om den.

Steg 4: Räkna ut exponeringsfönstret

”Är vi drabbade?” har en andra halva som ofta hoppas över: hur länge var vi drabbade?

Sårbarheten fanns långt innan CVE:n publicerades. Log4Shell hade funnits i Log4j sedan 2.0-beta9, som släpptes flera år innan någon avslöjade den. Din exponering började den dag ett bygge först drog in en sårbar version, och den slutade den dag det sista bygget som innehöll den ersattes. Du behöver det fönstret för att:

  • berätta för kunderna vilka av de releaser de kör som är berörda, inte bara den senaste
  • avgränsa en incidentutredning till rätt period, om sårbarheten kan ha utnyttjats
  • visa en revisor eller en tillsynsmyndighet när problemet kom in i produkten och när rättningen levererades

Det kan en skanning av dagens kod inte ge dig. Den aktuella lockfilen säger vad repot vill ha nu, inte vad varje tidigare bygge installerade. Den enda tillförlitliga källan är en registrering av varje bygge, gjord medan det kördes och sparad efteråt.

Så besvarar CRACI frågan

CRACI kör dina GitHub Actions-jobb på sina egna runners och registrerar varje paket som varje bygge faktiskt drar in, direkt och transitivt, inklusive paket som installeras av skript och återställs från cachar. Varje bygges SBOM sparas, så historiken finns redan där när en CVE publiceras.

När en ny CVE kommer finns svaret redan: varje tidigare bygge och dess SBOM, vilka av dem som innehöll det sårbara beroendet, direkt eller transitivt, och perioden du var drabbad. Inget kalkylblad, ingen omskanning, ingen rekonstruktion från lockfiler. Det första bygget som innehöll det och bygget som tog bort det ger dig exponeringsfönstret, så långt tillbaka som din lagring räcker (180 dagar som standard, anpassad lagring på Enterprise).

När du vet kan en policykontroll blockera byggen som innehåller den här CVE:n, så att en senare beroendeuppdatering eller en återställd cache inte i tysthet kan föra tillbaka den sårbara versionen in i en release.

Därifrån har resten av processen något att stå på:

  • CRACI bevakar SBOM:erna löpande, så nya CVE:er matchas mot dina byggen utan att någon behöver fråga.
  • Säkerhetsteam triagerar fynd och skickar dem till teamen som äger rättningen, och CRACI stöder VEX för att registrera utfallet.
  • CRACI:s inventering visar vilka programvaruversioner som är driftsatta i vilka produkter.
  • För CRA skickar CRACI in den tidiga varningen, anmälan och slutrapporten åt dig.

Boka en demo för att se bygghistoriken för ett av dina egna repon.