Automatisierte Schwachstellenbehebung, vom Befund zum Fix

Was automatisierte Schwachstellenbehebung bedeutet

Schwachstellenbehebung bedeutet, eine bekannte Schwachstelle aus Ihrer Software zu entfernen: durch ein Upgrade des betroffenen Pakets, einen Patch oder den Ersatz der Komponente. Die automatisierte Behebung übergibt den mechanischen Teil dieser Arbeit an Software. Sie liest einen Befund, ermittelt, welche Version ihn behebt, ändert Manifest, Lockfile oder Code und schlägt die Änderung vor, meist als Pull Request.

Bei Abhängigkeiten von Drittanbietern, wo die meisten bekannten Schwachstellen einer modernen Codebasis liegen, sieht der Ablauf in jedem Tool gleich aus:

1. Inventar. Wissen Sie, welche Pakete in welchen Versionen in allem stecken, was Sie ausliefern.
2. Abgleich. Prüfen Sie dieses Inventar gegen Advisories, und prüfen Sie weiter, sobald neue erscheinen.
3. Priorisierung. Entscheiden Sie nach Schweregrad, Ausnutzung und Exposition, was Sie zuerst beheben.
4. Fix. Wählen Sie die korrigierte Version, aktualisieren Sie darauf und passen Sie den Code an, falls das Upgrade etwas kaputt macht.
5. Verifizierung. Bauen und testen Sie die Änderung und bestätigen Sie dann, dass tatsächlich die korrigierte Version ausgeliefert wurde.
6. Dokumentation. Halten Sie fest, was betroffen war, wann es behoben wurde und in welchem Release.

Am stärksten ist die Automatisierung bei den Schritten 2, 4 und 6, wo die Arbeit repetitiv ist. Am schwächsten ist sie, wo die Eingaben falsch sind, und die Eingabe für alles Weitere ist Schritt 1.

Vier Arten der automatisierten Behebung

Ansatz	Was er tut	Beispiele	Wo er endet
Bots für Abhängigkeits-Updates	Öffnen Pull Requests, die eine verwundbare Abhängigkeit auf eine korrigierte Version anheben	Dependabot security updates, Renovate	Arbeiten mit den Manifesten und Lockfiles im Repository; bei einem Breaking Upgrade muss weiterhin ein Mensch den Code anpassen
SCA-Fix-Pull-Requests	Öffnen Upgrade-Pull-Requests für die Befunde eines kommerziellen SCA-Tools	Snyk, Black Duck, Aikido, Endor Labs	Die Abdeckung variiert: Manche Tools beheben nur direkte Abhängigkeiten, manche ergänzen Patches oder Backports
KI-Code-Fixes	Erzeugen eine Code-Änderung für einen Befund, oft eine Warnung der statischen Analyse	GitHub Copilot Autofix	Nicht deterministische Vorschläge, die geprüft werden müssen; siehe KI-gestützte Behebung
Automatische Behebung in der Infrastruktur	Macht eine Fehlkonfiguration rückgängig oder patcht einen Host, wenn eine Regel greift	Tools für Cloud Security Posture und Endpoints	Deckt laufende Infrastruktur ab, nicht die Abhängigkeiten in der Software, die Sie ausliefern

Die ersten drei beheben alle Code, den Sie ausliefern, und sie teilen eine Annahme: dass die Liste der verwundbaren Pakete, die sie beheben, die richtige Liste ist.

Jeder Fix hängt vom Inventar ab

Ein Tool zur Behebung kann nur die Schwachstellen beheben, die es kennt, und es kennt die, die sein Inventar enthält. Die meisten Inventare werden aus Dateien rekonstruiert: Manifesten, Lockfiles, installierten Paketen oder einem fertigen Container-Image. Diese Rekonstruktion übersieht Dinge auf vorhersehbare Weise.

• Pakete, die die Dateien nicht deklarieren. Tools, die der Build herunterlädt, Basis-Images, Plugins und alles, was ein Skript installiert, tauchen nie in einem Lockfile auf, also wird für sie auch nie ein Fix-Pull-Request geöffnet.
• Versionen, die vom Lockfile abweichen. Der Build löst möglicherweise eine andere Version auf als die, die ein Scanner liest, besonders ohne committetes Lockfile. Ein Fix, der sich auf die falsche Version stützt, ist eine selbstbewusste falsche Antwort.
• Aus Caches wiederhergestellte Pakete. Eine gecachte Abhängigkeit berührt die Registry nie wieder, daher kann das, was der Build genutzt hat, hinter dem zurückbleiben, was das Repository sagt.

Die Lösung besteht darin, von dem auszugehen, was der Build tatsächlich genutzt hat. Eine Build-Time-SBOM wird während des Builds aufgezeichnet und listet daher die Pakete auf, die der Job geladen hat, einschließlich transitiver, und nicht das, was laut einem Manifest nötig sein sollte. Eine Behebung, die dort ansetzt, behebt, was ausgeliefert wird.

Was Sie automatisieren und was Sie behalten sollten

Die meisten Teams, bei denen die Behebung funktioniert, teilen sie so auf:

