Automatisert utbedring av sårbarheter, fra funn til retting

Hva automatisert utbedring av sårbarheter betyr

Utbedring av sårbarheter er å fjerne en kjent sårbarhet fra programvaren din: oppgradere den berørte pakken, bruke en patch eller erstatte komponenten. Automatisert utbedring overlater den mekaniske delen av arbeidet til programvare. Den leser et funn, finner ut hvilken versjon som retter det, endrer manifestet, lockfilen eller koden og foreslår endringen, som oftest som en pull request.

For tredjepartsavhengigheter, der de fleste kjente sårbarhetene i en moderne kodebase finnes, ser sløyfen lik ut i alle verktøy:

1. Oversikt. Vit hvilke pakker, i hvilke versjoner, som er i alt du leverer.
2. Match. Sjekk oversikten mot advisories, og fortsett å sjekke etter hvert som nye publiseres.
3. Prioriter. Bestem hva som skal rettes først, ut fra alvorlighetsgrad, utnyttelse og eksponering.
4. Rett. Velg den rettede versjonen, oppdater og tilpass koden hvis oppgraderingen ødelegger noe.
5. Verifiser. Bygg og test endringen, og bekreft deretter at den rettede versjonen er det som faktisk ble levert.
6. Registrer. Før oversikt over hva som var berørt, når det ble rettet, og i hvilken utgivelse.

Automatisering er sterkest på steg 2, 4 og 6, der arbeidet er repetitivt. Den er svakest der inndataene er feil, og inndataene til alt annet er steg 1.

Fire typer automatisert utbedring

Tilnærming	Hva den gjør	Eksempler	Hvor den stopper
Roboter for avhengighetsoppdatering	Åpner pull requests som løfter en sårbar avhengighet til en rettet versjon	Dependabot security updates, Renovate	Arbeider ut fra manifestene og lockfilene i repositoriet; en brytende oppgradering krever fortsatt at et menneske tilpasser koden
Pull requests med SCA-rettinger	Åpner pull requests med oppgraderinger for funnene et kommersielt SCA-verktøy rapporterer	Snyk, Black Duck, Aikido, Endor Labs	Dekningen varierer: Noen verktøy retter bare direkte avhengigheter, noen legger til patcher eller backporter
AI-rettinger av kode	Genererer en kodeendring for et funn, ofte et varsel fra statisk analyse	GitHub Copilot Autofix	Ikke-deterministiske forslag som må gjennomgås; se AI-basert utbedring
Automatisk utbedring av infrastruktur	Tilbakestiller en feilkonfigurasjon eller patcher en vert når en regel utløses	Verktøy for skysikkerhetstilstand og endepunkter	Dekker kjørende infrastruktur, ikke avhengighetene inne i programvaren du leverer

De tre første retter alle kode du leverer, og de deler alle én antakelse: at listen over sårbare pakker de retter, er den riktige listen.

Hver retting avhenger av oversikten

Et utbedringsverktøy kan bare rette sårbarhetene det kjenner til, og det kjenner til dem oversikten inneholder. De fleste oversikter rekonstrueres fra filer: manifester, lockfiler, installerte pakker eller et ferdig container-image. Den rekonstruksjonen går glipp av ting på forutsigbare måter.

• Pakker filene ikke deklarerer. Verktøy som bygget laster ned, base-images, plugins og alt som installeres av et skript, dukker aldri opp i en lockfile, så det blir aldri åpnet en pull request med retting for dem.
• Versjoner som avviker fra lockfilen. Bygget kan ende opp med en annen versjon enn den en skanner leser, særlig uten en lockfile som er lagt inn i repositoriet. En retting basert på feil versjon er et selvsikkert, men feil svar.
• Pakker gjenopprettet fra cacher. En cachet avhengighet berører aldri registeret igjen, så det bygget brukte, kan ligge etter det repositoriet sier.

Løsningen er å starte fra det bygget faktisk brukte. En SBOM fra bygget registreres mens bygget kjører, så den viser pakkene jobben hentet inn, inkludert transitive, og ikke det et manifest sier den burde trenge. Utbedring som starter der, retter det som leveres.

Hva du bør automatisere, og hva du bør beholde

De fleste team som får utbedring til å fungere, deler det slik:

