Automatiseret afhjælpning af sårbarheder, fra fund til rettelse

Hvad automatiseret afhjælpning af sårbarheder betyder

Afhjælpning af sårbarheder er at fjerne en kendt sårbarhed fra din software: opgradere den ramte pakke, anvende en patch eller udskifte komponenten. Automatiseret afhjælpning overlader den mekaniske del af arbejdet til software. Den læser et fund, finder ud af, hvilken version der retter det, ændrer manifestet, lockfilen eller koden og foreslår ændringen, oftest som en pull request.

For tredjepartsafhængigheder, hvor de fleste kendte sårbarheder i en moderne kodebase findes, ser løkken ens ud i alle værktøjer:

1. Inventar. Vid, hvilke pakker, i hvilke versioner, der er i hver ting, du leverer.
2. Match. Tjek inventaret mod advisories, og bliv ved med at tjekke, efterhånden som nye offentliggøres.
3. Prioritér. Beslut, hvad der skal rettes først, ud fra alvorlighed, udnyttelse og eksponering.
4. Ret. Vælg den rettede version, opdatér den, og tilpas koden, hvis opgraderingen ødelægger noget.
5. Verificér. Byg og test ændringen, og bekræft derefter, at den rettede version er det, der faktisk blev leveret.
6. Registrér. Bevar et spor af, hvad der var ramt, hvornår det blev rettet, og i hvilken release.

Automatisering er stærkest ved trin 2, 4 og 6, hvor arbejdet er repetitivt. Den er svagest, hvor input er forkert, og input til alt det andet er trin 1.

Fire slags automatiseret afhjælpning

Tilgang	Hvad den gør	Eksempler	Hvor den stopper
Bots til opdatering af afhængigheder	Åbner pull requests, der løfter en sårbar afhængighed til en rettet version	Dependabot security updates, Renovate	Arbejder ud fra manifesterne og lockfilerne i repositoriet; en opgradering med breaking changes kræver stadig, at et menneske tilpasser koden
SCA-pull requests med rettelser	Åbner pull requests med opgraderinger for de fund, et kommercielt SCA-værktøj rejser	Snyk, Black Duck, Aikido, Endor Labs	Dækningen varierer: Nogle værktøjer retter kun direkte afhængigheder, andre tilføjer patches eller backports
AI-koderettelser	Genererer en kodeændring for et fund, ofte en alarm fra statisk analyse	GitHub Copilot Autofix	Ikke-deterministiske forslag, der skal gennemgås; se AI-afhjælpning
Automatisk afhjælpning af infrastruktur	Ruller en fejlkonfiguration tilbage eller patcher en host, når en regel udløses	Værktøjer til cloudsikkerhed og endpoints	Dækker kørende infrastruktur, ikke afhængighederne i den software, du leverer

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

Hver rettelse afhænger af inventaret

Et afhjælpningsværktøj kan kun rette de sårbarheder, det kender til, og det kender til dem, dets inventar indeholder. De fleste inventarer rekonstrueres ud fra filer: manifester, lockfiles, installerede pakker eller et færdigt container-image. Den rekonstruktion overser ting på forudsigelige måder.

• Pakker, filerne ikke deklarerer. Værktøjer, buildet downloader, base-images, plugins og alt, der installeres af et script, optræder aldrig i en lockfile, så der bliver aldrig åbnet en pull request med en rettelse for dem.
• Versioner, der afviger fra lockfilen. Buildet kan ende med en anden version end den, en scanner læser, især uden en committet lockfile. En rettelse baseret på den forkerte version er et selvsikkert forkert svar.
• Pakker gendannet fra caches. En cachet afhængighed rører aldrig registryet igen, så det, buildet brugte, kan halte efter det, repositoriet siger.

Løsningen er at starte fra det, buildet faktisk brugte. En build-time SBOM registreres, mens buildet kører, så den angiver de pakker, jobbet trak ind, inklusive transitive, i stedet for det, et manifest siger, det burde have brug for. Afhjælpning, der starter der, retter det, der leveres.

Hvad du skal automatisere, og hvad du skal beholde

De fleste teams, der får afhjælpning til at virke, deler det op sådan:

• Automatisér fund og matchning. Nye advisories offentliggøres hver dag. At tjekke hvert leveret build mod dem manuelt skalerer ikke, og det er præcis den slags arbejde, software er god til.
• Automatisér forslaget. At vælge den rettede version og oprette ændringen er mekanisk. Gruppér relaterede opdateringer, så reviewere ser én pull request i stedet for tyve.
• Gør merge betinget af test. Automerge sikkerhedsopdateringer på patch-niveau, som testsuiten dækker. Overlad opgraderinger med breaking changes og alt uden testdækning til et menneske.
• Behold vurderingerne hos mennesker. Om en sårbarhed overhovedet rammer dit produkt, og om en risikabel opgradering er det værd i denne uge, er beslutninger. Registrér dem, for eksempel som en VEX-erklæring, så det samme spørgsmål ikke bliver stillet to gange.

