KI-Sicherheitstools lesen Ihren Code. Ihren Build muss trotzdem etwas aufzeichnen.

Ihr Team setzt KI wahrscheinlich schon in der Sicherheit ein

Die meisten Engineering-Teams haben inzwischen mindestens ein KI-Tool im Sicherheitsprozess. Ein Modell prüft Pull Requests. Ein anderes schlägt Fixes für Warnungen der statischen Analyse vor. Ein drittes sortiert Scanner-Befunde in „ansehen“ und „wahrscheinlich Rauschen“. Diese Tools sparen echte Zeit, und nichts auf dieser Seite spricht gegen sie.

Die sinnvolle Frage ist, welche Aufgaben sie übernehmen sollten und welche Aufgaben eine Aufzeichnung brauchen, die jedes Mal gleich ausfällt. Die Folgefrage lautet: Was lesen Ihre KI-Tools, wenn sie eine Entscheidung über Ihre Abhängigkeiten treffen?

Was KI-Sicherheitstools gut können

• KI-Code-Review. GitHub Copilot Code Review hinterlässt Kommentare in natürlicher Sprache und Codevorschläge in Pull Requests und kann repositoryspezifischen Anweisungen folgen. Es ist gut bei der Lesearbeit, die ein ausgelasteter Reviewer überspringt.
• KI-Fixes. GitHub Copilot Autofix „erzeugt automatisch Vorschläge für Codeänderungen zu CodeQL-Warnungen, die in Pull Requests und im Default-Branch gefunden werden“. Entwickler erhalten einen vorgeschlagenen Patch neben der Warnung statt eines Links auf eine CWE-Seite.
• KI-Triage. Die KI-Funktionen von Semgrep sichten Befunde aus Semgrep Code automatisch und schlagen Fixes vor. Semgrep dokumentiert seine Rauschfilterung als „zu über 95 % genau bei der Einordnung von Semgrep-Code-Befunden als False Positives“.

Achten Sie auf das Muster bei den letzten beiden. Copilot Autofix arbeitet mit CodeQL-Warnungen. Die Triage von Semgrep arbeitet mit Befunden aus der regelbasierten Engine von Semgrep. Die KI fügt deterministischen Ergebnissen ein Urteil hinzu. Die zugrunde liegenden Befunde erzeugt sie nicht selbst.

Was die Anbieter selbst über die Grenzen sagen

Die klarsten Aussagen darüber, wo KI-Tools an ihre Grenzen stoßen, stammen von den Anbietern selbst, was für sie spricht.

• Zum Code Review schreibt GitHub, dass „Copilot möglicherweise nicht alle Probleme im Code erkennt“ und dass „ein Risiko von Halluzinationen besteht“, also Probleme hervorgehoben werden, die es nicht gibt.
• Zu Autofix schreibt GitHub, es „verwendet ein generatives Modell, das nicht deterministisch ist. Selbst bei derselben Warnung und demselben Code gelingt möglicherweise kein brauchbarer Vorschlag, oder der Vorschlag unterscheidet sich von Versuch zu Versuch.“
• Ebenfalls zu Autofix: „Das System weiß nicht, welche Abhängigkeitsversionen unterstützt oder sicher sind, und schlägt möglicherweise erfundene Abhängigkeiten vor, die unter statistisch wahrscheinlichen Namen veröffentlicht wurden.“

Nichts davon macht die Tools weniger nützlich. Es beschreibt ihre Aufgabe: Sie liefern Vorschläge, die ein Mensch prüft. Das ist eine andere Aufgabe, als die Aufzeichnung zu liefern, anhand derer dieser Mensch prüft.

Zwei Ebenen, zwei Aufgaben

CRACI arbeitet auf der Ebene der Aufzeichnung. Es ersetzt den GitHub-Actions-Runner (Sie ändern runs-on auf craci), und ein paketbewusster Proxy beobachtet während des Jobs den Datenverkehr des Builds zu den Paketquellen. Das Ergebnis ist eine SBOM dessen, was der Job tatsächlich geladen hat, ein Vollständigkeitsstatus für jeden Job und Cache sowie ein Netzwerk-Trace. Die API liefert SBOMs, Netzwerk-Traces und Provenienz.