• Automatiser funn og matching. Nye advisories publiseres hver dag. Å sjekke hvert levert bygg mot dem for hånd skalerer ikke, og det er akkurat den typen arbeid programvare gjør godt.
• Automatiser forslaget. Å velge den rettede versjonen og åpne endringen er mekanisk. Grupper relaterte oppdateringer, så de som går gjennom, ser én pull request i stedet for tjue.
• Gjør merge avhengig av tester. Automerge sikkerhetsoppdateringer på patchnivå som testene dekker. Overlat brytende oppgraderinger, og alt uten testdekning, til et menneske.
• La mennesker ta skjønnsvurderingene. Om en sårbarhet i det hele tatt berører produktet ditt, og om en risikabel oppgradering er verdt det denne uken, er beslutninger. Registrer dem, for eksempel som en VEX-erklæring, så det samme spørsmålet ikke blir stilt to ganger.

Slik vurderer du et utbedringsverktøy

Før du stoler på at et verktøy åpner pull requests i repositoriene dine, bør du spørre:

1. Hvor kommer sårbarhetslisten fra: filer i repositoriet, et skannet image eller selve bygget?
2. Retter det transitive avhengigheter, eller bare de direkte du deklarerer?
3. Hvordan velger det den rettede versjonen: den laveste patchede versjonen, den nyeste eller en versjon du fester?
4. Blir rettingen bygget og testet før du ser den, eller er pull requesten første gang den kjører?
5. Kan det gruppere og planlegge oppdateringer, så det ikke oversvømmer dem som går gjennom?
6. Registrerer det hvilke utgivelser som var berørt, og når hver retting ble levert?

Hvor CRACI passer inn i dag

CRACI kjører GitHub Actions-jobbene dine på egne runnere og registrerer pakkene hver jobb faktisk hentet, inkludert transitive avhengigheter og pakker gjenopprettet fra cacher, med en fullstendighetsstatus for hver jobb. Den registreringen er oversikten en utbedringsworkflow bør starte fra.

CRACI vurderer overvåkede SBOM-er kontinuerlig på nytt, så når en ny advisory publiseres, ser du hvilke leverte bygg den berører på tvers av repositoriene dine. Sikkerhetsteam prioriterer hvert funn og sender det til teamet som eier rettingen, og CRACI støtter VEX for å registrere hvordan en sårbarhet berører produktet ditt. SBOM-en for neste bygg viser deretter om den rettede versjonen er det bygget faktisk brukte. Siden om sporing av sårbarheter dekker hele funksjonen.

Under EUs Cyber Resilience Act må produsenter håndtere og utbedre sårbarheter uten opphold, blant annet gjennom sikkerhetsoppdateringer. En oversikt over hva hvert bygg inneholdt, og når hver retting ble levert, er dokumentasjonen den prosessen trenger.

Automatisert utbedring av sårbarheter: ofte stilte spørsmål

Hva er automatisert utbedring av sårbarheter?

Automatisert utbedring av sårbarheter er programvare som gjør et sårbarhetsfunn om til en retting uten at et menneske gjør grovarbeidet: Den finner den rettede versjonen, endrer manifestet, lockfilen eller koden og foreslår endringen, vanligvis som en pull request. Et menneske, eller en policy teamet stoler på, bestemmer fortsatt hva som merges.

Hva er forskjellen på utbedring og risikoreduksjon?

Utbedring fjerner sårbarheten, for eksempel ved å oppgradere til en rettet versjon eller bruke en patch. Risikoreduksjon senker risikoen mens sårbarheten fortsatt er der, for eksempel ved å slå av den berørte funksjonen eller blokkere angrepsveien. Risikoreduksjon kjøper tid; utbedring lukker funnet.

Kan utbedring av sårbarheter automatiseres fullt ut?

Deler av den kan det. Å finne berørte bygg, matche advisories og foreslå en versjonsoppgradering er mekanisk og lar seg godt automatisere. Å avgjøre om en brytende oppgradering er trygg, eller om en sårbarhet i det hele tatt berører produktet ditt, krever fortsatt skjønn. De fleste team automatiserer forslaget og lar et menneske, støttet av tester, stå for merge.

Gjør Dependabot automatisert utbedring av sårbarheter?

Dependabot security updates åpner pull requests som oppdaterer en sårbar avhengighet til den laveste patchede versjonen, for varslene GitHub gir på avhengighetsgrafen til repositoriet ditt. Det er automatisert utbedring for det manifestene og lockfilene deklarerer. CRACI vs Dependabot dekker hvor det deklarerte og det leverte skiller seg fra hverandre.

Hva bør jeg se etter i et verktøy for utbedring av sårbarheter?

Hvor sårbarhetslisten kommer fra, om det håndterer transitive avhengigheter, hvordan det velger versjonen med rettingen, om rettingen bygges og testes før du ser den, og om det registrerer hva som ble rettet, og når. Det siste er viktig for revisjoner og for CRA, som ber produsenter utbedre sårbarheter uten opphold.