Der Quelltext beschreibt einen grundlegenden Wandel in der Software-Lieferkettensicherheit: KI-generierter Code lasse sich nicht einfach wie zusätzlicher Quellcode behandeln, der durch vorhandene Scanner läuft. Das greife zu kurz, weil sich das Risiko verlagert habe. Die entscheidende Frage nach der Herkunft und Vertrauenswürdigkeit eines Artefakts betreffe nun nicht mehr nur das Endprodukt, sondern ebenso das Modell, den Agenten und die Werkzeuge, die an seiner Entstehung beteiligt sind.
Konkret nennt der Text mehrere neue Angriffspunkte. Ein KI-Coding-Assistent kann demnach eine Abhängigkeit vorschlagen, die ein Entwickler übernimmt, ohne dass das Paket je bewusst in einem menschlichen Bedrohungsmodell bewertet wurde. Ein autonomer Agent kann über MCP auf ein Werkzeug zugreifen, um eine Aufgabe zu erledigen, woraufhin dieses Werkzeug seinerseits weitere Werkzeuge nachlädt. Hinzu kommen Eingabeaufforderungen, die ein Angreifer so platziert, dass ein Modell sie liest und dadurch beeinflusst wird, was geschrieben oder welche Abhängigkeit eingebunden wird.
Die Prüfung von KI-generiertem Code vor dem Commit bezeichnet der Quelltext zwar als Grundvoraussetzung. Das eigentliche Problem liege aber in der Steuerung der Agenten, die den Code schreiben, und der Werkzeuge, die sie aufrufen. Nach Darstellung der Autoren fehlt es Teams nicht an Funden, sondern eher an der Fähigkeit, diese sinnvoll zu bearbeiten. Eine zusätzliche Anweisung, auch noch die Ausgabe von KI zu scannen, mache den Berg an Warnungen nur größer, stärke das Sicherheitsprogramm aber nicht automatisch.
Der Text nennt deshalb zwei notwendige Änderungen. Erstens müsse die Nachverfolgbarkeit auf alles ausgeweitet werden, was in die Pipeline gelangt, einschließlich Modelle und Agenten. Als möglicher Ansatz wird beschrieben, die Herkunfts- und Aktivitätskette auf die gesamte Pipeline auszudehnen: von der ersten Code-Änderung bis zur Laufzeit, einschließlich Aktivitäten, Provenienz und Konfigurationsänderungen. Für Modelle und Agenten müsse dabei dieselbe Strenge gelten wie für jede andere Abhängigkeit.
Zweitens müsse die Priorisierung auf tatsächlicher Ausnutzbarkeit beruhen, nicht auf der Menge der Findings. Laut Quelltext liegt der Unterschied zwischen einer bloßen Liste von Schwachstellen und einer praktisch nutzbaren Angriffskette in der Korrelation mit dem Laufzeitkontext und der Frage, was tatsächlich erreichbar ist. Gerade wenn ein Agent in kurzer Zeit große Mengen plausiblen Codes erzeugen kann, werde diese Unterscheidung noch wichtiger.
Als Signal für die Marktrelevanz verweist der Quelltext auf Gartner. Das Analystenhaus habe im Juni erstmals einen Magic Quadrant für Software Supply Chain Security veröffentlicht. Das sei die Anerkennung eines Problems, gegen das Teams bislang verteidigt hätten, ohne dass dafür eine eigene Budgetposition vorgesehen gewesen sei.
Außerdem kündigt der Text ein Webinar von OX-Forschern am 22. Juli an: „Wie KI die Sicherheit von Lieferketten verändert, wie wir sie kennen“. Dort solle neue Forschung vorgestellt werden, gemeinsam mit Sicherheitsverantwortlichen aus der Praxis. Genannt werden drei Themen: wie die Integration von KI die Angriffsfläche verändert hat, Erkenntnisse aus der ersten systematischen Untersuchung von MCP-Servern in freier Wildbahn und die Frage, wie ein Programm für Software-Lieferkettensicherheit konkret aussieht, wenn KI von Beginn an zum Geltungsbereich gehört statt erst nachträglich ergänzt zu werden.