Five Best Practices for Building Security as Code into a Continuous Delivery Pipeline

Dies ist der vierte Blog unserer Mini-Serie, der zeigt, wie BMC agile Entwicklung, Cloud-Dienste, einen Infrastructure-as-Code-Ansatz und neue Bereitstellungstechnologien genutzt hat, um ein cloudnatives Produkt zu liefern. Lesen Sie auch unbedingt mit: Einstieg mit cloudnativen Anwendungen, 9 Schritte zum Aufbau von Pipelines für Continuous Delivery und Deployment sowie Infrastruktur und wie "Alles als Code" alles verändert Sicherheit als Code in eine CI/CD-Pipeline einzubauen bedeutet, Sicherheitsrichtlinien, Tests und Compliance-Prüfungen als versionierte, automatisierte Artefakte zu behandeln, die in jeder Phase der Bereitstellung laufen – Schwachstellen während der Entwicklung erkennen und nicht schon beim Release. Die fünf Best  Practices unten zeigen, wie Ingenieurteams Security-as-Code- und Compliance-As-Code-Prinzipien direkt in eine kontinuierliche Lieferpipeline integrieren können, um sowohl Sicherheit als auch Geschwindigkeit zu  gewährleisten .

Warum ist Sicherheit als Code in einer CI/CD-Pipeline wichtig? 

Wenn die Sicherheit von Anfang an nicht integriert ist, wird sie zum Engpass im schlimmstmöglichen Moment. Wenn ein Release sich der Bereitschaft der Bereitschaft nähert, werden Teams in eine späte Phase aus Schwachstellen-Scanning, Penetrationstests und Bedrohungsmodellierung gezwungen – ausgeführt durch manuelle Werkzeuge, Checklisten und Prüfungsdokumente. Wenn in dieser Phase kritische oder hohe Schwachstellen auftreten, stocken Releases wochen- oder monatelang, während Probleme behoben werden.  Das Security-as-Code-Prinzip  beseitigt diesen Engpass, indem es Sicherheitspraktiken kodifiziert und deren Ausführung als Teil einer DevOps-Pipeline automatisiert. Sicherheit und Compliance werden kontinuierlich durchgesetzt – sowohl im  Anwendungsfall -, Design-, Entwicklungs- als auch Testphase der Anwendungsbereitstellung – und nicht auf eine Pre-Release-Überprüfung überwiesen. Sicherheitsrichtlinien, Tests und Ergebnisse werden als First-Class-Code-Artefakte behandelt: im selben Repository versioniert und durch dieselbe CI/CD-Pipeline wie Anwendungscode durchgeführt. 

Was sind die fünf Best Practices, um Sicherheit und  Compliance als Code anzuwenden? 

Die folgenden Praktiken basieren auf der Erfahrung von BMC beim Aufbau einer cloudnativen Anwendung auf Amazon Web Services (AWS). Jede behandelt eine eigene Ebene des Security-as-Code-Ansatzes – von  der ersten Richtliniendefinition bis zur Produktionsbehebung.

1. Definition und Kodifizierung von Sicherheitsrichtlinien

Sicherheitsrichtlinien sollten gleich zu Beginn eines Projekts definiert und zusammen mit Anwendungscode in einem Quellcode-Repository gespeichert werden. Für eine cloudnative-Anwendung auf AWS umfasst dies Anforderungen wie: 

• Sicherheitsgruppen und Firewalls werden gesichert 
• Virtual Private Cloud (VPC), Elastic Load Balancing und verwandte Dienste werden durchgesetzt und gesichert 
• Alle EC2- und anderen Ressourcen müssen  sich im VPC befinden und einzeln gefirewallt werden 
• Alle AWS-Ressourcen und Protokolle wurden mit Key Management Services verschlüsselt

Sicherheitsrichtlinien müssen ebenfalls automatisiert werden – eine einzelne Aktion sollte sie für jede Anwendung in jeder Phase oder Umgebung bewerten können. Alles rund um Sicherheit wird kodifiziert, versioniert und automatisiert; Sicherheitsartefakte werden wie Anwendungscode in ein Repository eingecheckt.  Unternehmen sollten standardisierte Sicherheitsmuster erstellen, um eine Wiederverwendung über Organisationen und Anwendungen hinweg zu ermöglichen. Eine 3-Stufen-Anwendung und eine Entwicklungs-/Testcloud-Umgebung benötigen beispielsweise jeweils  ihre eigene Standard-Sicherheitsvorlage. Mit AWS können die fünf NIST AWS CloudFormation-Vorlagen Netzwerke, VPCs sowie Identitäts- und Zugriffsmanagement-Rollen verstärken – und so eine "gehärtete Cloud"-Grundlage bilden. Für private Cloud- oder On-Premises-Infrastruktur übernimmt BMC BladeLogic Server Automation das Server-Hardening .

