Die klassische Priorisierung von Abhilfemaßnahmen stützt sich nach dem Bericht auf Software Bills of Materials, VEX-Erklärungen und CVSS-Bewertungen. SBOMs listen die in einer Software enthaltenen Komponenten auf, VEX gibt an, ob bekannte Schwachstellen in einer konkreten Produktkonfiguration ausnutzbar sind, und CVSS dient als Schweregradmaß. Nach Einschätzung von Devashri Datta funktioniert dieses Modell jedoch nicht ausreichend, weil Lieferkettenangriffe weiter zunehmen und der notwendige Nutzungskontext fehlt.
Genau dieser Kontext werde im Zeitalter von KI immer wichtiger. Datta verweist darauf, dass die Auswirkungen einer Ausnutzung je nach Phase des KI-Lebenszyklus unterschiedlich ausfallen können. Als Beispiel nennt sie zwei Schwachstellen: eine kritische Remote-Code-Execution-Lücke mit CVSS 9.8 in einem Backoffice-Analyse-Dashboard und einen moderaten Eingabevalidierungsfehler mit CVSS 5.2 in einem Sensor-Fusion-Modul eines autonomen Lieferroboters in einem öffentlichen Lager. Nach bisheriger Logik würde zuerst die kritische Backoffice-Lücke gepatcht. Der Fehler im Roboter könne jedoch unter Umständen Menschen schaden.
Datta formuliert das Problem so: VEX könne zwar mitteilen, dass eine Schwachstelle nicht ausnutzbar sei, liefere aber keinen Sicherheitskontext. Es könne also nicht abbilden, welche Folgen eine Ausnutzung in einem realen System hätte. Besonders bei agentischen KI-Systemen mit realen Aktionen sei die Angriffsfläche zudem anders verteilt als bei traditioneller Software: über Trainingsdaten, Modellgewichte, Inferenz-Pipelines, Werkzeug-Integrationen und die Bereitstellungsinfrastruktur. Eine Kompromittierung in jeder dieser Phasen könne das Verhalten verändern, und zwar schwer erkennbar und noch schwerer zuzuordnen.
Hier setzt SRIL an. Datta beschreibt die Ebene als strukturierte Annotation über bestehenden Schwachstellendaten, die CVSS und VEX um vier Kontextdimensionen ergänzt, die in sicherheitskritischen Umgebungen benötigt würden, von heutigen Standards aber nicht abgedeckt seien. Zusammen sollen diese Dimensionen es Sicherheitsteams ermöglichen, eine sicherheitsangepasste Priorität zu berechnen – also einen Triage-Wert, der nicht nur die isolierte Schwere einer Schwachstelle, sondern ihre Bedeutung im konkreten Betriebskontext widerspiegelt.
Der Aufwand dafür bleibt laut Datta zunächst manuell und liegt beim DevSecOps-Team. Die SRIL-Daten werden anschließend von AIVEX verarbeitet. AIVEX erzeugt daraus kontextreiche, maschinenlesbare Entscheidungen wie „sofort beheben“, „verschieben“ oder „beobachten“. Datta bezeichnet AIVEX als vorgeschlagene Erweiterung des CycloneDX-VEX-Schemas. Die Erweiterung bilde SRIL in strukturierten Feldern für Modellherkunft, Klassifizierung der Angriffsfläche zur Inferenzzeit, Annotation des Sicherheitsbereichs und Phase des KI-Lebenszyklus ab. Sie sei darauf ausgelegt, sich in bestehende SBOM-Werkzeuge zu integrieren, nicht sie zu ersetzen. Laut Datta wird der Vorschlag derzeit von der CycloneDX-Arbeitsgruppe aktiv geprüft.
Nach ihren Angaben gibt es bereits erste Umsetzungen. Flexera habe den Ansatz übernommen und werde die Version in der kommenden Woche an Kunden ausliefern. Anchore arbeite ebenfalls daran und wolle die Funktion in der nächsten Version bereitstellen.
Datta sieht neben der besseren Priorisierung noch einen zweiten Vorteil: regulatorische Nachvollziehbarkeit. In ihrem bei ISACA zur Veröffentlichung vorgesehenen Beitrag schreibt sie, ein lebenszyklusbasierter Interpretationsansatz verbessere Nachverfolgbarkeit und Auditierbarkeit, ohne neue Compliance-Lasten einzuführen. Als Bezugspunkte nennt sie das Secure Software Development Framework von NIST, das risikobasierte Entscheidungen fördert, sowie das NIST AI Risk Management Framework. Außerdem verweist sie auf den EU AI Act, dessen anspruchsvollste Anforderungen für in regulierte Produkte eingebettete KI nach ihrer Darstellung erst ab August dieses Jahres vollständig durchgesetzt werden, sowie auf sektorbezogene Leitlinien von FDA, CISA und dem Department of Transportation. Diese Entwicklungen würden unabhängig voneinander in dieselbe Richtung weisen: auf einen strukturierten Mechanismus, der Schwachstellendaten mit Sicherheitsfolgen verknüpft.