Dieser Artikel wurde mitverfasst von Mikey Strauss sowie Viktor Kartaschow.
Verwandeln Sie die OWASP Top 10-Risiken in automatisierte, überprüfbare Kontrollen
In modernen DevOps-Umgebungen bilden CI/CD-Pipelines das Rückgrat der Softwarebereitstellung. Doch mit hoher Geschwindigkeit geht auch eine hohe Gefährdung einher. Da Unternehmen Releases beschleunigen, zielen Angreifer zunehmend auf unsichere Pipelines ab, um Schadcode einzuschleusen, Geheimnisse abzugreifen oder die Integrität der Lieferkette zu gefährden.
Um dieses Problem zu lösen, hebt das OWASP Top 10 CI/CD-Sicherheitsrisiko-Framework die häufigsten und kritischsten Schwachstellen in Entwicklungspipelines hervor. Scribe-SicherheitWir haben dieses Framework übernommen, um Unternehmen dabei zu helfen, CI/CD-Sicherheit durch signierte Beweise, initiativenbasierte Durchsetzung und Policy-as-Code direkt in ihre Arbeitsabläufe einzubetten.
Warum die OWASP CI/CD-Risiken wichtig sind
Herkömmliche Sicherheitstools können mit der Geschwindigkeit moderner Pipelines kaum Schritt halten. Ohne automatisierte Durchsetzung und Transparenz werden häufige Probleme übersehen:
❌ Fest codierte Geheimnisse in Pipeline-Konfigurationen
❌ Manipulierte Build-Artefakte ohne Herkunft
❌ Unsichere Basisbilder aus öffentlichen Registern gezogen
❌ Zugriff auf Administratorebene ohne 2FA oder Überprüfungskontrollen
Das OWASP-Framework formalisiert diese Risiken und bietet eine gemeinsame Sprache und Struktur für die Behebung. Bei Scribe nutzen wir es, um Initiativen zu definieren, die die Sicherheitslage Ihrer CI/CD-Pipelines automatisch überprüfen, ohne dass größere Änderungen an Ihrem Build-Prozess erforderlich sind.
Sicherheit beginnt mit signierten Beweisen
Um zu bestätigen, dass Ihre Pipeline sicher ist, sammeln und signieren wir Beweise wie:
- Git SBOM und Image SBOM
Generiert mit Scribe-Sicherheit/Aktionsbom, diese bieten vollständige Transparenz über den Inhalt Ihres Codes und Ihrer Container. - SLSA-Herkunft
Erfasst, wie, wo und von wem Ihre Artefakte erstellt wurden. - GitHub-Org- und Repo-Scans
Ausführen über Aktionsplattformen um nach Geheimnissen, Konfigurationsabweichungen und falsch konfiguriertem Zugriff zu suchen.
Alle diese Nachweise werden signiert, um Integrität und Rückverfolgbarkeit zu gewährleisten, und zur Lebenszyklusverfolgung bestimmten Produkten und Versionen zugeordnet.
📌 Wir haben dieses beweisbasierte Modell in unseren früheren Beiträgen behandelt. SLSA-Konformität sowie Durchsetzung von SP 800–190.
🔒 Durchsetzung von OWASP-Kontrollen über Policy-as-Code
Bei Scribe bilden wir die OWASP Top 10 CI/CD-Risiken in einer Policy-as-Code-Initiative die direkt in Ihrer CI-Pipeline ausgeführt wird. Jedes Risiko wird als konfigurierbare Regel dargestellt, die in einer lokalen owasp-top10-cicd.yaml Datei. Diese Regeln werden während der Überprüfungsphase automatisch ausgewertet und liefern umsetzbares Feedback und Anleitungen zur Problembehebung.
Hier sind einige der wichtigsten enthaltenen Steuerelemente:
- CICD-SEC-1 : Durchsetzen von Branch-Schutzregeln
Verhindern Sie nicht autorisierte Codeänderungen, indem Sie direkte Pushes auf kritische Zweige beschränken, wie Haupt-. - CICD-SEC-2 : Identitäts- und Zugriffsverwaltungskontrollen
Fordern Sie eine Multi-Faktor-Authentifizierung (MFA) an und beschränken Sie die Administratorrechte in Ihrem Git-Anbieter. - CICD-SEC-3 : Abhängigkeitsüberprüfung
Stellen Sie sicher, dass alle Basisimages und Abhängigkeiten von Drittanbietern aus genehmigten und vertrauenswürdigen Registern abgerufen werden. - CICD-SEC-4 : Verhinderung der Ausführung vergifteter Pipelines
Schränken Sie ein, wer CI/CD-Skripte ändern kann, um die Einführung bösartiger Logik in Ihre Arbeitsabläufe zu vermeiden. - CICD-SEC-6 : Durchsetzung der Anmeldeinformationshygiene
Suchen Sie nach fest codierten Geheimnissen, abgelaufenen Token oder durchgesickerten Anmeldeinformationen und kennzeichnen Sie diese vor der Veröffentlichung.
Jede dieser Kontrollen kann basierend auf der Risikotoleranz, der Umgebung oder den Compliance-Anforderungen Ihres Unternehmens angepasst werden. Da es als Code definiert ist, wird Ihre Sicherheitslage überprüfbar, versionskontrolliert und durch Automatisierung durchsetzbar.
✅ Profi-Tipp: Sie können bestimmte Regeln einschließen oder ausschließen, Schweregradschwellen festlegen und sogar individuelle Abhilfeempfehlungen geben – direkt in Ihrer Initiativenkonfigurationsdatei.
Indem Sie diese Kontrollen in Ihre Pipeline integrieren, gelangen Sie von Ad-hoc-Überprüfungen zu automatisierte, überprüfbare Sicherheitsdurchsetzung – ein entscheidender Schritt zum Schutz Ihrer Software-Lieferkette.
GitHub Actions: CI/CD-Integration in der Praxis
Hier ist ein Beispiel-Workflow, der die Aktionen von Scribe zum Erstellen, Sammeln von Beweisen, Scannen der Organisation und Überprüfen der Konformität mit dem OWASP Top 10 CI/CD-Framework verwendet:
Name: OWASP CI/CD Secure Build auf: Push: Zweige: – Hauptumgebung: PRODUKTNAME: meine App PRODUKTVERSION: v1.0 Jobs: Build: läuft auf: Ubuntu-Neueste Ausgaben: Imagename: ${{ steps.meta.outputs.image }} Schritte: – verwendet: actions/checkout@v4 – verwendet: docker/setup-buildx-action@v3 – ausführen: echo „${{ secrets.REGISTRY_PASSWORD }}“ | Docker-Login ${{ secrets.REGISTRY_URL }} -u ${{ secrets.REGISTRY_USER }} --password-stdin – ID: Meta verwendet: docker/build-push-action@v5 mit: Kontext: . push: true tags: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} - verwendet: scribe-security/action-bom@master mit: Ziel: „git:.“ Produktschlüssel: ${{ env.PRODUCT_NAME }} Produktversion: ${{ env.PRODUCT_VERSION }} Format: Attest – verwendet: scribe-security/action-bom@master mit: Ziel: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} Basis-Image: Dockerfile Produktschlüssel: ${{ env.PRODUCT_NAME }} Produktversion: ${{ env.PRODUCT_VERSION }} Format: Attest – verwendet: scribe-security/action-verify@master mit: Ziel: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} Produktschlüssel: ${{ env.PRODUCT_NAME }} Produktversion: ${{ env.PRODUCT_VERSION }} Initiative: slsa.l2@v2 Herkunft: true Format: Attest Verschönerung: true Org-Scan: läuft auf: Ubuntu-Latest-Schritte: - verwendet: Scribe-Security/Action-Platforms@Master mit: Befehl: Plattform entdecken: Github-Signatur: true Attest-Standard: Sigstore-Argumente: >- --Token ${{ secrets.GITHUB_PAT }} --Organization.Mapping ${{ github.repository_owner }}::${{ env.PRODUCT_NAME }}::${{ env.PRODUCT_VERSION }} --Repository.Mapping $(Basisname ${{ github.repository }})::${{ env.PRODUCT_NAME }}::${{ env.PRODUCT_VERSION }} --Scope.Workflow.Past_Days 1 --Scope.Branch ${{ github.ref_name }} --Hook trivy_iac_and_secrets_sarif Überprüfen: Läuft auf: Ubuntu-Latest benötigt: [Build, Org-Scan] Schritte: - verwendet: scribe-security/action-verify@master mit: Initiative: owasp-top10-cicd.yaml Produktschlüssel: ${{ env.PRODUCT_NAME }} Produktversion: ${{ env.PRODUCT_VERSION }} Format: alle Beweise bestätigen: wahr Verschönern: wahr
Kontinuierliche Compliance in Aktion
Das Ergebnis dieses Workflows ist eine überprüfbare Bestätigung, die zeigt, welche OWASP-Risiken Ihre Pipeline erfüllt oder nicht erfüllt. Jeder Verstoß lässt sich anhand spezifischer Beweise (SBOMs, Workflow-Protokolle und Organisationskonfigurationen) nachvollziehen, sodass Teams Probleme schnell und zuverlässig beheben können.
Möchten Sie sehen, wie das in der Praxis aussieht? Hier ist ein Beispiel für ein Scan-Ergebnis aus einer unserer internen Pipelines:
Übersichtsansicht
Verstoßansicht
Beweisansicht
Diese Inhalte werden Ihnen von Scribe Security zur Verfügung gestellt, einem führenden Anbieter von End-to-End-Sicherheitslösungen für die Software-Lieferkette, der modernste Sicherheit für Code-Artefakte sowie Code-Entwicklungs- und Bereitstellungsprozesse in der gesamten Software-Lieferkette bietet. Weitere Informationen.
Ähnliche Artikel