Wo deterministische Sichtbarkeit nötig ist

„Sind wir betroffen?“

Wenn eine neue Sicherheitsmeldung erscheint, lautet die erste Frage, ob einer Ihrer Builds die betroffene Version enthielt. Die SBOM-Mindestelemente der CISA von 2026 formulieren die Anforderung klar: Der Empfänger einer SBOM „sollte schließen können, dass eine neu gemeldete Schwachstelle ihn nicht betrifft, wenn die SBOM die Komponente nicht auflistet“. Dieser Schluss gilt nur, wenn die Liste vollständig ist. Ein Modell kann Ihnen helfen, die Antwort zu lesen. Es sollte nicht darüber entscheiden, was im Build war.

CRACI führt Schwachstellen über Builds und Repositories hinweg zusammen und bewertet überwachte SBOMs neu, sobald neue Schwachstellen veröffentlicht werden. Die Frage wird also anhand dessen beantwortet, was aufgezeichnet wurde.

Abhängigkeiten, die eine KI hinzugefügt hat

KI-Coding-Assistenten fügen Abhängigkeiten hinzu, und Studien zeigen, dass sie manchmal Pakete nennen, die es nicht gibt. Eine auf der USENIX Security 2025 vorgestellte Studie erzeugte 576.000 Codebeispiele mit 16 Modellen und fand einen durchschnittlichen Anteil halluzinierter Pakete von mindestens 5,2 % bei kommerziellen und 21,7 % bei Open-Source-Modellen. Ein Name, den es heute nicht gibt, kann morgen registriert werden. Egal, wer oder was eine Abhängigkeit hinzugefügt hat: CRACI zeichnet das Paket auf, das der Build tatsächlich heruntergeladen hat, und Egress-Richtlinien können einen Job auf die Paketquellen beschränken, die Sie freigeben.

Audits und Kundenfragen

Ein Auditor oder das Sicherheitsteam eines Kunden wird fragen, woher Sie wissen, was ausgeliefert wurde. „Das Modell hat es gesagt“ ist eine schwache Antwort. „Hier ist die SBOM, aufgezeichnet während des Release-Builds, ihr Vollständigkeitsstatus und der Netzwerk-Trace dieses Jobs“ ist eine starke. SBOMs lassen sich als CycloneDX oder SPDX exportieren, einschließlich Schwachstellen, und die API liefert SBOMs, Netzwerk-Traces und Provenienz.

Reproduzierbare Antworten

Manche Fragen brauchen dieselbe Antwort, egal, wer fragt oder wann. Welche Pakete hat das Release vom letzten Dienstag geladen? Ein generatives Modell kann diese Antwort gut formulieren, aber nach Aussage seiner eigenen Anbieter womöglich jedes Mal anders. Ein aufgezeichneter Build liefert eine einzige Antwort.

Wie beides zusammenpasst

Bewährt hat sich das Muster, das Copilot Autofix und Semgrep bereits nutzen: deterministische Daten als Grundlage, KI-Urteil darüber.

1. Lassen Sie KI-Code-Review und KI-Fixes an Pull Requests arbeiten, wobei ein Mensch jede Änderung freigibt.
2. Lassen Sie CRACI aufzeichnen, was jeder Build geladen hat, und ausweisen, ob diese Aufzeichnung vollständig ist.
3. Wenn Sie KI-Unterstützung bei Abhängigkeitsrisiken möchten, geben Sie dem Modell die aufgezeichnete SBOM. Die öffentliche REST-API von CRACI liefert die SBOM als CycloneDX, den Netzwerk-Trace des Jobs und die Provenienz des Artefakts.
4. Bewahren Sie die aufgezeichnete SBOM als Nachweis auf, nicht die Zusammenfassung des Modells.

Wenn Ihr Team einen Großteil seines Codes mit KI-Assistenten schreibt, behandelt unsere Seite zur Sicherheit in der KI-gestützten Entwicklung diese Situation, und SBOM-Generierung während des Builds erklärt, wie die Aufzeichnung entsteht.