En kritisk sårbarhet publiseres, varselet sprer seg, og innen en time spør noen i firmachatten: Er vi berørt? Log4Shell gjorde spørsmålet berømt. CVE-2021-44228 rammet Log4j Core fra 2.0-beta9 opp til 2.15.0, et bibliotek som lå flere lag ned i avhengighetstreet til utallige Java-produkter, og de fleste team måtte finne ut på den harde måten hvor det var.

Spørsmålet høres enkelt ut. Egentlig er det tre spørsmål:

  1. Finnes den sårbare komponenten i noe vi bygger eller leverer?
  2. Hvis ja, kan den utnyttes i produktet vårt?
  3. Siden når, og i hvilke utgivelser?

De fleste prosesser svarer på de to første. Det tredje er det kunder, revisorer og myndigheter spør om deretter, og det er det vanskeligste å svare på i ettertid.

Steg 1: Finn ut om komponenten er der

Selskaper kommer vanligvis frem til et svar på én av fire måter, omtrent i rekkefølge etter modenhet.

Spør rundt og søk. Noen skriver i Slack, utviklere søker etter pakkenavnet i repositorier og lockfiler, og et regneark samler svarene. Dette er fortsatt den vanligste metoden. Den er treg, den avhenger av hvem som svarer, og den går glipp av alt som ikke er oppgitt i en fil: avhengigheter av avhengigheter, vendorede biblioteker, base-images og verktøy som installeres under bygget.

Sjekk dashbordene til skannerne. Avhengighetsskannere flagger CVE-en per repositorium i løpet av timer. Det er raskere, men en skanner rapporterer om koden den har foran seg i dag, vanligvis standardgrenen. Den forteller deg ikke hvilke utgivelser kundene dine kjører, eller hva et bygg for tre måneder siden faktisk hentet inn.

Søk i en SBOM-oversikt. Team som har en SBOM for hver utgivelse, kan stille ett spørsmål på tvers av alle sammen: Hvilke produkter og versjoner inneholder de berørte versjonene av denne pakken? Dette er den første metoden som svarer for programvare du har levert, ikke bare programvare i repositoriet.

Match fortløpende. Når SBOM-er overvåkes mot sårbarhetsdata, finnes listen over berørte produkter før noen spør. Chattråden starter med svaret i stedet for spørsmålet.

Kvaliteten på hver metode avhenger av hva oversikten faktisk inneholder. De vanlige blindsonene er:

  • Transitive avhengigheter. Den sårbare pakken er sjelden en du har lagt til selv. Den kommer inn tre eller fire nivåer ned.
  • Alt manifestet ikke oppgir. Pakker installert av byggeskript, npx-verktøy, Dockerfile-steg, gjenopprettede cacher og vendoret C- og C++-kode.
  • Gamle utgivelser. En gren som ikke lenger lar seg bygge, kan ikke skannes på nytt, men produktet bygget fra den kan fortsatt være i bruk ute hos kundene.

Steg 2: Avgjør om det betyr noe

En komponent kan være til stede uten å være en reell risiko, så neste steg er triage:

  • Versjon og konfigurasjon. Faller versjonen nøyaktig innenfor det berørte området? Er den sårbare funksjonen kompilert inn og slått på?
  • Reachability. Kaller koden din i det hele tatt den sårbare funksjonen?
  • Eksponering. Kan komponenten nås fra nettverket eller fra upålitelige inndata, eller brukes den bare ved bygging?
  • Tiltak. Finnes det sandkassing, en nettverksbegrensning eller en konfigurasjon som blokkerer exploiten?
  • Tegn på utnyttelse. CVSS gir alvorlighetsgraden, EPSS anslår sannsynligheten for at en CVE blir utnyttet de neste 30 dagene, og CISAs Known Exploited Vulnerabilities catalog lister dem som allerede utnyttes i praksis. Sammen avgjør de hva som ses på først.

Steg 3: Registrer beslutningen

Utfallet registreres per produkt og versjon, i økende grad som en VEX-erklæring (Vulnerability Exploitability eXchange). CISAs minimum requirements for VEX definerer fire statuser: not affected, affected, fixed og under investigation. En «not affected»-erklæring må si hvorfor, for eksempel fordi den sårbare koden ikke finnes eller ikke kan nås av en angriper.

Denne registreringen er grunnlaget for alt som følger: rettingen og utgivelsene som inneholder den, sikkerhetsvarselet til kundene og enhver rapport en myndighet forventer. Etter EUs Cyber Resilience Act må for eksempel en produsent sende et tidlig varsel om en aktivt utnyttet sårbarhet i produktet sitt innen 24 timer etter å ha blitt kjent med den.

Steg 4: Finn eksponeringsvinduet

«Er vi berørt?» har en andre halvdel som ofte hoppes over: Hvor lenge var vi berørt?

Sårbarheten fantes lenge før CVE-en ble publisert. Log4Shell hadde vært i Log4j siden 2.0-beta9, utgitt år før noen avslørte den. Eksponeringen din begynte den dagen et bygg først hentet inn en sårbar versjon, og den sluttet den dagen det siste bygget som inneholdt den, ble erstattet. Du trenger dette vinduet for å:

  • fortelle kunder hvilke av utgivelsene de kjører som er berørt, ikke bare den nyeste
  • avgrense en hendelsesundersøkelse til riktig periode, hvis sårbarheten kan ha blitt utnyttet
  • vise en revisor eller en myndighet når problemet kom inn i produktet, og når rettingen ble levert

Å skanne dagens kode kan ikke gi deg det. Dagens lockfile sier hva repositoriet vil ha nå, ikke hva hvert tidligere bygg installerte. Den eneste pålitelige kilden er en registrering av hvert bygg, gjort mens det kjørte og tatt vare på etterpå.

Slik svarer CRACI

CRACI kjører GitHub Actions-jobbene dine på egne runnere og registrerer hver pakke hvert bygg faktisk henter inn, direkte og transitive, inkludert pakker installert av skript og gjenopprettet fra cacher. SBOM-en til hvert bygg tas vare på, så historikken allerede er der når en CVE publiseres.

Når en ny CVE kommer, ligger svaret allerede klart: hvert tidligere bygg og SBOM-en dets, hvilke av dem som inneholdt den sårbare avhengigheten, direkte eller transitivt, og perioden du var berørt. Ingen regneark, ingen ny skanning, ingen rekonstruksjon fra lockfiler. Det første bygget som inneholdt den, og bygget som fjernet den, gir deg eksponeringsvinduet, så langt tilbake som oppbevaringstiden din rekker (180 dager som standard, egendefinert oppbevaring på Enterprise).

Når du vet det, kan en policy gate blokkere bygg som inneholder denne CVE-en, så en senere avhengighetsoppdatering eller en gjenopprettet cache ikke i det stille kan bringe den sårbare versjonen tilbake i en utgivelse.

Derfra har resten av prosessen noe å stå på:

  • CRACI overvåker SBOM-ene fortløpende, så nye CVE-er matches mot byggene dine uten at noen spør.
  • Sikkerhetsteam triagerer funn og sender dem til teamene som eier rettingen, og CRACI støtter VEX for å registrere utfallet.
  • CRACIs inventar viser hvilke programvareversjoner som er rullet ut til hvilke produkter.
  • For CRA sender CRACI inn det tidlige varselet, varslingen og sluttrapporten på dine vegne.

Book en demo for å se byggehistorikken til et av dine egne repositorier.