Zum Inhalt springen

DevSecOps · CI/CD-Sicherheit

Sicherheitsprüfungen in jedem Build, mit Nachweis für das nächste Audit.

Schwachstellen und eingecheckte Zugangsdaten werden vor dem Release gefunden, und jeder Build hinterlässt einen Nachweis. Wir binden Code-, Secret-, Container- und IaC-Prüfungen in Ihre Pipeline in Azure DevOps oder GitHub ein.

Erstgespräch vereinbaren So läuft es ab

Beispiel eines Pull Requests: Secret Scanning, Abhängigkeiten, Code-Analyse sowie Container und IaC sind bestanden, die Freigabe ist erteilt. Der Stand ist bereit zum Deployment, der Nachweis ist gespeichert.

Kein Werkzeugwechsel
Ihre bestehende Pipeline
Nachweis je Build
Für Prüfer und Versicherer
GitHub und Azure DevOps
Beide Plattformen abgedeckt

Kennen Sie das?

Wo fehlt Sicherheit in der Entwicklung?

Code geht ungeprüft live

Schwachstellen und eingecheckte Secrets landen direkt in Produktion.

Abhängigkeiten ohne Überblick

Bibliotheken und Images mit bekannten Lücken bleiben unbemerkt.

Prüfer fragen nach Nachweisen

Dokumentierte Security-Prozesse für die Entwicklung fehlen bisher.

Prüfpunkte

Wo stoppt die Pipeline einen Befund?

Jede Änderung durchläuft dieselben Prüfpunkte, in GitHub wie in Azure DevOps. Wählen Sie ein Beispiel und sehen Sie, wo ein Befund den Commit anhält.

Beispiel wählen
Plattform wählen

  1. Commit

    Push in einen Pull Request

  2. 1 Secrets

    Secret Scanning mit Push-SchutzSecret Scanning mit Push-Schutz

    bestanden Befund nicht erreicht

  3. 2 Abhängigkeiten

    Dependabot und Dependency ReviewDependency Scanning

    bestanden Befund nicht erreicht

  4. 3 Code

    Code Scanning mit CodeQLCode Scanning mit CodeQL

    bestanden Befund nicht erreicht

  5. 4 Container und IaC

    Microsoft Security DevOpsMicrosoft Security DevOps

    bestanden Befund nicht erreicht

  6. 5 Freigabe

    Branch-Schutz und EnvironmentsBranch Policies und Approvals

    bestanden Befund nicht erreicht

  7. Deployment

    Workflow-Protokoll und SBOM als NachweisPipeline-Protokoll und SBOM als Nachweis

    ausgerollt nicht erreicht

Freigegeben und ausgerollt

Alle Prüfungen bestanden. Protokoll, SBOM und Freigabe bleiben am Build gespeichert.

Push abgewiesen

Der Push-Schutz erkennt den Zugangsschlüssel, bevor er ins Repository gelangt. Er wird entfernt und in Azure Key Vault abgelegt.

Merge blockiert

Der Terraform-Code würde einen Speicher öffentlich erreichbar machen. Der Befund steht im Pull Request, bis er behoben ist.

Ein Commit durchläuft fünf Prüfpunkte: Secrets mit Secret Scanning und Push-Schutz, Abhängigkeiten mit Dependabot und Dependency Review in GitHub oder Dependency Scanning in Azure DevOps, Code mit CodeQL, Container und IaC mit Microsoft Security DevOps, Freigabe über Branch-Schutz und Environments in GitHub oder Branch Policies und Approvals in Azure DevOps. Ohne Befund wird ausgerollt, Protokoll und SBOM bleiben als Nachweis. Ein Zugangsschlüssel im Code wird schon beim Push abgewiesen. Ein öffentlich erreichbarer Speicher im Terraform-Code stoppt den Commit bei Container und IaC, der Merge ist blockiert.

Was wir in Ihre Pipeline einbauen

Code-Analyse

CodeQL, Secret Scanning mit Push-Schutz und Dependabot über GitHub Advanced Security.

Container und AKS

Defender for Containers scannt Images, nur signierte Artefakte werden deployed.

Infrastruktur als Code

Microsoft Security DevOps prüft Terraform und Bicep, Azure Policy setzt durch.

SBOM je Build

Das SBOM-Tool von Microsoft erzeugt je Build ein Inventar (SPDX).

Teams schulen

Secure Coding Workshops, Threat Modeling und Security Champions.

Nachweise für Prüfer

Prüfungen zugeordnet zu NIS2 Art. 21 Abs. 2 d und e sowie ISO 27001.

Wie läuft die Einführung ab?

  1. 2 bis 4 Wochen

    Pipeline Assessment

    Bestandsaufnahme, Lücken und priorisierte Roadmap.

  2. 2 bis 4 Monate

    Security-Integration

    GitHub Advanced Security und Microsoft Security DevOps einbinden.

  3. 1 bis 3 Monate

    Policy und Governance

    Policy as Code, Admission Control für AKS, Prüferdokumentation.

  4. 1 bis 2 Monate, danach laufend

    Schulung und Betrieb

    Workshops, Security Champions, Runbook für Befunde.

Wie sicher ist Ihre Pipeline?

Wir klären, wo die größten Lücken liegen.

Erstgespräch vereinbaren

Was ändert sich für Ihr Team?

Ohne DevSecOps

  • Schwachstellen fallen erst in Produktion auf
  • Kein Überblick über Abhängigkeiten
  • Images aus unkontrollierten Quellen
  • Security-Reviews blockieren Releases am Ende

Mit DevSecOps

  • Jeder Commit automatisch geprüft
  • Abhängigkeiten laufend überwacht, SBOM je Build
  • Nur geprüfte, signierte Images im Deployment
  • Befunde direkt im Pull Request

Häufig gestellte Fragen

Was ist eine SBOM und wofür brauchen wir sie?

Eine Software Bill of Materials listet alle Komponenten eines Softwarestands. Damit beantworten Sie nach einer neuen Schwachstelle belegbar, ob Sie betroffen sind. NIS2 schreibt sie nicht vor, verlangt aber Sicherheit in der Lieferkette.

Bremsen Sicherheitsprüfungen unsere Releases?

Nur wenn sie falsch eingebunden sind. Schnelle Prüfungen laufen bei jedem Commit, aufwendige nachts oder vor dem Release, und blockiert wird nur oberhalb vereinbarter Schwellenwerte.

Wie verhindern wir, dass Zugangsdaten im Quellcode landen?

Secret Scanning mit Push-Schutz weist Commits mit erkannten Schlüsseln ab. Pipelines melden sich über Workload Identity Federation oder Managed Identities an. Ein eingechecktes Secret gilt als kompromittiert und wird rotiert.

Wie weisen wir einem Prüfer nach, dass unsere Softwareentwicklung sicher ist?

Mit Pipeline-Protokollen je Build, Security-Gates mit dokumentierten Schwellenwerten und einer SBOM je Release, jeweils den Anforderungen aus NIS2 oder ISO 27001 zugeordnet.

Wo steht Ihre Softwareentwicklung?

Erstgespräch vereinbaren