Building Security In Maturity Model 12 Security Best Practices in der Software-Entwicklung

Redakteur: Stephan Augsten

Wie reell ist die Gefahr von Sicherheitsvorfällen und von Unterbrechungen der Software-Lieferkette? Im „Building Security In Maturity Model“- oder kurz BSIMM-Report listet Synopsys wichtige Software-Sicherheitspraktiken von Unternehmen.

Firmen zum Thema

Auf Grundlage des „Building Security In Maturity Model 12“ gibt Synopsys einige Denkanstöße für mehr Sicherheit in der Software-Entwicklung.
Auf Grundlage des „Building Security In Maturity Model 12“ gibt Synopsys einige Denkanstöße für mehr Sicherheit in der Software-Entwicklung.
(Bild: TeroVesalainen / Pixabay )

Das 2008 initiierte Building Security In Maturity Model (BSIMM) ist ein Tool zur Erstellung, Analyse und Bewertung von Software-Sicherheitsinitiativen. Die als BSIMM12 bezeichnet 12. Auflage untersucht die Softwaresicherheitspraktiken von 128 Unternehmen aus unterschiedlichen Branchen. Fast 3.000 Mitglieder aus Softwaresicherheits-Teams und über 6.000 sogenannte „Satellite Members“ tragen mit ihrer Erfahrung dazu bei.

Die jüngsten Daten zeigen, dass Identifizierung und Open-Source-Management seitens der Software-Security-Teams in den letzten beiden Jahren um 61 Prozent gestiegen sind. „Mit ziemlicher Sicherheit“ lässt sich das laut Synopsys auf die Verbreitung von Open-Source-Komponenten in moderner Software und eine wachsende Zahl von Angriffen zurückführen, die populäre Open-Source-Projekte als Vektor nutzen.

Die Studie verzeichnet zudem einen signifikanten Anstieg von Sicherheitsbemühungen hinsichtlich Cloud-Plattformen und Container-Technologien. Dies wiederum sei ein deutlicher Indikator für die dramatischen Auswirkungen dieser Technologien auf die Software-Sicherheitskonzepte der Unternehmen. So lässt sich bei der „Nutzung von Orchestrierung für Container und virtualisierte Umgebungen“ innerhalb der letzten beiden Jahre ein Anstieg um 560 Prozent beobachten.

Laut der in BSIMM erhobenen Daten hat sich die Rolle der mit Softwaresicherheit befassten Gruppen verändert: von der Vorgabe geeigneter Verhaltensregeln hin zu einer partnerschaftlichen Zusammenarbeit. Es werden Ressourcen, Personal und Wissen für DevOps-Praktiken geteilt. Ziel ist es, Sicherheit in den kritischen Pfad der Softwarebereitstellung mit einzubeziehen.

Gleichzeitig nutzen die Firmen zusätzliche Möglichkeiten, beispielsweise die Inventarisierung von Software und das Erstellen von Software-Stücklisten (SBOM). Die automatisierte Erkennung von Assets und die Erstellung von Stücklisten derartige Aktivitäten mit ein. Dazu zählt auch die Verwendung von Containern, um Sicherheitskontrollen zu verstärken, Orchestrierung zu erlauben sowie das Scannen von Infrastructure as Code.

Orientierung an führenden Unternehmen

Basierend auf den BSIMM12-Daten empfiehlt Synopsys einige zentrale Maßnahmen. Diese eigneten sich sowohl Unternehmen, die aktuell eine Software-Sicherheitsinitiative entwickeln, als auch für jene, die bereits ein Software-Sicherheitsprogramm pflegen:

  • Wann immer möglich, Telemetrie für Sicherheitstests verwenden, um Daten zu sammeln, z. B. welche Tests wurden durchgeführt und welche Probleme dabei festgestellt, um Verbesserungen im Softwareentwicklungslebenszyklus oder bei den Governance-Prozessen voranzutreiben.
  • Setzen Sie auf die Automatisierung von Sicherheitsentscheidungen mit dem letztendlichen Ziel einer überprüfbaren Governance-as-Code. Governance-as-Code verlagert Sicherheitspraktiken und die Einhaltung von Compliance weg von einem manuellen Ansatz hin zu einem konsistenten, effizienten und wiederholbaren automatisierten Ansatz.
  • Ein umfassendes Softwareinventar erstellen (einschließlich einer „Software-Stückliste“ oder BOM) sämtlicher Assets. Diese Liste sollte sowohl intern erstellten Code als auch Open-Source- und Drittanbieter-Code mit einbeziehen.
  • Fokussierte, schrittweise Sicherheitsaktivitäten im gesamten SDLC implementieren, statt umfangreicher, zäher Pass/Fail-Gates, die den Fortschritt der Pipeline zwangsläufig verzögern.
  • Automatisierte Sicherheitstools einsetzen, die Fehler, Schwachstellen und bösartigen Code in unternehmenskritischer Software identifizieren und beheben, unabhängig davon, ob es sich um intern entwickelte Software, kommerzielle Software von Drittanabietern oder Open Source handelt.

(ID:47685384)