TL; DR
Die meisten Sicherheitsanforderungen für die Softwareentwicklung werden als Absichtserklärungen formuliert, was bedeutet, dass niemand sie erfüllen oder nicht erfüllen kann. „Abhängigkeiten müssen sicher sein“ liest sich gut und übersteht die Prüfung, bis ein Auditor die Datei einsehen möchte. Diese Checkliste für Software-Sicherheitsanforderungen enthält zwölf Zeilen, die genau umgekehrt formuliert sind.
- Eine Anforderung ist nur dann überprüfbar, wenn drei Dinge gegeben sind. Ein benanntes Artefakt, ein Zeitpunkt der Überprüfung und ein definiertes Verhalten bei einem Fehler. Die meisten Software-Sicherheitsanforderungen scheitern bereits am ersten Punkt.
- Jede der 12 Zeilen liefert Beweise. Eine Herkunftsbescheinigung, eine SBOM gebunden an eine veröffentlichte Version, einen Widerrufszeitstempel, ein Gate decision mit einem Besitzer. Kein Scannerbericht.
- Sie teilten sich in drei Gruppen auf. Was fließt in Ihre Software ein, was baut sie auf und was beweist ihren Zustand?
- Die Überprüfung dieser Daten ist eine SSCS und ASPM Das Problem liegt nicht am Scanner. Sechs Werkzeuge ergeben sechs dashboardEin Wirtschaftsprüfer verlangt eine eindeutige Antwort. Die Beweise müssen aus einer einzigen Quelle stammen, sonst werden sie gar nicht anerkannt.
Warum versagen die meisten Sicherheitsanforderungen an die Softwareentwicklung, sobald sie überprüft werden?
Öffnet man ein beliebiges Dokument mit Sicherheitsanforderungen, findet man Sätze wie „Komponenten von Drittanbietern müssen frei von bekannten Sicherheitslücken sein“ und „der Build pipeline „Muss gesichert werden.“ Sie lesen sich gut. Sie überstehen die Überprüfung. Und dann ein Auditor, ein Kundenfragebogen zur Sicherheit oder ein NIS2 or DORA Der Prüfer stellt eine einfache Frage: Zeigen Sie es mir.
An diesem Punkt scheitert die Anforderung, da niemand festgehalten hat, was „frei von bekannten Schwachstellen“ in welchem Stadium des Lebenszyklus bedeutet, wer die Entscheidung trifft und welche Datei übergeben werden muss. Das Team gerät in Panik, exportiert einen Scannerbericht und hofft, dass die Vielzahl der Ergebnisse als Sorgfaltspflicht interpretiert werden kann.
Das Problem liegt nicht im Arbeitsaufwand. Teams, die vier oder fünf Tools einsetzen, leisten bereits viel. Das Problem besteht vielmehr darin, dass die Anforderungen an die Softwaresicherheit einen gewünschten Zustand beschreiben, anstatt ein überprüfbares Ereignis. Ein gewünschter Zustand ist nicht nachweisbar. Ein Ereignis hingegen schon. Alles, was die Sicherheitsüberprüfung von Softwareentwicklungsprozessen ermöglicht, basiert auf dieser Unterscheidung.
Was macht eine Software-Sicherheitsanforderung überprüfbar?
Drei Eigenschaften, und eine Anforderung benötigt alle drei:
- Ein benanntes Artefakt. Eine Bescheinigung, eine SBOM, eine signierte Schallplatte, ein Tor decisIon. Etwas, das als Datei oder Protokolleintrag existiert und auf Anfrage erzeugt werden kann.
- Ein Moment. Pull request, erstellen, veröffentlichen oder kontinuierlich. „Irgendwann im Laufe der SDLC„ist kein Augenblick.“
- Ein definiertes Ausfallverhalten. Was passiert, wenn die Prüfung fehlschlägt: Blockieren, Warnung ausgeben, unter Quarantäne stellen oder an einen benannten Eigentümer mit einem dokumentierten Ausnahmepfad weiterleiten.
Prüfen Sie Ihre aktuellen Anforderungen anhand dieser drei Kriterien. Die meisten werden beim ersten Kriterium scheitern, weshalb Teams am Ende mit den Prüfern verhandeln müssen, anstatt deren Fragen zu beantworten.
Die folgenden zwölf Zeilen sind so formuliert, dass jede einzelne alle drei Kriterien erfüllt. Sie sind bewusst langweilig gehalten. Überprüfbare Anforderungen sind üblicherweise so.
Checkliste für Sicherheitsanforderungen in der Softwareentwicklung: 12 Zeilen, die tatsächlich überprüfbar sind
In jeder Zeile wird das Artefakt genannt, das dies beweist, die Frage, die es prüft, und woher die Beweise stammen.
Gruppe eins: Was gelangt in Ihre Software?
| Anforderung | Überprüfen durch | Beweisbar |
|---|---|---|
| 01Jede Abhängigkeit wird auf schädliches Verhalten überprüft, ohne auf eine veröffentlichte Signatur zu warten. | Anfrage nach dem Screening-Ergebnis für jedes Paket, das in den letzten 30 Tagen hinzugefügt wurde | Frühwarnung vor Malware erkennt schädliche Pakete im gesamten Code. pipelines, IaC und Register, bevor eine Unterschrift oder Empfehlung vorliegt, unter Verwendung von Beweiserkennung mit anschließender KI-Validierung |
| 02Jede Veröffentlichung hat eine SBOMAbrufbar nach Version, generiert durch den Build-Prozess und nicht manuell zusammengestellt | Eine veröffentlichte Version benennen und nach ihrer SBOM innerhalb von fünf Minuten | SBOM Generation pro Gebäude, einschließlich der beigefügten Meldung zur Offenlegung von Sicherheitslücken |
| 03Eine Sicherheitslücke verhindert die Veröffentlichung nur dann, wenn sie in Ihrem Code auslösbar ist. | Man nehme drei blockierte Ergebnisse und frage sich, welcher Funktionspfad sie ausnutzbar macht. | Erreichbarkeit auf Funktionsebene, Ausnutzbarkeit und EPSS innerhalb des Priorisierungstrichters |
| 04Bekannte Schwachstellen enthalten einen Besitzer und einen Deployment-Code.cisIon, nicht nur eine Eintrittskarte | Man wählt einen beliebigen offenen kritischen Befund aus und fragt, wer das Risiko akzeptiert hat und bis wann. | Eigentumsverhältnisse und Status werden anhand des jeweiligen Assets erfasst, nicht anhand eines Scanvorgangs. |
| 05Abhängigkeiten von KI und maschinellem Lernen werden wie gewöhnliche Lieferketten behandelt, weil sie | Frage, welche CVEs die heute produktiv eingesetzten ML-Bibliotheken betreffen. | Eine Kompositionsanalyse, die den KI-Stack auf derselben Plattform wie die KI-Assets umfasst, die ihn nutzen. |
Gruppe zwei: Was baut Ihre Software auf?
| Anforderung | Überprüfen durch | Beweisbar |
|---|---|---|
| 06Jeder Build erzeugt eine Herkunftsbescheinigung, die unabhängig überprüft werden kann. | Die Attestierung für das aktuellste Produktionsartefakt wird abgerufen und mit dem Quellcode verglichen. commit | SLSA provenance und benutzerdefinierte In-Toto-Bescheinigungen mit schlüssellosen Signaturen, die in einer beliebigen Registry gespeichert werden, wobei manipulierte Artefakte vor der Zustellung blockiert werden. |
| 07Pipeline Die Konfiguration wird als Code gescannt, im gleichen Rhythmus wie der Anwendungscode. | Es wird gefragt, wann die letzte Konfigurationsänderung von GitHub Actions oder Jenkins einer Sicherheitsprüfung unterzogen wurde und von wem. | CI/CD Sicherheitdienst in pipeline Fehlkonfigurationen, fehlerhafte Arbeitsabläufe und Lieferkettenrisiken, mit SSCS Compliance integriert |
| 08Jedes Geheimnis, das irgendwo im Lebenszyklus gefunden wird, wird widerrufen, nicht nur gemeldet. | Anfrage nach den letzten fünf erkannten Geheimnissen und deren Widerrufszeitpunkten | Erkennung über Code, Konfigurationen, Container und pipelinemit über 100 geheimen Typen, plus automatischer Widerruf playbooks pro Anmeldeinformationstyp |
| 09Anomale Aktivität in der pipeline löst eine Warnung aus, bevor es zu einem Vorfall kommt. | Sich zu fragen, was ein beeinträchtigter Läufer oder ein ungewöhnlicher commit Das Muster würde ausgelöst werden, und wer es empfängt | Erkennung von Anomalien über Aktivitäten, die einem Angriff vorausgehen |
Gruppe drei: Was beweist den Zustand Ihrer Software?
| Anforderung | Überprüfen durch | Beweisbar |
|---|---|---|
| 10Die Infrastruktur als Code wird vor dem Zusammenführen geprüft, nicht nach der Bereitstellung korrigiert. | Die Frage ist, ob eine unsichere Terraform-Änderung die Hauptdatei erreichen kann und was dies verhindert. | IaC Scannen mit guardrails im pull request |
| 11Die Ergebnisse aller Tools, sowohl Ihrer eigenen als auch der von Drittanbietern, basieren auf einem gemeinsamen Schweregradmodell. | Sich zu fragen, ob ein kritischer Bericht von einem Scanner und ein kritischer Bericht von einem anderen für Ihr Team dasselbe bedeuten. | Das ASPM Schicht nimmt Erkenntnisse aus dem SAST, SCA, DAST und IaC Die Tools, die Sie bereits verwenden, unabhängig davon, wer sie entwickelt hat, werden nach denselben Kriterien priorisiert, geprüft, erklärt und behoben wie bei nativen Ergebnissen. |
| 12Alle KI-Komponenten im Quellcode sind inventarisiert und exportierbar. | Sie fragen ab, welche Modelle, Agenten und MCP-Server in Ihren Anwendungen laufen, und fordern die Datei an. | Kontinuierliche Erkennung von Modellen, Frameworks, Datensätzen, Inferenzendpunkten, Agenten, MCP-Servern, Fähigkeiten, Eingabeaufforderungen und KI-Codierungswerkzeugen, mit einem CycloneDX ML-BOM Bei jedem Scan generiert |
Wem gehört jede Zeile der Checkliste?
Ein Anforderungsdokument ohne Spalte für Verantwortliche ist eine Wunschliste. Weisen Sie jeder Zeile einen Verantwortlichen zu, bevor Sie es veröffentlichen:
Die zweite Spalte ist diejenige, die in der Praxis versagt. Kontinuierliche Überprüfung funktioniert nur dann, wenn die Beweise sich von selbst sammeln.
Wie kann man eine Checkliste für die Sicherheitsanforderungen der Softwareentwicklung überprüfen, ohne eine weitere Konsole hinzuzufügen?
Hier scheitern die meisten Programme. Die zwölf oben genannten Anforderungen betreffen Abhängigkeiten, pipelineSie erstellen Artefakte, Geheimnisse, Infrastrukturcode und KI-Assets. Überprüfen Sie diese mit sechs verschiedenen Tools, und Sie haben eine siebte Aufgabe geschaffen: die Abstimmung von sechs dashboards in eine Antwort für einen Prüfer, der eine einzige Zahl wünscht.
Zwei Fähigkeiten machen dies durchführbar.
- Software supply chain security (SSCS) umfasst die Anforderungen, die zwischen den commit und das Artefakt. Abhängigkeiten pipelineDie Integrität von Gebäuden, Geheimnisse und anomale Aktivitäten stellen eine Angriffsfläche dar, und genau dort befinden sich auch die am schwersten zu fälschenden Beweise: Eine unterzeichnete Bestätigung ist für einen Gutachter wertvoller als ein Scannerbericht, da sie nicht nachträglich wiederhergestellt werden kann.
- ASPM ist die Ebene, die Erkenntnisse in eine Haltung umwandelt, über die man berichten kann. Das ist aus einem bestimmten Grund wichtig: Es verarbeitet die Ergebnisse Ihrer bestehenden Scanner. Sie müssen Ihre bereits bezahlten Tools nicht ersetzen, um diese Checkliste zu erfüllen. Die Ergebnisse werden als Eingabe verwendet, und die Priorisierung, KI-gestützte Triage, Erklärung und Behebung gelten sowohl für diese als auch für die nativen Ergebnisse. Ein Sicherheitsprogramm für die Softwareentwicklung, das auf einer Plattform basiert, die nur die eigenen Scanner versteht, wird immer dann scheitern, wenn verschiedene Systemumgebungen zusammenkommen – und jede Systemumgebung kommt vor.
Was ändert sich, wenn ein Agent den Code schreibt?
Alles oben Genannte ging davon aus, dass die Änderung von einem Menschen verfasst und von einem anderen überprüft wurde. Diese Annahme verliert an Gültigkeit und verändert die Anforderungen an die Sicherheit in der Softwareentwicklung grundlegend.
Wenn ein Codierungsagent tausend Dateien pro Woche produziert, verliert die Codeüberprüfung ihre Kontrollfunktion und wird zur Warteschlange. Drei der zwölf Zeilen haben in diesem Kontext die größte Bedeutung: die Überprüfung auf bösartige Abhängigkeiten (da Agenten Pakete schnell herunterladen und irreführende Paketnamen nun als Angriffsvektor gelten), pull request Analyse, die nach Ausnutzbarkeit und nicht nach Schweregrad geordnet ist, und Inventar der KI-Assets.
Es gibt außerdem eine vierte Anforderung, die es wert wäre, in jede Checkliste für Software-Sicherheitsanforderungen aufgenommen zu werden, die im Jahr 2026 erstellt wird: Die Konfigurationsdateien, die Ihre KI-Tools steuern, werden als Sicherheitsartefakte überprüft. Skilldateien, Regeldateien und MCP-Serverkonfigurationen sind commitSie werden als Klartext verfasst und wie Dokumente geprüft und legen fest, was ein Assistent zu tun hat und worauf er zugreifen darf.
Wie gelangt man von der Checkliste zum Beweismaterial?
Schreiben Sie nicht gleich das gesamte Dokument neu. Nehmen Sie sich die drei Zeilen vor, die bei Ihrem nächsten Audit, Kundenfragebogen oder Ihrer nächsten Vorstandssitzung tatsächlich geprüft werden. SBOM Auf Anfrage, geheimer Widerruf und Herkunftsnachweis. Beweisen Sie diese drei Punkte anhand des Artefakts. Erweitern Sie die Funktionalität anschließend.
Die Checkliste für Sicherheitsanforderungen in der Softwareentwicklung ist kein Dokument.cise. Es ist der Unterschied zwischen einem Sicherheitsprogramm, das Fragen beantworten kann, und einem, das sich nur selbst beschreiben kann. Zwölf verifizierbare Zeilen sind besser als vierzig angestrebte, denn zwölf davon überstehen den Kontakt mit jemandem, der die Datei einsehen möchte.
Wenn Ihre Software-Sicherheitsanforderungen kein Artefakt auf Abruf erzeugen können, haben Sie keine Anforderungen. Sie haben Absichten mit einer Versionsnummer.
Sehen Sie selbst, was Ihr Nachlass bereits beweist. Verbinden Sie ein Repository, und Xygeni Gibt Ihre Abhängigkeiten zurück, pipelines, Geheimnisse, Integritätsstatus der Systeme und KI-Inventar in einer einzigen Ansicht, mit den zu jedem Befund gehörenden Nachweisen. Kostenlos starten or Demo buchen.
FAQ
Wie viele Software-Sicherheitsanforderungen sollte eine Checkliste enthalten?
Weniger als Sie denken. Die sinnvolle Anzahl ist die, die Sie bei Bedarf überprüfen können, was für die meisten Teams zwischen 10 und 20 liegt. Eine Checkliste mit 60 Anforderungen, von denen 45 keine Nachweise enthalten, ist weniger aussagekräftig als eine Checkliste mit 12 Anforderungen, bei der jede Zeile einen Nachweis liefert. Beginnen Sie mit den Punkten, die Ihr nächstes Audit prüfen wird, und erweitern Sie die Liste von dort aus.
Worin besteht der Unterschied zwischen Softwareentwicklungssicherheit und einem Compliance-Rahmenwerk?
Rahmenwerke wie NIS2, DORA oder der Cyber Resilience Act definieren die erwarteten Ergebnisse. Die Sicherheit in der Softwareentwicklung legt fest, wie diese Ergebnisse in Prüfungen umgesetzt werden, die Ihr Entwicklungsteam bestehen oder nicht bestehen kann. pull request Oder man baut etwas Neues. Frameworks werden für Gutachter geschrieben, Anforderungen für Entwickler, und die meisten Probleme in einem Compliance-Programm entstehen dadurch, dass niemand diese Übersetzung vornimmt.
Kann ich eine Checkliste mit Software-Sicherheitsanforderungen mit den Scannern überprüfen, die ich bereits habe?
Teilweise. Scanner liefern Ergebnisse, und für einige dieser Anforderungen werden stattdessen Artefakte benötigt: eine Herkunftsbestätigung, eine SBOM im Zusammenhang mit einer veröffentlichten Version, einem Widerrufsdatensatz, einem Gate-Decision mit einem Besitzer. Deshalb befindet sich die Checkliste auf SSCS und ASPM Anstatt auf einem Scanner. Der praktische Weg besteht darin, die vorhandenen Scanner beizubehalten und eine darüberliegende Ebene einzuführen, die deren Ergebnisse erfasst und ein einheitliches Priorisierungsmodell auf alle anwendet.
Welche Anforderung wird von Teams am häufigsten falsch erfüllt?
Geheimnisse. Fast jede Checkliste besagt, dass Geheimnisse nicht … commitFast keine Dokumentation besagt, dass ein erkanntes Geheimnis innerhalb eines definierten Zeitraums widerrufen werden muss. Wird es erkannt, ohne dass der Widerruf erfolgt, verbleibt eine gültige Zugangsberechtigung im Verlauf des Repositorys, und dieser Verlauf ist öffentlich, sobald das Repository erstellt wird. Formuliert man diese Zeile als Widerrufsanforderung mit einem Zeitstempel, wird sie überprüfbar.
