Geautomatiseerd herstel van kwetsbaarheden, van bevinding tot fix

Wat geautomatiseerd herstel van kwetsbaarheden betekent

Kwetsbaarheidsherstel is het verwijderen van een bekende kwetsbaarheid uit uw software: het getroffen pakket upgraden, een patch toepassen of de component vervangen. Geautomatiseerd herstel draagt het mechanische deel van dat werk over aan software. Die leest een bevinding, bepaalt welke versie het probleem oplost, wijzigt het manifest, de lockfile of de code, en stelt de wijziging voor, meestal als pull request.

Voor afhankelijkheden van derden, waar de meeste bekende kwetsbaarheden in een moderne codebase zitten, ziet de cyclus er in elke tool hetzelfde uit:

1. Inventariseren. Weet welke pakketten, in welke versies, in elk product zitten dat u levert.
2. Matchen. Vergelijk die inventaris met advisories, en blijf dat doen zodra er nieuwe verschijnen.
3. Prioriteren. Bepaal wat u het eerst repareert, op basis van ernst, misbruik en blootstelling.
4. Repareren. Kies de gerepareerde versie, werk bij en pas de code aan als de upgrade iets breekt.
5. Verifiëren. Bouw en test de wijziging, en bevestig daarna dat echt de gerepareerde versie is geleverd.
6. Vastleggen. Bewaar een spoor van wat was getroffen, wanneer het is gerepareerd en in welke release.

Automatisering is het sterkst bij stap 2, 4 en 6, waar het werk repetitief is. Ze is het zwakst waar de invoer niet klopt, en de invoer voor al het andere is stap 1.

Vier soorten geautomatiseerd herstel

Aanpak	Wat het doet	Voorbeelden	Waar het stopt
Bots voor het bijwerken van afhankelijkheden	Openen pull requests die een kwetsbare afhankelijkheid naar een gerepareerde versie verhogen	Dependabot security updates, Renovate	Werkt op basis van de manifests en lockfiles in de repository; bij een breaking upgrade moet nog steeds iemand de code aanpassen
Fix-pull-requests van SCA-tools	Openen upgrade-pull-requests voor de bevindingen van een commerciële SCA-tool	Snyk, Black Duck, Aikido, Endor Labs	De dekking verschilt: sommige tools repareren alleen directe afhankelijkheden, andere voegen patches of backports toe
AI-codefixes	Genereren een codewijziging voor een bevinding, vaak een melding uit statische analyse	GitHub Copilot Autofix	Niet-deterministische suggesties die een review nodig hebben; zie AI-herstel
Automatisch herstel van infrastructuur	Draait een misconfiguratie terug of patcht een host wanneer een regel wordt geactiveerd	Tools voor cloud security posture en endpoints	Dekt draaiende infrastructuur, niet de afhankelijkheden in de software die u levert

De eerste drie repareren allemaal code die u levert, en ze delen één aanname: dat de lijst met kwetsbare pakketten die ze repareren de juiste lijst is.

Elke fix hangt af van de inventaris

Een hersteltool kan alleen de kwetsbaarheden repareren die hij kent, en hij kent de kwetsbaarheden die in zijn inventaris zitten. De meeste inventarissen worden gereconstrueerd uit bestanden: manifests, lockfiles, geïnstalleerde pakketten of een afgewerkte containerimage. Die reconstructie mist dingen op voorspelbare manieren.

• Pakketten die de bestanden niet declareren. Tools die de build downloadt, base images, plug-ins en alles wat een script installeert, verschijnen nooit in een lockfile, dus er wordt nooit een fix-pull-request voor geopend.
• Versies die afwijken van de lockfile. De build kan op een andere versie uitkomen dan een scanner leest, vooral zonder gecommitte lockfile. Een fix die op de verkeerde versie is gebaseerd, is een zelfverzekerd fout antwoord.
• Pakketten die uit caches zijn teruggezet. Een gecachete afhankelijkheid komt nooit meer bij de registry, dus wat de build gebruikte, kan achterlopen op wat de repository zegt.

De oplossing is te beginnen bij wat de build echt heeft gebruikt. Een build-time SBOM wordt vastgelegd terwijl de build draait, dus hij toont de pakketten die de job heeft binnengehaald, inclusief transitieve, en niet wat volgens een manifest nodig zou moeten zijn. Herstel dat daar begint, repareert wat wordt geleverd.

Wat u automatiseert en wat u zelf doet

De meeste teams bij wie herstel werkt, verdelen het zo:

• Automatiseer het vinden en matchen. Er verschijnen elke dag nieuwe advisories. Elke geleverde build daar handmatig opnieuw aan toetsen schaalt niet, en het is precies het soort werk waar software goed in is.
• Automatiseer het voorstel. De gerepareerde versie kiezen en de wijziging openen is mechanisch. Groepeer verwante updates, zodat reviewers één pull request zien in plaats van twintig.
• Maak de merge afhankelijk van tests. Laat beveiligingsupdates op patchniveau die de testsuite dekt automatisch mergen. Laat breaking upgrades, en alles zonder testdekking, aan een mens over.
• Houd afwegingen bij mensen. Of een kwetsbaarheid uw product überhaupt raakt, en of een riskante upgrade deze week de moeite waard is, zijn beslissingen. Leg ze vast, bijvoorbeeld als VEX-verklaring, zodat dezelfde vraag niet twee keer wordt gesteld.

