DevSecOps-Beratung
DevSecOps bedeutet, Sicherheitskontrollen als festen Bestandteil der Software-Delivery-Pipeline und des Betriebs auszuführen, so weit wie möglich automatisiert. Wir integrieren Code-, Abhängigkeits- und Container-Scans, Secrets-Management (Passwörter, API-Schlüssel, Zertifikate und andere vertrauliche Zugangsdaten) und Prüfungen der Cloud-Konfiguration in Ihren Delivery-Prozess, sodass Befunde schon während der Entwicklung sichtbar werden und nachverfolgt werden.
- Schwerpunkt
- Pipeline-Sicherheit, Software-Lieferkette, Container und IaC, Secrets-Management, Cloud-Konfiguration
- Umgebungen
- Public Cloud, lokale Cloud-Anbieter, Rechenzentrum, hybrid
- Referenzrahmen
- OWASP SAMM, NIST SSDF, SLSA, CIS
- Erster Schritt
- Kostenloses Erstgespräch oder kostenloses Assessment mit Sicherheitsfokus
Wann kommt DevSecOps ins Spiel?
Je früher ein Sicherheitsbefund sichtbar wird, desto leichter lässt er sich beheben. Deshalb rücken wir Kontrollen näher an den Anfang des Entwicklungsprozesses und in ihn hinein.
- Sicherheitstests finden gebündelt vor dem Release statt. Werden Befunde früher und in kleineren Teilen sichtbar, lässt sich der Release-Plan leichter einhalten.
- Passwörter und Schlüssel liegen an verschiedenen Orten. Passwörter und Zugangsschlüssel sollten in einem zentralen Secrets-Vault verwaltet, Zugriffe nachverfolgt und regelmäßig erneuert werden.
- Wird eine neue Schwachstelle bekannt, dauert die Auswirkungsanalyse. Ein aktuelles Inventar (SBOM), das zeigt, welche Komponentenversion in welcher Anwendung läuft, verkürzt diese Zeit.
- Die Cloud-Konten sind über die Zeit gewachsen. Berechtigungen, Netzwerkregeln und Logging-Einstellungen sollten anhand eines Standards überprüft werden.
- Nachweise für Audits und Kundenanfragen kosten Zeit. Laufen Kontrollen automatisch und werden ihre Ergebnisse aufbewahrt, entstehen Nachweise als Nebenprodukt der täglichen Arbeit.
- Unternehmenskunden fragen, was in Ihrer Software steckt. Zunehmend wird erwartet, dass Sie die eingesetzten Open-Source-Komponenten und ihren Sicherheitsstatus dokumentieren können.
Was leisten wir im Rahmen von DevSecOps?
Von der Entwicklung bis zum Betrieb: die Bereiche, die Sicherheitskontrollen automatisiert und messbar machen.
Sicherheit der Delivery-Pipeline
Statische Codeanalyse (SAST) und Abhängigkeitsscans (SCA) bei jeder Änderung, zeitgesteuerte dynamische Tests (DAST); Befunde in den Tools der Entwickler.
Container- und IaC-Sicherheit
Images scannen und signieren, Signaturen beim Deployment prüfen; Fehlkonfigurationen in Terraform und Kubernetes vor dem Release erkennen.
Secrets- und Zugriffsmanagement
Passwörter und Schlüssel in einen zentralen Secrets-Vault überführen, regelmäßig und automatisch rotieren, Zugriffe nach dem Prinzip minimaler Rechte gestalten.
Sicherheitskonfiguration der Cloud
Prüfung der Konten- und Netzwerkarchitektur, Härtung nach den CIS Benchmarks und laufende Kontrolle der Cloud-Konfiguration.
Sicherheit der Software-Lieferkette
Ein Komponenteninventar (SBOM) für jedes Release, signierte Releases und Build-Nachweise (Provenance) nach SLSA.
Monitoring und Incident Response
Sicherheitslogs, aussagekräftige Alarme und Laufzeit-Monitoring; die Schritte der Incident Response als Runbooks festgehalten.
Erst die hohen Risiken, dann die Automatisierung.
Wir gehen zuerst die Bereiche mit dem höchsten Risiko an, automatisieren dann die Kontrollen und verankern sie in der täglichen Arbeit Ihres Teams. Welche Befunde ein Release stoppen, legen wir gemeinsam mit Ihnen fest.
Woran orientieren wir uns?
Wir gestalten Kontrollen, indem wir sie anerkannten Frameworks zuordnen:
- Reifegradmodell OWASP SAMM
- NIST SSDF (SP 800-218) für sichere Softwareentwicklung
- SLSA-Stufen für die Software-Lieferkette
- OWASP Top 10 und ASVS
- Härtungsleitfäden der CIS Benchmarks
Risiko- und Ist-Analyse
Wir prüfen Ihre Delivery-Pipeline, Cloud-Konten, Zugriffsrechte und vorhandenen Sicherheitstools.
Ergebnis: Priorisierte Risikoliste und Baseline der bestehenden BefundeVorrangige Korrekturen
Wir gehen Befunde mit hoher Priorität an, etwa offenliegende Secrets, zu weit gefasste Berechtigungen und aus dem Internet erreichbare Ressourcen.
Ergebnis: Behebungs- und Prüfstatus der vorrangigen BefundeKontrollen in der Pipeline verankern
Wir ergänzen die Pipelines um Scans, Richtlinien und Quality Gates und filtern unnötige Alarme heraus.
Ergebnis: Automatisierte SicherheitskontrollenMonitoring und Reaktion
Wir nehmen Sicherheitslogs, Alarme und Abläufe für die Incident Response in Betrieb.
Ergebnis: Alarmregeln, RunbooksKontinuierliche Verbesserung
Wir berichten regelmäßig über Befunde, verfolgen Trends und schulen Ihr Team in sicherer Entwicklung.
Ergebnis: Berichte und SchulungenWas Sie am Ende eines DevSecOps-Projekts in der Hand haben.
Die Kontrollen laufen in Ihrer Delivery-Pipeline; Nachweise und Prozesse sind dokumentiert und liegen bei Ihnen.
Risiko- und Befundbericht
Priorisierte Befunde, mögliche Auswirkungen, Verantwortliche und empfohlene Schritte zur Behebung.
Sichere Pipeline-Vorlagen
Wiederverwendbare Vorlagen mit Schritten für Scans, Quality Gates, SBOM und Signierung.
Setup für Secrets-Management
Vault-Konfiguration, Zugriffsrichtlinien und Abläufe zur Schlüsselrotation.
Richtliniensätze
Als Code definierte Sicherheitsrichtlinien für Kubernetes und IaC.
Runbooks für Incident Response
Schrittweise Abläufe für Reaktion, Kommunikation und Rollback.
Schulung zu sicherer Entwicklung
Praxisnahe Sessions für Entwicklungs- und Betriebsteams.
Prozess vor Tools.
Wir bewerten Ihre vorhandenen Tools und schließen Lücken mit Open-Source- oder Enterprise-Lösungen.
Anwendungssicherheitstests
- SonarQube
- Semgrep
- CodeQL
- ZAP
- Snyk
- GitLab Security
Abhängigkeiten und SBOM
- OWASP Dependency-Check
- Dependency-Track
- Syft
- Grype
Container, IaC und Signierung
- Trivy
- Cosign
- Checkov
- Kyverno
- OPA Gatekeeper
Secrets-Management und Leak-Erkennung
- HashiCorp Vault
- AWS Secrets Manager
- Azure Key Vault
- External Secrets
- Gitleaks
- TruffleHog
Monitoring und Erkennung
- Falco
- Wazuh
- Elastic Security
- Microsoft Sentinel
- OpenSearch
Der Einstieg in sichere Delivery, passend zu Ihrer Größe.
KMU und kleine Softwareteams
Am Anfang stehen Secrets-Management, Abhängigkeitsscans und grundlegende Cloud-Härtung; Ziel ist große Wirkung mit wenigen Tools.
Teams mit Unternehmenskunden
Vorbereitung auf Sicherheitsfragen von Kunden und auf Audits mit SBOMs, signierten Releases und Pipelines, die Nachweise erzeugen.
IT- und Sicherheitsteams in Unternehmen
Vorhandene Sicherheitstools an die Delivery-Pipeline anbinden, Policy as Code und gemeinsame Standards über Teams hinweg.
Damit das erste Gespräch ergiebig wird.
Nichts davon ist Voraussetzung; alles, was Sie bereits haben, macht das erste Gespräch konkreter.
Was Sie vorbereiten können, falls vorhanden
- Eine Liste der Code-Repositories und Pipelines
- Eine Liste der Cloud-Konten und Umgebungen
- Eingesetzte Sicherheitstools und, falls vorhanden, aktuelle Scan-Ergebnisse
- Ihre kritischsten Anwendungen und die Arten von Daten, die sie verarbeiten
- Sicherheitsanforderungen aus Audits oder von Kunden
Fragen zu DevSecOps
Quellen und Standards
- OWASP SAMM (öffnet in neuem Tab)Reifegradmodell für Softwaresicherheit
- NIST SP 800-218 (SSDF) (öffnet in neuem Tab)Framework für sichere Softwareentwicklung
- SLSA (öffnet in neuem Tab)Framework für die Sicherheit der Software-Lieferkette
- CycloneDX (öffnet in neuem Tab)SBOM-Standard
- CIS Benchmarks (öffnet in neuem Tab)Benchmarks zur Konfigurationshärtung
Gehen wir die Sicherheit Ihrer Software-Auslieferung gemeinsam an.
Im kostenlosen Erstgespräch besprechen wir Ihre aktuelle Situation und Ihre Ziele und teilen unsere erste Einschätzung sowie mögliche nächste Schritte noch im selben Gespräch.
- Ein fachliches Gespräch mit Spezialisten für Ihr Thema
- Eine erste Einschätzung Ihrer Situation und mögliche Ansätze
- Wenn es passt, ein nächster Schritt: Assessment, Projektangebot oder Beratung
- Bei Bedarf eine Vertraulichkeitsvereinbarung vor dem Gespräch
- Rückmeldung innerhalb von 4 Geschäftsstunden
DevSecOps-Beispiele aus der Praxis
Anhand beispielhafter Szenarien zeigen wir wie Sicherheitskontrollen in der Delivery-Pipeline funktionieren.
Sichere Delivery-Pipeline
Scans auf Secrets, Code, Abhängigkeiten und die laufende Anwendung sind reguläre Schritte der Pipeline. Befunde sehen Entwickler direkt im Merge Request.
Secret-Scan
Bevor Code ins Repository gelangt, wird er auf offengelegte Passwörter, Schlüssel und Tokens geprüft.
- $ gitleaks git --staged -v
- ✓ no leaks found
Statische Codeanalyse (SAST)
Der Code wird auf Fehlermuster wie SQL-Injection und unsichere Konfiguration geprüft.
- $ semgrep scan --config p/owasp-top-ten
- Ran 512 rules on 284 files: 1 finding.
- ! tainted-sql-string · orders/views.py:88
Abhängigkeitsanalyse (SCA)
Open-Source-Komponenten werden mit Datenbanken bekannter Schwachstellen abgeglichen.
- $ grype dir:. --fail-on high
- jackson-databind 2.13.2 → 2.13.4.1 High CVE-2022-42003
Quality Gate
Solange Befunde hoher Schwere offen sind, wird nichts gemergt; die Korrektur wird im selben Merge Request verifiziert.
- ! Quality Gate: FAILED
- → fix commit pushed
- ✓ Quality Gate: PASSED
Dynamische Tests (DAST)
Nach dem Deployment in die Testumgebung wird die laufende Anwendung von außen gescannt.
- $ zap-baseline.py -t https://staging.example.local
- FAIL-NEW: 0 WARN-NEW: 2 PASS: 61
- Gitleaks
- Semgrep
- Grype
- SonarQube
- ZAP
Auswirkungsanalyse von Schwachstellen mit SBOM
Ein SBOM ist ein Komponenteninventar; für sich allein sagt es nicht, dass ein Release sicher ist. Sein Nutzen: Wird eine neue Schwachstelle bekannt, lassen sich die betroffenen Anwendungen sofort finden.
Komponenteninventar
Bei jedem Release wird automatisch eine Liste der Pakete und Versionen im Image erstellt (SBOM).
- $ syft registry.example.local/orders:3.2.0 -o cyclonedx-json > sbom.json
- ✓ Cataloged contents: 412 packages
Zentrales Inventar
SBOMs werden auf einer Plattform gesammelt; so lässt sich abfragen, welche Anwendung welche Komponentenversion nutzt.
- PUT /api/v1/bom · orders 3.2.0
- ✓ 412 components processed
Neue Schwachstelle gemeldet
Wird für eine Komponente eine kritische Schwachstelle veröffentlicht, listet das Inventar die betroffenen Projekte auf.
- ! CVE-2021-44228 · log4j-core · CVSS 10.0
- affected: orders 3.2.0 (log4j-core 2.14.1)
- not affected: payments-api, inventory-service
Behebung
Die Komponente wird auf eine sichere Version aktualisiert, die Pipeline läuft erneut und ein neues SBOM entsteht.
- log4j-core 2.14.1 → 2.17.1
- ✓ orders 3.2.1 built, scan clean
Abschluss
Das SBOM des neuen Release wird ins Inventar hochgeladen; der Schwachstelleneintrag wird geschlossen und der Vorgang in einem Bericht festgehalten.
- orders 3.2.1 · log4j-core 2.17.1
- ✓ CVE-2021-44228 closed
- Syft
- CycloneDX
- Dependency-Track
Image-Signierung und Prüfung beim Deployment
Eine Signatur zeigt nicht, dass ein Image sicher ist, sondern dass es aus der erwarteten Pipeline stammt und seitdem nicht verändert wurde. Der Cluster führt kein Image aus, ohne dessen Signatur zu prüfen.
Build-Nachweis
Das Image wird in der Pipeline gebaut; aus welchem Code und in welcher Umgebung es entstanden ist, wird festgehalten (Provenance).
- $ docker buildx build --provenance=true --push -t registry.example.local/payments-api:1.9.0 .
Signierung
Das Image erhält eine schlüssellose Signatur, die an die Identität der Pipeline gebunden ist; die Signatur liegt neben dem Image in der Registry.
- $ cosign sign --yes registry.example.local/payments-api@sha256:9f2c…
- tlog entry created with index: 1048…
- ✓ Pushing signature to: registry.example.local/payments-api
SBOM-Attestierung
Das SBOM wird dem Image als signierte Attestierung (Attestation) beigefügt.
- $ cosign attest --yes --type cyclonedx --predicate sbom.json registry.example.local/payments-api@sha256:9f2c…
Prüfung beim Deployment
Nur Images, die mit der erwarteten Identität signiert sind, werden zugelassen; die Regel greift am Eingang des Clusters.
- verifyImages: registry.example.local/*
- ✓ payments-api@sha256:9f2c… signature verified
Nicht signiertes Image
Ein nicht signiertes oder mit einer anderen Identität signiertes Image wird nicht in den Cluster aufgenommen; der Grund wird protokolliert.
- $ kubectl apply -f test-pod.yaml
- ! admission webhook "mutate.kyverno.svc-fail" denied the request: failed to verify image
- Docker Buildx
- Cosign (Sigstore)
- Kyverno
- SLSA
Secrets-Management
Secrets sind vertrauliche Zugangsdaten wie Passwörter, API-Schlüssel und Zertifikate. Sie liegen nicht im Code oder in Konfigurationsdateien, sondern in einem Secrets-Vault mit protokolliertem Zugriff.
Erkennung
Offen liegende Secrets in Repositories und Konfigurationsdateien werden gefunden und aufgelistet.
- $ gitleaks git --report-path report.json
- ! leaks found: 3
Umzug in den Vault
Secrets werden in einen zentralen Vault übernommen; der Zugriff wird nach Anwendungsidentität und dem Prinzip der minimalen Rechte festgelegt.
- $ vault kv put secret/payments-api/prod db_host=…
- ✓ Success! Data written to: secret/payments-api/prod
Kurzlebige Zugangsdaten
Die Anwendung erhält einen eigenen, kurzlebigen Datenbankbenutzer; läuft seine Gültigkeit ab, wird der Benutzer gelöscht.
- $ vault read database/creds/payments-api
- lease_duration 1h
- username v-k8s-payments-api-7Hq2…
Rotation
Schlüssel, die langfristig bestehen bleiben müssen, werden nach Zeitplan automatisch erneuert.
- rotation_period: 720h
- ✓ last rotation: 3 days ago
Audit-Log
Das Audit-Log hält fest, welche Identität wann welches Secret gelesen hat.
- $ vault audit list
- file/ file n/a
- Gitleaks
- HashiCorp Vault
- Kubernetes