Automatiserad åtgärd av sårbarheter, från fynd till rättning

Vad automatiserad åtgärd av sårbarheter innebär

Att åtgärda en sårbarhet innebär att ta bort en känd sårbarhet från din programvara: uppgradera det berörda paketet, installera en patch eller ersätta komponenten. Automatiserad åtgärd lämnar över den mekaniska delen av arbetet till programvara. Den läser ett fynd, tar reda på vilken version som åtgärdar det, ändrar manifestet, lockfilen eller koden och föreslår ändringen, oftast som en pull request.

För tredjepartsberoenden, där de flesta kända sårbarheterna i en modern kodbas finns, ser loopen likadan ut i alla verktyg:

1. Inventera. Ha koll på vilka paket, i vilka versioner, som finns i allt du levererar.
2. Matcha. Kontrollera inventeringen mot säkerhetsmeddelanden, och fortsätt kontrollera när nya publiceras.
3. Prioritera. Bestäm vad som ska åtgärdas först, utifrån allvarlighetsgrad, utnyttjande och exponering.
4. Åtgärda. Välj den åtgärdade versionen, uppdatera och anpassa koden om uppgraderingen förstör något.
5. Verifiera. Bygg och testa ändringen, och bekräfta sedan att den åtgärdade versionen är den som faktiskt levererades.
6. Dokumentera. Spara en historik över vad som berördes, när det åtgärdades och i vilken release.

Automatisering är starkast i steg 2, 4 och 6, där arbetet är repetitivt. Den är svagast där indata är fel, och indata till allt annat är steg 1.

Fyra sorters automatiserad åtgärd

Metod	Vad den gör	Exempel	Var gränsen går
Bottar för beroendeuppdateringar	Öppnar pull requests som höjer ett sårbart beroende till en åtgärdad version	Dependabot security updates, Renovate	Utgår från manifest och lockfiler i repot; en inkompatibel uppgradering kräver fortfarande att en människa anpassar koden
Pull requests med rättningar från SCA	Öppnar pull requests med uppgraderingar för de fynd som ett kommersiellt SCA-verktyg tar upp	Snyk, Black Duck, Aikido, Endor Labs	Täckningen varierar: vissa verktyg åtgärdar bara direkta beroenden, vissa lägger till patchar eller bakåtporteringar
Kodrättningar med AI	Genererar en kodändring för ett fynd, ofta ett larm från statisk analys	GitHub Copilot Autofix	Icke-deterministiska förslag som behöver granskas; se AI-baserad åtgärd
Automatisk åtgärd av infrastruktur	Återställer en felkonfiguration eller patchar en värd när en regel utlöses	Verktyg för molnsäkerhetsstatus och slutpunkter	Täcker infrastruktur i drift, inte beroendena i programvaran du levererar

De tre första åtgärdar alla kod du levererar, och de har alla ett antagande gemensamt: att listan över sårbara paket de åtgärdar är rätt lista.

Varje rättning hänger på inventeringen

Ett åtgärdsverktyg kan bara åtgärda de sårbarheter det känner till, och det känner till dem som finns i dess inventering. De flesta inventeringar rekonstrueras från filer: manifest, lockfiler, installerade paket eller en färdig containeravbild. Den rekonstruktionen missar saker på förutsägbara sätt.

• Paket som filerna inte deklarerar. Verktyg som bygget laddar ned, basavbilder, insticksprogram och allt som installeras av ett skript dyker aldrig upp i en lockfile, så ingen pull request med en rättning öppnas någonsin för dem.
• Versioner som skiljer sig från lockfilen. Bygget kan hamna på en annan version än den som en skanner läser, särskilt utan en incheckad lockfile. En rättning som utgår från fel version är ett tvärsäkert men felaktigt svar.
• Paket som återställs från cachar. Ett cachat beroende hämtas aldrig igen från registret, så det som bygget använde kan ligga efter det som repot säger.

Lösningen är att utgå från vad bygget faktiskt använde. En SBOM från bygget registreras medan bygget körs, så den listar paketen som jobbet drog in, inklusive transitiva, och inte vad ett manifest säger att det borde behöva. Åtgärd som utgår därifrån åtgärdar det som levereras.

Vad du ska automatisera och vad du ska behålla

De flesta team som får åtgärdsarbetet att fungera delar upp det så här:

• Automatisera hittandet och matchningen. Nya säkerhetsmeddelanden publiceras varje dag. Att kontrollera varje levererat bygge mot dem för hand skalar inte, och det är precis den sortens arbete som programvara gör bra.
• Automatisera förslaget. Att välja den åtgärdade versionen och öppna ändringen är mekaniskt. Gruppera relaterade uppdateringar så att granskarna ser en pull request i stället för tjugo.
• Låt tester styra sammanslagningen. Slå automatiskt samman säkerhetsuppdateringar på patchnivå som testsviten täcker. Spara inkompatibla uppgraderingar, och allt utan testtäckning, åt en människa.
• Låt bedömningarna vara mänskliga. Om en sårbarhet över huvud taget påverkar din produkt, och om en riskfylld uppgradering är värd det den här veckan, är beslut. Dokumentera dem, till exempel som ett VEX-uttalande, så att samma fråga inte ställs två gånger.

Så utvärderar du ett åtgärdsverktyg

Innan du litar på att ett verktyg öppnar pull requests i dina repon, fråga:

1. Var kommer listan över sårbarheter ifrån: filer i repot, en skannad avbild eller själva bygget?
2. Åtgärdar det transitiva beroenden, eller bara de direkta som du deklarerar?
3. Hur väljer det den åtgärdade versionen: den lägsta patchade versionen, den senaste eller en version du låser?
4. Byggs och testas rättningen innan du ser den, eller är pull requesten första gången den körs?
5. Kan det gruppera uppdateringar och schemalägga dem, så att det inte dränker granskarna?
6. Dokumenterar det vilka releaser som berördes och när varje rättning levererades?

Var CRACI passar in i dag

CRACI kör dina GitHub Actions-jobb på egna runners och registrerar paketen som varje jobb faktiskt hämtade, inklusive transitiva beroenden och paket som återställs från cachar, med en fullständighetsstatus för varje jobb. Den registreringen är inventeringen som ett arbetsflöde för åtgärder bör utgå från.

CRACI omvärderar bevakade SBOM:er löpande, så när ett nytt säkerhetsmeddelande publiceras ser du vilka levererade byggen det påverkar i dina repon. Säkerhetsteam triagerar varje fynd och skickar det till teamet som äger åtgärden, och CRACI har stöd för VEX för att dokumentera hur en sårbarhet påverkar din produkt. Nästa bygges SBOM visar sedan om den åtgärdade versionen är den som bygget verkligen använde. Sidan om sårbarhetsuppföljning täcker hela funktionen.

Enligt EU:s Cyber Resilience Act måste tillverkare hantera och åtgärda sårbarheter utan dröjsmål, bland annat genom säkerhetsuppdateringar. En registrering av vad varje bygge innehöll och när varje rättning levererades är underlaget den processen behöver.

Automatiserad åtgärd av sårbarheter: vanliga frågor

Vad är automatiserad åtgärd av sårbarheter?

Automatiserad åtgärd av sårbarheter är programvara som gör ett sårbarhetsfynd till en rättning utan att en människa gör grovjobbet: den tar reda på den åtgärdade versionen, ändrar manifestet, lockfilen eller koden och föreslår ändringen, oftast som en pull request. En människa, eller en policy som teamet litar på, bestämmer fortfarande vad som slås samman.

Vad är skillnaden mellan att åtgärda och att begränsa en sårbarhet?

Att åtgärda tar bort sårbarheten, till exempel genom att uppgradera till en åtgärdad version eller installera en patch. Att begränsa minskar risken medan sårbarheten finns kvar, till exempel genom att stänga av den berörda funktionen eller blockera angreppsvägen. Begränsning köper tid; åtgärd stänger fyndet.

Kan åtgärd av sårbarheter automatiseras helt?

Delvis. Att hitta berörda byggen, matcha säkerhetsmeddelanden och föreslå en versionshöjning är mekaniskt och går bra att automatisera. Att avgöra om en inkompatibel uppgradering är säker, eller om en sårbarhet över huvud taget påverkar din produkt, kräver fortfarande omdöme. De flesta team automatiserar förslaget och behåller en människa, med stöd av tester, vid sammanslagningen.

Gör Dependabot automatiserad åtgärd av sårbarheter?

Dependabot security updates öppnar pull requests som uppdaterar ett sårbart beroende till den lägsta patchade versionen, för larmen som GitHub tar upp utifrån ditt repos beroendegraf. Det är automatiserad åtgärd för det som manifest och lockfiler deklarerar. CRACI vs Dependabot tar upp var det deklarerade och det levererade skiljer sig åt.

Vad ska jag leta efter i ett verktyg för åtgärd av sårbarheter?

Var listan över sårbarheter kommer ifrån, om det hanterar transitiva beroenden, hur det väljer version för rättningen, om rättningen byggs och testas innan du ser den och om det dokumenterar vad som åtgärdades och när. Det sista spelar roll vid revisioner och för CRA, som kräver att tillverkare åtgärdar sårbarheter utan dröjsmål.