• Automatisieren Sie das Finden und den Abgleich. Neue Advisories erscheinen jeden Tag. Jeden ausgelieferten Build von Hand erneut dagegen zu prüfen, skaliert nicht, und es ist genau die Art von Arbeit, die Software gut erledigt.
• Automatisieren Sie den Vorschlag. Die korrigierte Version zu wählen und die Änderung zu öffnen ist mechanisch. Gruppieren Sie zusammengehörige Updates, damit Reviewer einen Pull Request sehen statt zwanzig.
• Machen Sie den Merge von Tests abhängig. Mergen Sie Sicherheitsupdates auf Patch-Ebene automatisch, wenn die Testsuite sie abdeckt. Überlassen Sie Breaking Upgrades und alles ohne Testabdeckung einem Menschen.
• Überlassen Sie Ermessensentscheidungen Menschen. Ob eine Schwachstelle Ihr Produkt überhaupt betrifft und ob sich ein riskantes Upgrade diese Woche lohnt, sind Entscheidungen. Dokumentieren Sie sie, zum Beispiel als VEX-Aussage, damit dieselbe Frage nicht zweimal gestellt wird.

So bewerten Sie ein Tool zur Behebung

Bevor Sie einem Tool zutrauen, Pull Requests in Ihren Repositories zu öffnen, fragen Sie:

1. Woher stammt seine Schwachstellenliste: aus Dateien im Repository, einem gescannten Image oder dem Build selbst?
2. Behebt es transitive Abhängigkeiten oder nur die direkten, die Sie deklarieren?
3. Wie wählt es die korrigierte Version: die kleinste gepatchte, die neueste oder eine, die Sie pinnen?
4. Wird der Fix gebaut und getestet, bevor Sie ihn sehen, oder läuft er im Pull Request zum ersten Mal?
5. Kann es Updates gruppieren und planen, damit es Reviewer nicht überflutet?
6. Dokumentiert es, welche Releases betroffen waren und wann jeder Fix ausgeliefert wurde?

Wo CRACI heute steht

CRACI führt Ihre GitHub-Actions-Jobs auf eigenen Runnern aus und zeichnet die Pakete auf, die jeder Job tatsächlich geladen hat, einschließlich transitiver Abhängigkeiten und aus Caches wiederhergestellter Pakete, mit einem Vollständigkeitsstatus für jeden Job. Diese Aufzeichnung ist das Inventar, von dem ein Workflow zur Behebung ausgehen sollte.

CRACI bewertet überwachte SBOMs laufend neu, sodass Sie bei einem neuen Advisory sehen, welche ausgelieferten Builds es über Ihre Repositories hinweg betrifft. Sicherheitsteams sichten jeden Befund und leiten ihn an das Team weiter, das für den Fix zuständig ist, und CRACI unterstützt VEX, um festzuhalten, wie sich eine Schwachstelle auf Ihr Produkt auswirkt. Die SBOM des nächsten Builds zeigt dann, ob der Build wirklich die korrigierte Version genutzt hat. Die Seite zur Schwachstellenverfolgung beschreibt den vollen Funktionsumfang.

Nach dem EU Cyber Resilience Act müssen Hersteller Schwachstellen unverzüglich behandeln und beheben, auch durch Sicherheitsupdates. Eine Aufzeichnung dessen, was jeder Build enthielt und wann jeder Fix ausgeliefert wurde, ist der Nachweis, den dieser Prozess braucht.

Automatisierte Schwachstellenbehebung: häufig gestellte Fragen

Was ist automatisierte Schwachstellenbehebung?

Automatisierte Schwachstellenbehebung ist Software, die aus einem Schwachstellenbefund einen Fix macht, ohne dass ein Mensch die Kleinarbeit leistet: Sie ermittelt die korrigierte Version, ändert Manifest, Lockfile oder Code und schlägt die Änderung vor, meist als Pull Request. Was gemergt wird, entscheidet weiterhin ein Mensch oder eine Policy, der das Team vertraut.

Was ist der Unterschied zwischen Behebung und Mitigation von Schwachstellen?

Die Behebung entfernt die Schwachstelle, zum Beispiel durch ein Upgrade auf eine korrigierte Version oder einen Patch. Die Mitigation verringert das Risiko, solange die Schwachstelle noch vorhanden ist, zum Beispiel durch Deaktivieren der betroffenen Funktion oder Blockieren des Angriffswegs. Die Mitigation verschafft Zeit; die Behebung schließt den Befund.

Lässt sich die Schwachstellenbehebung vollständig automatisieren?

Teilweise. Betroffene Builds zu finden, Advisories abzugleichen und ein Versions-Upgrade vorzuschlagen, ist mechanisch und lässt sich gut automatisieren. Zu entscheiden, ob ein Breaking Upgrade sicher ist oder ob eine Schwachstelle Ihr Produkt überhaupt betrifft, erfordert weiterhin Urteilsvermögen. Die meisten Teams automatisieren den Vorschlag und lassen beim Merge einen Menschen entscheiden, gestützt auf Tests.

Leistet Dependabot automatisierte Schwachstellenbehebung?

Dependabot security updates öffnen Pull Requests, die eine verwundbare Abhängigkeit auf die kleinste gepatchte Version aktualisieren, für die Warnungen, die GitHub zum Abhängigkeitsgraphen Ihres Repositories ausgibt. Das ist automatisierte Behebung für das, was Manifeste und Lockfiles deklarieren. CRACI vs. Dependabot zeigt, wo sich Deklariertes und Ausgeliefertes unterscheiden.

Worauf sollte ich bei einem Tool zur Schwachstellenbehebung achten?

Woher seine Schwachstellenliste stammt, ob es mit transitiven Abhängigkeiten umgehen kann, wie es die Fix-Version wählt, ob der Fix gebaut und getestet wird, bevor Sie ihn sehen, und ob es dokumentiert, was wann behoben wurde. Letzteres zählt für Audits und für den CRA, der von Herstellern verlangt, Schwachstellen unverzüglich zu beheben.