Sådan evaluerer du et afhjælpningsværktøj

Før du stoler på, at et værktøj åbner pull requests på dine repositories, bør du spørge:

1. Hvor kommer dets liste over sårbarheder fra: filer i repositoriet, et scannet image eller selve buildet?
2. Retter det transitive afhængigheder, eller kun de direkte, du deklarerer?
3. Hvordan vælger det den rettede version: den laveste patchede version, den nyeste eller en version, du fastlåser?
4. Bliver rettelsen bygget og testet, før du ser den, eller er pull requesten første gang, den kører?
5. Kan det gruppere opdateringer og planlægge dem, så det ikke oversvømmer reviewere?
6. Registrerer det, hvilke releases der var ramt, og hvornår hver rettelse blev leveret?

Hvor CRACI passer ind i dag

CRACI kører dine GitHub Actions-jobs på sine egne runnere og registrerer de pakker, hvert job faktisk hentede, inklusive transitive afhængigheder og pakker gendannet fra caches, med en fuldstændighedsstatus for hvert job. Den registrering er det inventar, et afhjælpningsworkflow bør starte fra.

CRACI genvurderer løbende overvågede SBOM'er, så når en ny advisory offentliggøres, ser du, hvilke leverede builds den rammer på tværs af dine repositories. Sikkerhedsteams triagerer hvert fund og sender det til det team, der ejer rettelsen, og CRACI understøtter VEX til at registrere, hvordan en sårbarhed påvirker dit produkt. SBOM'en for det næste build viser derefter, om den rettede version er det, buildet reelt brugte. Siden om sårbarhedssporing dækker den fulde funktionalitet.

Under EU's Cyber Resilience Act skal producenter håndtere og afhjælpe sårbarheder uden forsinkelse, herunder gennem sikkerhedsopdateringer. En registrering af, hvad hvert build indeholdt, og hvornår hver rettelse blev leveret, er den dokumentation, den proces har brug for.

Automatiseret afhjælpning af sårbarheder: ofte stillede spørgsmål

Hvad er automatiseret afhjælpning af sårbarheder?

Automatiseret afhjælpning af sårbarheder er software, der gør et sårbarhedsfund til en rettelse, uden at et menneske skal gøre benarbejdet: Den finder den rettede version, ændrer manifestet, lockfilen eller koden og foreslår ændringen, som regel som en pull request. Et menneske, eller en politik teamet stoler på, beslutter stadig, hvad der bliver merget.

Hvad er forskellen på afhjælpning og afbødning af sårbarheder?

Afhjælpning fjerner sårbarheden, for eksempel ved at opgradere til en rettet version eller anvende en patch. Afbødning reducerer risikoen, mens sårbarheden stadig er der, for eksempel ved at deaktivere den ramte funktion eller blokere angrebsvejen. Afbødning køber tid; afhjælpning lukker fundet.

Kan afhjælpning af sårbarheder automatiseres fuldt ud?

Det kan dele af den. At finde ramte builds, matche advisories og foreslå en versionsopgradering er mekanisk og egner sig godt til automatisering. At afgøre, om en opgradering med breaking changes er sikker, eller om en sårbarhed overhovedet rammer dit produkt, kræver stadig vurdering. De fleste teams automatiserer forslaget og beholder et menneske, understøttet af test, ved merge.

Udfører Dependabot automatiseret afhjælpning af sårbarheder?

Dependabot security updates åbner pull requests, der opdaterer en sårbar afhængighed til den laveste patchede version, for de alarmer, GitHub rejser på dit repositorys afhængighedsgraf. Det er automatiseret afhjælpning af det, manifesterne og lockfilerne deklarerer. CRACI vs. Dependabot gennemgår, hvor det deklarerede og det leverede adskiller sig.

Hvad skal jeg kigge efter i et værktøj til afhjælpning af sårbarheder?

Hvor dets liste over sårbarheder kommer fra, om det håndterer transitive afhængigheder, hvordan det vælger den rettede version, om rettelsen bygges og testes, før du ser den, og om det registrerer, hvad der blev rettet og hvornår. Det sidste er vigtigt for revisioner og for CRA, som kræver, at producenter afhjælper sårbarheder uden forsinkelse.