2. Security User Stories definieren und das Risiko der Anwendungsarchitektur bewerten

Sicherheitsbezogene User Stories müssen im agilen Prozess genauso definiert werden wie jede andere Feature Story. Beispiele sind: 

• "Eingabevalidierung für standortübergreifendes Skripting und SQL-Injektion"
• "SSL/TLS für alle Kommunikationen aktiviert"
• "Automatisierte Anwendungssicherheitstests"

Diese Praxis stellt sicher, dass Sicherheit niemals optional oder aufgeschoben behandelt wird. Sicherheitskontrollen werden  anhand von Anwendungssicherheitsrisiken und Bedrohungsmodellen sowohl für die Anwendungs- als auch für die Infrastrukturarchitektur identifiziert und dann im Anwendungscode oder durch Richtlinien implementiert. 

3. Überprüfen und die Sicherheit beim Check-in von Anwendungscodes überprüfen und beheben

Sicherheitstests sollten automatisch ausgelöst werden, sobald Code eingecheckt ist – sowohl für Anwendungs- als auch für Infrastrukturänderungen. Viele Sicherheitsschwachstellen-Scan-Tools  sind von BMC, Drittanbietern und Open-Source-Projekten verfügbar, um die Erkennung und Behebung zu automatisieren. Wenn kritische oder hohe Schwachstellen festgestellt werden, können Automatisierungstools Fehler oder Tickets erzeugen, die dem  Komponenteninhaber zur Behebung zugewiesen werden.   Bei cloudnativen Anwendungen beinhaltet das  Testen beim Code-Check-in die Bewertung von Infrastructure-as-Code-Artefakten – wie AWS CloudFormation-Vorlagen – anhand definierter Sicherheitsrichtlinien. 

4. Sicherheitsrichtlinien zu testen, um sicherzustellen, dass sie keine Anforderungen verletzen.

Sicherheitsrichtlinien selbst müssen überprüft werden, um sicherzustellen, dass sie keine  Konfigurationen mit bekannten Fehlern zulassen . Beispiele für Prüfungen von Richtlinienverletzungen sind: 

• "Keine S3-Eimer sollten öffentlich lesbar oder beschreibbar sein"
• "Verwenden Sie keine offenen Sicherheitsgruppen mit 0.0.0.0/allen erlaubten Datenverkehr" 

Diese Tests sollten im Rahmen der Anwendungsbereitstellungspipeline automatisiert werden. In der Pipeline von BMC für seine cloudnative-Anwendung werden Sicherheitsscans von Spinnaker orchestriert, um  jeden Push-in die Produktion zu validieren . Für regulatorische Compliance-Prüfungen – wie  Center for Internet Security (CIS) und die Defense Information Systems Agency (DISA) Anforderungen über Server, Datenbanken  und Netzwerke hinweg – kann die BMC BladeLogic-Produktsuite Compliance-Verstöße erkennen und beheben. 

5. Testen und Sanieren von Sicherheit und Einhaltung in der Produktion

Automatisierte Sicherheits- und Compliance-Tests setzen sich fort, während eine Anwendung Entwicklungs-, Qualitätssicherungs- und Testumgebungen durchläuft. Das Risiko, in dieser Phase kritische Probleme zu finden, ist geringer, da die meisten Sicherheitsautomatisierungen viel früher in der Pipeline laufen. Für Produktionsumgebungen unterstützen BMC BladeLogic Server Automation und BMC Threat Director Sicherheitspatches nach dem Scannen von Produktionsservern auf veränderliche Infrastruktur.  Dieser Schritt  bleibt entscheidend: Mehr als 80 % der Angriffe zielen auf bekannte Schwachstellen ab, und 79 % der Schwachstellen verfügen über Patches am Tag der Offenlegung. Für Anwendungen, die in öffentlichen Clouds wie AWS bereitgestellt werden, können Sicherheits- und Compliance-Bewertungen über Spinnaker automatisiert werden.   In modernen cloudnativen Stacks werden Komponenten nie direkt gepatcht – sie werden vollständig ersetzt. Dennoch müssen neue Container oder Server Sicherheits- und Compliance-Tests bestehen, bevor sie in die Produktion eingeliefert werden. 