Hoe u een hersteltool beoordeelt

Voordat u een tool vertrouwt om pull requests op uw repositories te openen, stelt u deze vragen:

1. Waar komt de kwetsbaarheidslijst vandaan: uit bestanden in de repository, een gescande image of de build zelf?
2. Repareert de tool transitieve afhankelijkheden, of alleen de directe die u declareert?
3. Hoe kiest de tool de gerepareerde versie: de minimale gepatchte versie, de nieuwste of een versie die u vastpint?
4. Wordt de fix gebouwd en getest voordat u die ziet, of draait hij voor het eerst in de pull request?
5. Kan de tool updates groeperen en plannen, zodat reviewers niet worden overspoeld?
6. Legt de tool vast welke releases waren getroffen en wanneer elke fix is geleverd?

De rol van CRACI op dit moment

CRACI draait uw GitHub Actions-jobs op zijn eigen runners en legt de pakketten vast die elke job daadwerkelijk heeft opgehaald, inclusief transitieve afhankelijkheden en pakketten die uit caches zijn teruggezet, met een volledigheidsstatus voor elke job. Die vastlegging is de inventaris waarvan een herstelworkflow zou moeten uitgaan.

CRACI beoordeelt gemonitorde SBOM's doorlopend opnieuw, dus wanneer er een nieuwe advisory verschijnt, ziet u welke geleverde builds die raakt over uw repositories heen. Securityteams triëren elke bevinding en sturen die naar het team dat verantwoordelijk is voor de fix, en CRACI ondersteunt VEX om vast te leggen hoe een kwetsbaarheid uw product raakt. De SBOM van de volgende build laat vervolgens zien of de build echt de gerepareerde versie heeft gebruikt. De pagina over het volgen van kwetsbaarheden behandelt de volledige functionaliteit.

Volgens de EU Cyber Resilience Act moeten fabrikanten kwetsbaarheden onverwijld aanpakken en verhelpen, onder meer via beveiligingsupdates. Een vastlegging van wat elke build bevatte en wanneer elke fix is geleverd, is het bewijs dat dat proces nodig heeft.

Geautomatiseerd herstel van kwetsbaarheden: veelgestelde vragen

Wat is geautomatiseerd herstel van kwetsbaarheden?

Geautomatiseerd herstel van kwetsbaarheden is software die van een kwetsbaarheidsbevinding een fix maakt zonder dat iemand het uitzoekwerk doet: ze bepaalt de gerepareerde versie, wijzigt het manifest, de lockfile of de code, en stelt de wijziging voor, meestal als pull request. Een mens, of een beleid dat het team vertrouwt, beslist nog steeds wat wordt gemerged.

Wat is het verschil tussen herstel en mitigatie van kwetsbaarheden?

Herstel verwijdert de kwetsbaarheid, bijvoorbeeld door te upgraden naar een gerepareerde versie of een patch toe te passen. Mitigatie verkleint het risico terwijl de kwetsbaarheid er nog is, bijvoorbeeld door de getroffen functie uit te schakelen of het aanvalspad te blokkeren. Mitigatie koopt tijd; herstel sluit de bevinding.

Kan herstel van kwetsbaarheden volledig worden geautomatiseerd?

Delen ervan wel. Getroffen builds vinden, advisories matchen en een versieverhoging voorstellen zijn mechanisch en laten zich goed automatiseren. Bepalen of een breaking upgrade veilig is en of een kwetsbaarheid uw product überhaupt raakt, vraagt nog steeds om oordeelsvermogen. De meeste teams automatiseren het voorstel en houden een mens, gesteund door tests, bij de merge.

Doet Dependabot aan geautomatiseerd herstel van kwetsbaarheden?

Dependabot security updates openen pull requests die een kwetsbare afhankelijkheid bijwerken naar de minimale gepatchte versie, voor de meldingen die GitHub geeft op de dependency graph van uw repository. Dat is geautomatiseerd herstel voor wat de manifests en lockfiles declareren. CRACI vs Dependabot behandelt waar gedeclareerd en geleverd van elkaar afwijken.

Waar moet ik op letten bij een tool voor kwetsbaarheidsherstel?

Waar de kwetsbaarheidslijst vandaan komt, of de tool transitieve afhankelijkheden aankan, hoe hij de fixversie kiest, of de fix wordt gebouwd en getest voordat u die ziet, en of hij vastlegt wat wanneer is gerepareerd. Dat laatste is van belang voor audits en voor de CRA, die fabrikanten vraagt kwetsbaarheden onverwijld te verhelpen.