Security as Code
Was ist Security as Code?
Security as CodePraxis, Sicherheitskontrollen, Tests und Infrastruktur als Quellcode auszudrücken, sodass sie versioniert, peer-reviewt, automatisiert und kontinuierlich mit Apps ausgeliefert werden.
Security as Code (SaC) erweitert das Prinzip Policy as Code auf alle Sicherheitsartefakte: Detektionsregeln, IaC-Hardening, IAM-Berechtigungen, Secret-Konfiguration, Threat Models und CI/CD-Sicherheits-Gates liegen als Code in Git und werden über dieselben Pipelines ausgeliefert wie Anwendungsänderungen. Typische Bausteine sind Terraform-Module mit sicheren Defaults, Rego/Sentinel-Policy-Bundles, CodeQL- oder Semgrep-Regeln, Falco/Sigma-Detektionen sowie Kubernetes-Manifeste mit integriertem Security Context. Der Ansatz bietet Versionshistorie, Peer Review, automatisierte Tests, Drift-Erkennung und reproduzierbare Rollouts und ersetzt ticketgetriebenes Hardening durch kontinuierliche, auditierbare Security-Delivery im DevSecOps.
● Beispiele
- 01
Terraform-Modul liefert ein EKS-Cluster mit privaten Endpunkten und Audit Logs als Standard.
- 02
Semgrep-Regelsatz im Security-Rules-Repo versioniert; muss vor Merge erfolgreich laufen.
● Häufige Fragen
Was ist Security as Code?
Praxis, Sicherheitskontrollen, Tests und Infrastruktur als Quellcode auszudrücken, sodass sie versioniert, peer-reviewt, automatisiert und kontinuierlich mit Apps ausgeliefert werden. Es gehört zur Kategorie Cloud-Sicherheit der Cybersicherheit.
Was bedeutet Security as Code?
Praxis, Sicherheitskontrollen, Tests und Infrastruktur als Quellcode auszudrücken, sodass sie versioniert, peer-reviewt, automatisiert und kontinuierlich mit Apps ausgeliefert werden.
Wie funktioniert Security as Code?
Security as Code (SaC) erweitert das Prinzip Policy as Code auf alle Sicherheitsartefakte: Detektionsregeln, IaC-Hardening, IAM-Berechtigungen, Secret-Konfiguration, Threat Models und CI/CD-Sicherheits-Gates liegen als Code in Git und werden über dieselben Pipelines ausgeliefert wie Anwendungsänderungen. Typische Bausteine sind Terraform-Module mit sicheren Defaults, Rego/Sentinel-Policy-Bundles, CodeQL- oder Semgrep-Regeln, Falco/Sigma-Detektionen sowie Kubernetes-Manifeste mit integriertem Security Context. Der Ansatz bietet Versionshistorie, Peer Review, automatisierte Tests, Drift-Erkennung und reproduzierbare Rollouts und ersetzt ticketgetriebenes Hardening durch kontinuierliche, auditierbare Security-Delivery im DevSecOps.
Wie schützt man sich gegen Security as Code?
Schutzmaßnahmen gegen Security as Code kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für Security as Code?
Übliche alternative Bezeichnungen: SaC, DevSecOps as Code.
● Verwandte Begriffe
- cloud-security№ 839
Policy as Code
Praxis, Sicherheits-, Compliance- und Governance-Regeln in maschinenlesbarem Code zu definieren, sodass sie versioniert, getestet, reviewt und automatisch durchgesetzt werden.
- cloud-security№ 756
OPA (Open Policy Agent)
CNCF-graduierte, universelle Policy-Engine, die mit der Rego-Sprache Autorisierungsentscheidungen von Anwendungen und Kubernetes-Admission entkoppelt.
- cloud-security№ 600
Kubernetes-Sicherheit
Schutz eines Kubernetes-Clusters – API-Server, Control Plane, Nodes, Workloads und Netzwerk – vor Fehlkonfiguration, Kompromittierung und lateraler Bewegung.
- compliance№ 204
Compliance
Die Disziplin, gesetzliche, regulatorische, vertragliche und interne Sicherheitsanforderungen durch dokumentierte Kontrollen, Nachweise und laufende Bewertung einzuhalten.
- cloud-security№ 1014
Service-Mesh-Sicherheit
Sammlung von Identitäts-, Verschlüsselungs- und Autorisierungskontrollen, die ein Service Mesh bereitstellt, um Service-zu-Service-Traffic in Cloud-Native-Umgebungen abzusichern.
- network-security№ 1262
Zero Trust Network
Eine Netzwerkarchitektur, die Nutzer, Geräte oder Dienste niemals automatisch vertraut und jede Verbindung kontinuierlich identitätsbasiert prüft.