Links verschieben : Sicherheitskräfte von Anfang an starten

Das Shift-Left-Prinzip  bedeutet, die Sicherheit vom Ende des Release-Prozesses bis zum Anfang zu verschieben – und sie während der gesamten DevOps-Pipeline dort zu halten. Anstatt Sicherheit als letztes Gate zu behandeln oder periodische Scans der Produktionsumgebungen durchzuführen, integrieren Teams Security-as-Code-Praktiken in jeder Phase der Bereitstellung – von der Richtliniendefinition beim Projektstart bis hin zu automatisierten Compliance-Prüfungen in der Produktion. Durch die Kodifizierung von Richtlinien, Automatisierung von Tests und die Integration der Compliance in die CI/CD-Pipeline können Produktteams  sowohl die Sicherheit als auch die Innovationsgeschwindigkeit aufrechterhalten . 

Häufig gestellte Fragen zur Sicherheit als Code in CI/CD

Was ist der Unterschied zwischen Security as Code und DevSecOps?  Security as Code ist eine spezifische Praxis innerhalb von DevSecOps , bei der Sicherheitsrichtlinien, Tests und Compliance-Prüfungen als versionierte, automatisierte Code-Artefakte behandelt werden, die in einem Quellcode-Repository gespeichert sind. DevSecOps ist die breitere kulturelle und organisatorische Praxis, Sicherheitsverantwortung über den gesamten Softwareentwicklungszyklus hinweg zu integrieren – Security as Code ist die technische Implementierung, die DevSecOps umsetzbar macht .  Was bedeutet "nach links verschieben" im Kontext von Sicherheitstests?   Nach links zu verschieben bedeutet, Sicherheitstests und -validierung früher im Entwicklungsprozess zu verlagern – idealerweise bis zum Code-Check-in – anstatt auf Staging oder Release zu warten. In einer Security-as-Code-Pipeline werden automatisierte Sicherheitsprüfungen bei jedem Commit durchgeführt und Schwachstellen in der Entwicklungsphase erkannt, wo sie am günstigsten und am schnellsten zu beheben sind.  Welche Tools unterstützen automatisierte Sicherheitstests in einer CI/CD-Pipeline?  Gängige Werkzeuge sind Schwachstellenscanner, Infrastructure-as-Code-Policy-Validatoren und Compliance-Automatisierungsplattformen . BMC BladeLogic Server Automation, BMC Threat Director und Pipeline-Orchestratoren wie Spinnaker sind Beispiele für Werkzeuge, die automatisierte Sicherheits- und Compliance-Tests in Entwicklungs-, Qualitätssicherungs- und Produktionsumgebungen unterstützen.  Warum sind standardisierte Sicherheitsmuster für Cloud-Anwendungen wichtig?  Standardisierte Sicherheitsmuster ermöglichen es Teams, bewährte Sicherheitskonfigurationen – wie gehärtete VPC-Vorlagen oder verschlüsselte Speicherrichtlinien – in mehreren Anwendungen und Umgebungen wiederzuverwenden. Dadurch entfällt die Notwendigkeit, dass jedes Team Sicherheit von Grund auf neu definieren muss, und gewährleistet eine konsistente, sofortige Sicherheitsabdeckung in der gesamten Organisation. NIST AWS CloudFormation-Vorlagen sind ein Beispiel für ein wiederverwendbares, gehärtetes Cloud-Muster.   Wie reduziert Security-As-Code Release-Verzögerungen, die durch Sicherheitsüberprüfungen verursacht werden?  Durch die Automatisierung von Sicherheits- und Compliance-Überprüfungen beim Code-Check-in und während der gesamten CI/CD-Pipeline erkennt Security-As-Code Schwachstellen während der Entwicklung und nicht erst zum Zeitpunkt der Veröffentlichung. Dadurch  werden die kurzfristigen manuellen Sicherheitsbewertungen – Penetrationstests, Schwachstellenscanning, Bedrohungsmodellierung –, die traditionell Deployments wochen- oder monatelang stoppen, wenn kritische Probleme kurz vor der Produktion entdeckt werden.  Die in diesem Beitrag geäußerten Ansichten und Meinungen sind die des Autors und spiegeln nicht unbedingt die offizielle Position von BMC wider.

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.