Am 22. März veröffentlichte NIST die endgültige Version des SSDF 1.1 (Secure Software Development Framework).
Das Framework wurde zunächst im September 2021 als Entwurfsversion veröffentlicht. Alle übergeordneten Praktiken und Aufgaben bleiben gleich, wobei sich viele Unterschiede auf die verschiedenen bereitgestellten Beispiele konzentrieren.
Was ist das NIST SP 800-218-Framework? Das SSDF bündelt langjährige Best-Practice-Empfehlungen für eine sichere Softwareentwicklung. Sein anpassbarer, branchenunabhängiger Ansatz ist darauf ausgelegt, die abteilungsübergreifende (und Produzent/Akquirer-)Kommunikation zu erleichtern, um bei der Definition strategischer Ziele und der Bewertung aktueller Lücken zu helfen.
NIST empfiehlt, bei der Entscheidung, welche Praktiken implementiert werden sollen, das Risiko gegen Kosten, Durchführbarkeit und Anwendbarkeit abzuwägen. Automatisierung ist ein Schlüsselmerkmal, das mit dem angestrebten Ziel in Betracht gezogen werden muss, möglichst viele Prüfungen und Prozesse zur Förderung der Softwaresicherheit zu automatisieren.
Unterschiede zwischen der endgültigen und der Entwurfsversion:
Integritätsüberprüfung – Bei der Diskussion von Schwachstellen liegt der Schwerpunkt eher auf der Integritätsüberprüfung wenn Sie sich sowohl Ihren Code als auch die von externen Quellen erworbenen Bibliotheken/Produkte ansehen.
Unveränderliche Bescheinigungen - Die Verantwortung für die Umsetzung der Praktiken kann auf verschiedene Organisationen verteilt sein, insbesondere wenn man die Komplexität der Software-Lieferketten berücksichtigt. Die Sicht nimmt erheblich ab, je weiter man in der Kette stromaufwärts oder stromabwärts geht. Aus diesem Grund empfiehlt NIST, die gemeinsame Verantwortung sowohl der Anbieter als auch der Verbraucher einer Plattform/eines Dienstes in einem Vertrag oder einer Vereinbarung festzuschreiben. Es sollte klar sein, welche Partei für jede Praxis und Aufgabe verantwortlich ist und wie jeder Anbieter seine Konformität mit der Vereinbarung bescheinigt. Hier gilt der Grundsatz „Vertrauen, aber überprüfen“ – unveränderliche Bescheinigungen Informationen, die problemlos zwischen Softwareherstellern und Softwarekäufern geteilt werden können, sind der Schlüssel zur Stärkung des Vertrauens aller Beteiligten in die Softwarelieferkette.
Beteiligung der Open-Source-Community – NIST gibt an, dass die zukünftige Arbeit wahrscheinlich die Form spezifischer Anwendungsfälle annehmen wird und dass es beabsichtigt, mit diesen zusammenzuarbeiten die Open-Source-Community. Wenn man bedenkt, dass die meisten heute verwendeten kommerziellen Codeprodukte wesentliche Open-Source-Codeelemente enthalten, ist es selbstverständlich, die Open-Source-Community in die Planung und Implementierung der Software-Lebenszyklussicherheit einzubeziehen.
Schweregradbewertung der Sicherheitslücke als KRI (Key Risk Indicator) – Eine weitere Änderung, die Wirkung zeigt, ist der Schweregrad als Schlüsselindikator. Angesichts der Tatsache, dass viele Cyber-Sicherheitsmitarbeiter unter Alarmmüdigkeit leiden, ist es sinnvoll, dass jedes Unternehmen die für es geeignete Schwachstellenbewertungsskala und die spezifische Behandlung definiert, die jede dieser Bewertungen verdient.
Weniger menschlicher Zugriff, mehr Automatisierung – NIST fordert die Minimierung des direkten menschlichen Zugriffs auf Toolchain-Systeme wie Build-Services. Je mehr Menschen Zugriff haben, desto mehr Fehler können passieren. Dies entspricht wiederum der Empfehlung einer stärkeren Automatisierung.
SBOMs mit Integrität – Bei der Erörterung der SBOM (Software Bill of Materials) empfiehlt NIST, die Integrität des Artefakts stark zu schützen und den Empfängern eine Möglichkeit zu bieten, diese Integrität zu überprüfen. Bei den Empfängern kann es sich sowohl um Personen innerhalb als auch außerhalb des Unternehmens handeln. Daher ist es sinnvoll, ein Drittsystem für den Austausch sicherer SBOMs einzusetzen.
Integrität von Binär- und Quellcode – Wenn die Integrität oder Herkunft der erworbenen Binärdateien nicht bestätigt werden kann, wird empfohlen, diese Binärdateien aus dem Quellcode neu zu erstellen. Dies setzt voraus, dass Sie die Integrität und Herkunft des Quellcodes überprüfen können. Es liegt in der Verantwortung aller Glieder der Software-Lieferkette, durch digitale Signaturen oder andere Mechanismen wie eine SBOM einen überprüfbaren Integritätsnachweis zu erbringen.
Zusammenfassung
Insgesamt ist das NIST der Ansicht, dass „die Praktiken, Aufgaben und Implementierungsbeispiele der SSDF einen zu berücksichtigenden Ausgangspunkt darstellen.“ Sie sollen verändert und angepasst werden und sich im Laufe der Zeit weiterentwickeln.“
Bei der SSDF handelt es sich nicht um eine Checkliste, die Sie befolgen sollten, sondern um eine Anleitung zur Planung und Umsetzung eines risikobasierten Ansatzes zur sicheren Softwareentwicklung.
Im Gegensatz zu gesetzesbasierten US-Vorschriften wird das SSDF unternehmensbasiert sein – die Regierung wird ihre Kaufkraft nutzen, um den Markt dazu zu bringen, sich an dieses neue Best-Practice-Rahmenwerk zu halten. Wenn Sie die Einhaltung des Rahmenwerks nicht nachweisen können, werden Sie für Regierungsaufträge nicht berücksichtigt. Wir werden wahrscheinlich einen Trickle-Down-Effekt erleben, bei dem Unternehmen, die sich um Regierungsaufträge bewerben möchten, von allen ihren Anbietern und Zulieferern ebenfalls die Einhaltung verlangen werden, und so weiter entlang der Software-Lieferkette.
Um mehr über die neuen Vorschriften und SSDF zu erfahren, schauen Sie sich unser Webinar an „Entmystifizierung neuer Cybersicherheitsvorschriften im Jahr 2022“.
Diese Inhalte werden Ihnen von Scribe Security zur Verfügung gestellt, einem führenden Anbieter von End-to-End-Sicherheitslösungen für die Software-Lieferkette, der modernste Sicherheit für Code-Artefakte sowie Code-Entwicklungs- und Bereitstellungsprozesse in der gesamten Software-Lieferkette bietet. Weitere Informationen.
Zusammenhängende Artikel
