Sicherheit prüfen, bevor etwas ausgeliefert wird

Wie StandardOS das prüft

Nur lesend verbunden, nach Zeitplan. Eine bestandene Prüfung hält einen Nachweiseintrag frisch; eine fehlgeschlagene lässt ihn verfallen, sodass eine Verschlechterung auffällt, statt auf das Audit zu warten. Jede Integration, und was die jeweiligen Zugangsdaten sehen können.

• GitHub · StandardOS liest ob der Standard-Branch bestandene Statusprüfungen vor einem Merge verlangt, damit Tests laufen, bevor etwas ausgeliefert wird, und nicht danach.
• GitHub · StandardOS liest ob Code-Scanning oder eine Prüfschranke Teil dessen ist, was den Standard-Branch schützt.
• AWS · StandardOS liest ob ECR Images prüft, bevor sie ausgerollt werden.
• Snyk · StandardOS liest welche aktiven Projekte das Testen von Pull Requests abgeschaltet haben, sodass eine verwundbare Abhängigkeit nach dem Merge gemeldet statt davor gestoppt wird.

Risiken, die dieses Control behandelt

Aus dem Start-Risikoregister, das StandardOS bei der Einrichtung vorschlägt. Sie behalten, bearbeiten oder löschen jedes einzelne; dies sind die, die A.8.29 als Behandlung nennen.

• Von einem Lieferanten geschriebener Code gelangt ungeprüft in ProduktionAnwendung

Was Kunden zu diesem Control fragen

Sicherheitsfragebögen verwenden keine Control-Nummern. Dies sind die Fragen, so wie Kunden sie stellen, die auf A.8.29 hinauslaufen. Jede wird aus denselben vier Aufzeichnungen beantwortet: dem SoA-Status, der genehmigten Richtlinie, datierten Nachweisen und einer laufenden Prüfung. Die vollständige Karte der dreißig Themen.

• Folgen Sie einem sicheren Entwicklungszyklus mit Code-Review und Änderungsmanagement?

  Sichere Entwicklung, Code-Review, Änderungsmanagement, CI/CD · auch A.8.25, A.8.32

Wo dies unter NIS2 steht

A.8.29 ist Teil dessen, was Artikel 21 Absatz 2 Buchstabe e, Security in network and information systems acquisition, development and maintenance, verlangt. Es einmal umzusetzen zählt für beides, und genau deshalb gibt es die NIS2-Zuordnung.