1. Hinweis
Willkommen beim praktischen Codelab CI/CD-Pipeline mit CodeMender sichern.
In der modernen Softwarebereitstellung sind statische Analysetools (wie CodeQL) unerlässlich, um bekannte syntaktische Muster zu erkennen. Sie übersehen jedoch oft nuancierte Sicherheitslücken, die tief in der Geschäftslogik verborgen sind, und generieren ungenaue, nicht verifizierte Benachrichtigungen.
CodeMender (ausführbare CLI-Datei: cm) verbessert Ihre CI/CD-Pipeline und arbeitet mit vorhandenen SAST-Tools zusammen. Dazu werden die auf Gemini basierenden Sicherheits-Reasoning-Agents von Google für Folgendes eingesetzt:
Komplexe Fehler in der Geschäftslogik aufdecken: Anwendungskontext und Architekturdatenflüsse über starre statische Musterregeln hinaus analysieren.
Drastische Reduzierung von Fehlalarmen durch Self-Exploit-Verifizierung: Die Ausnutzbarkeit wird dynamisch in Sandbox-Umgebungen nachgewiesen, bevor Entwickler benachrichtigt werden.
Verifizierte Ergebnisse autonom beheben: Code-Patches synthetisieren, anhand von Test-Suites validieren, um Regressionen zu verhindern, und Pull-Anfragen zur Überprüfung einreichen.
In diesem Codelab binden Sie CodeMender mithilfe von GitHub Actions und der schlüssellosen Google Cloud Workload Identity Federation (WIF) in das OWASP Juice Shop-Repository ein.
Voraussetzungen
- Empfohlen: Grundkenntnisse der CodeMender-Konzepte (werden in Anwendung mit CodeMender sichern behandelt)
- Grundlegendes Verständnis von GitHub Actions-Workflows, Triggern und YAML-Syntax
- Grundlegende Kenntnisse von Git-Befehlen und Workflows zur Überprüfung von Pull-Anfragen
- Grundkenntnisse der Google Cloud IAM-Konzepte (Dienstkonten, Rollen und APIs)
- Vertrautheit mit gängigen Sicherheitslücken in Webanwendungen (z. B. SQL-Injection und XSS)
Lerninhalte
- Schlüssellose Zero-Trust-Authentifizierung zwischen GitHub Actions und Google Cloud über Workload Identity-Föderation (WIF) konfigurieren
- Automatisierten Workflow zum Scannen auf Sicherheitslücken mit CodeMender und
gemini-3.8-flasherstellen - Veröffentlichen von umsetzbaren Sicherheitsberichten mit OASIS SARIF v2.1.0 und nativen GitHub Actions-Jobzusammenfassungen
- Workflow für die autonome Problembehebung erstellen, der testgeprüfte Code-Patches generiert und Pull-Anfragen für die manuelle Überprüfung öffnet
- Automatisierte Qualitätssicherung (
--fail-on) und Pipeline-Caching für schnelle, kontinuierliche Sicherheit erzwingen
Voraussetzungen
- Ein Google Cloud-Projekt mit aktivierter Abrechnung und Berechtigungen als Project Owner/Editor
- Ein GitHub-Konto mit Berechtigungen zum Erstellen von Repositories, Konfigurieren von Secrets und Verwalten von Actions (Sie forken das OWASP Juice Shop GitHub-Repository in Schritt 3 mit der GitHub-Befehlszeile).
2. CodeMender-CI/CD-Architektur
In modernen DevSecOps-Umgebungen von Unternehmen kann KI-gestützte Sicherheit nicht nur ein manuelles Desktop-Tool sein. Es muss als automatisierter Gatekeeper (Blockieren unsicherer Pull-Anfragen) und als autonomer Co-Entwickler (Vorschlagen verifizierter Patches direkt in Git) fungieren.
Dazu implementieren Sie eine Dual-Workflow-Architektur, die auf der Workload Identity-Föderation (WIF) von Google Cloud und Gemini Enterprise-Reasoning-Modellen basiert.
Die Dual-Workflow-Architektur
Anstatt Erkennung und Behebung in einem einzigen monolithischen Script zusammenzufassen, werden die Sicherheitsmaßnahmen in der Pipeline in zwei entkoppelte, zweckbestimmte Workflows aufgeteilt:
Workflow | Primärer Trigger | Hauptverantwortung | Qualitäts-Hard-Gate |
1. Vulnerability Scanner( | Pull-Anfragen, Main-Pushes, wöchentlicher Cron, manueller Versand | • Führt schnelle differenzielle AST-Scans für PRs (~15 Sek.), schnelle Baseline-Scans für Push-Vorgänge ( | Blockiert die PR-Zusammenführung, wenn neu eingeführte Sicherheitslücken mit hohem oder kritischem Schweregrad erkannt werden ( |
2. Autonomous Remediator( | Manueller Trigger ( | • Setzt den Status aus Scan-Artefakten ( | Sorgt für saubere Produktionsunterschiede, bevor ein PR geöffnet wird |
Drei Kernprinzipien des Unternehmensdesigns
Beachten Sie beim Erstellen dieser Workflows in den folgenden Abschnitten die folgenden drei grundlegenden Architektursäulen:
🔑 Schlüssellose Zero-Trust-Authentifizierung und Preflight-Validierung:
In GitHub Secrets werden keine langlebigen JSON-Schlüssel für Google Cloud-Dienstkonten gespeichert. Der Runner generiert ein kurzlebiges OIDC-Token, das über Google Cloud STS gegen ein temporäres, einstündiges Token ausgetauscht wird, legt persist-credentials: false für Git-Checkouts fest und führt cm health --strict aus, um die Anmeldedaten, die Network Reachability und die IAM-Berechtigungen zu prüfen, bevor das Nutzungsmodellkontingent verbraucht wird.
⚡ Adaptives Scan-Routing und alte Geräuschunterdrückung:
Anstatt bei jedem Pull-Anfrage langsame Audits des gesamten Repositorys auszuführen, leitet CodeMender jedes CI-Ereignis an den optimalen Scanmodus weiter: Pull-Anfragen lösen eine differenzielle AST-Analyse (--diff="origin/$BASE_REF") für geänderte Dateien und 1-Hop-Aufrufer in weniger als 15 Sekunden aus. Bei Push-Vorgängen im Hauptzweig werden schnelle Baseline-Scans für eine einzelne Sitzung (--quick) ausgeführt. Bei wöchentlichen Zeitplänen werden gleichzeitige detaillierte Audits für jede Datei (Standard: cm find .) ausgeführt. Bereits vorhandene Sicherheitslücken in der Codebasis, die nicht von einem PR betroffen sind, werden mit [LEGACY / UNTOUCHED] gekennzeichnet. Sie werden in SARIF-Berichten angezeigt, blockieren aber nicht das PR-Merge-Gate und lösen keine automatische Fehlerbehebung aus.
🛡️ Robuste, nicht blockierende Sicherheitsbeobachtbarkeit:
Auch wenn --fail-on mit dem Code 1 beendet wird, um einen unsicheren PR zu blockieren, wird durch das Schützen der Schritte zum Exportieren des Berichts und zum Hochladen von SARIF mit steps.scan.outputs.completed == 'true' und hashFiles('results.sarif') != '' sichergestellt, dass OASIS-SARIF-Warnungen und Jobzusammenfassungen weiterhin veröffentlicht werden. Export und Upload werden sauber übersprungen, wenn eine Ausführung abgebrochen wird oder aufgrund eines Einrichtungs- oder Kapazitätsfehlers (10–60) abgebrochen wird.
3. Ziel-Repository in Cloud Shell authentifizieren und vorbereiten
Um die schlüssellose Authentifizierung einzurichten und automatisierte Sicherheitspipelines auszuführen, benötigen Sie ein zugängliches GitHub-Ziel-Repository, das Ihnen gehört. In diesem Codelab verwenden Sie OWASP Juice Shop, eine absichtlich anfällige Node.js-Webanwendung, als schlüsselfertige Sicherheitsumgebung.
Sie verwenden die GitHub CLI (gh), die in Google Cloud Shell vorinstalliert ist, um sich bei GitHub zu authentifizieren, Ihre Nutzerdetails automatisch zu erfassen und Ihr Repository in einem optimierten Ablauf vorzubereiten.
Schritt 1: Cloud Shell öffnen und GitHub CLI authentifizieren
Öffnen Sie die Google Cloud Console und aktivieren Sie Cloud Shell (Symbol >_ in der oberen Navigationsleiste).
Authentifizieren Sie die GitHub CLI (gh), um die Git-Anmeldedatenverwaltung zu konfigurieren:
gh auth login --hostname github.com --git-protocol https --web
Folge der Anleitung auf dem Bildschirm:
Kopieren Sie den achtstelligen Einmalcode, der in Cloud Shell ausgegeben wird (z.B. 1234-ABCD).
Drücken Sie die Eingabetaste, um https://github.com/login/device in Ihrem Browser zu öffnen.
Fügen Sie den Code ein und klicken Sie auf GitHub autorisieren.
Schritt 2: Variablen dynamisch exportieren und OWASP Juice Shop forken
Führen Sie die folgenden Befehle in Cloud Shell aus, um Ihren GitHub-Nutzernamen automatisch zu erfassen und das Repository vorzubereiten:
# 1. Automatically capture your GitHub username (customize GITHUB_REPO if desired)
export GITHUB_ORG=$(gh api user -q .login)
export GITHUB_REPO="${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_ORG:+${GITHUB_ORG}/${GITHUB_REPO}}"
echo "Authenticated as: ${GITHUB_REPOSITORY}"
# 2. Fork on GitHub server using GITHUB_REPO as the fork name
gh repo fork juice-shop/juice-shop --fork-name "${GITHUB_REPO}" --default-branch-only --clone=false 2>/dev/null || true
# 3. Shallow clone your fork (downloads only ~15 MB in 3-5 seconds, skipping heavy upstream git history)
[ -d ~/"${GITHUB_REPO}" ] || git clone --depth=1 "https://github.com/${GITHUB_REPOSITORY}.git" ~/"${GITHUB_REPO}" || \
(sleep 2 && git clone --depth=1 "https://github.com/${GITHUB_REPOSITORY}.git" ~/"${GITHUB_REPO}")
cd ~/"${GITHUB_REPO}"
# 4. Confirm you are in the repository directory
git status
4. Google Cloud Workload Identity-Föderation über gcloud konfigurieren
In diesem Schritt verwenden Sie die gcloud-Befehlszeile in Google Cloud Shell, um die erforderlichen APIs zu aktivieren, ein dediziertes CI/CD-Dienstkonto zu erstellen, den Workload Identity-Pool einzurichten und eine OIDC-Vertrauensstellung mit Ihrem GitHub-Repository (${GITHUB_REPOSITORY}) herzustellen.
Schritt 1: Google Cloud-Umgebungsvariablen festlegen
Erfassen Sie im Cloud Shell-Terminal (im geklonten Repository-Arbeitsbereich) Ihre aktive Google Cloud-Projekt-ID, prüfen Sie die Variable für das GitHub-Repository und definieren Sie die WIF-Ressourcennamen:
# Capture active Google Cloud Project ID and verify GitHub repository
export PROJECT_ID=$(gcloud config get-value project)
export GITHUB_USER=$(gh api user -q ".login")
export GITHUB_REPO="${GITHUB_REPO:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*/##; s#\.git$##')}"
export GITHUB_REPO="${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_USER:+${GITHUB_USER}/${GITHUB_REPO}}"
# Define WIF and Service Account resource names
export WORKLOAD_IDENTITY_POOL="codemender-github-pool"
export WORKLOAD_IDENTITY_PROVIDER="codemender-github-provider"
export SERVICE_ACCOUNT_NAME="codemender-ci-runner"
if [ -z "${PROJECT_ID}" ] || [ -z "${GITHUB_REPOSITORY}" ]; then
echo "ERROR: PROJECT_ID ('${PROJECT_ID}') or GITHUB_REPOSITORY ('${GITHUB_REPOSITORY}') is empty. Check 'gcloud config get-value project' and 'gh auth status'."
else
echo "Project ID: ${PROJECT_ID}"
echo "GitHub Repository: ${GITHUB_REPOSITORY}"
fi
Schritt 2: Erforderliche Google Cloud APIs aktivieren
Aktivieren Sie die IAM API, die Security Token Service API, die IAM Credentials API, die Agent Platform API und die Resource Manager API:
gcloud services enable \
iam.googleapis.com \
iamcredentials.googleapis.com \
sts.googleapis.com \
aiplatform.googleapis.com \
cloudresourcemanager.googleapis.com \
--project=${PROJECT_ID}
Schritt 3: Dediziertes CI/CD-Dienstkonto erstellen
Erstellen Sie ein Google Cloud-Dienstkonto mit den geringsten Berechtigungen, das für die Ausführung der CI/CD-Pipeline vorgesehen ist. Wenn es bereits vorhanden ist, können Sie es sicher wiederverwenden:
export SERVICE_ACCOUNT_EMAIL="${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"
gcloud iam service-accounts describe "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" >/dev/null 2>&1 || \
gcloud iam service-accounts create "${SERVICE_ACCOUNT_NAME}" \
--display-name="CodeMender CI/CD Pipeline Runner" \
--project="${PROJECT_ID}"
echo "Service Account Email: ${SERVICE_ACCOUNT_EMAIL}"
Schritt 4: IAM-Berechtigungen für die Agent Platform gewähren
Weisen Sie dem Dienstkonto die Rolle roles/aiplatform.user (Agent Platform User) zu, damit es mit der Gemini Enterprise Agent Platform kommunizieren kann:
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
--role="roles/aiplatform.user"
Schritt 5: Workload Identity-Pool erstellen
Erstellen Sie den Workload Identity-Pool, um GitHub Actions-Identitätsbestätigungen zu verwalten (oder stellen Sie ihn automatisch wieder her und aktivieren Sie ihn, wenn er bereits in Ihrem Projekt vorhanden ist):
POOL_STATE=$(gcloud iam workload-identity-pools list \
--location="global" \
--show-deleted \
--project="${PROJECT_ID}" \
--filter="name ~ /${WORKLOAD_IDENTITY_POOL}$" \
--format="value(state)")
if [ -z "${POOL_STATE}" ]; then
gcloud iam workload-identity-pools create "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--display-name="CodeMender GitHub Pool" \
--project="${PROJECT_ID}"
else
[ "${POOL_STATE}" = "DELETED" ] && gcloud iam workload-identity-pools undelete "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}"
gcloud iam workload-identity-pools update "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--no-disabled \
--project="${PROJECT_ID}"
fi
Schritt 6: Workload Identity-Anbieter mit GitHub OIDC erstellen
Erstellen (oder aktualisieren) Sie den OIDC-Anbieter im Pool, binden Sie die Aussteller-URL https://token.actions.githubusercontent.com und ordnen Sie GitHub-Token-Assertions Google STS-Attributen zu:
PROVIDER_STATE=$(gcloud iam workload-identity-pools providers list \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--show-deleted \
--project="${PROJECT_ID}" \
--filter="name ~ /${WORKLOAD_IDENTITY_PROVIDER}$" \
--format="value(state)")
if [ -z "${GITHUB_REPOSITORY}" ]; then
echo "ERROR: GITHUB_REPOSITORY is empty. Re-run Step 1 before configuring the OIDC provider."
elif [ -z "${PROVIDER_STATE}" ]; then
gcloud iam workload-identity-pools providers create-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--display-name="CodeMender GitHub Provider" \
--issuer-uri="https://token.actions.githubusercontent.com" \
--attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner" \
--attribute-condition="assertion.repository == '${GITHUB_REPOSITORY}'" \
--project="${PROJECT_ID}"
else
[ "${PROVIDER_STATE}" = "DELETED" ] && gcloud iam workload-identity-pools providers undelete "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}"
gcloud iam workload-identity-pools providers update-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--issuer-uri="https://token.actions.githubusercontent.com" \
--attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository,attribute.repository_owner=assertion.repository_owner" \
--attribute-condition="assertion.repository == '${GITHUB_REPOSITORY}'" \
--no-disabled \
--project="${PROJECT_ID}"
fi
Schritt 7: Dem GitHub-Repository erlauben, die Identität des Dienstkontos zu übernehmen
Binden Sie die Rolle roles/iam.workloadIdentityUser, damit Tokens aus Ihrem Repository die Identität des CI-Runner-Dienstkontos übernehmen können, und prüfen Sie die Richtlinienbindung:
# Retrieve the canonical Workload Identity Pool resource ID
export POOL_ID=$(gcloud iam workload-identity-pools describe "${WORKLOAD_IDENTITY_POOL}" \
--project="${PROJECT_ID}" \
--location="global" \
--format="value(name)")
if [ -z "${POOL_ID}" ] || [ -z "${GITHUB_REPOSITORY}" ]; then
echo "ERROR: POOL_ID ('${POOL_ID}') or GITHUB_REPOSITORY ('${GITHUB_REPOSITORY}') is empty. Re-run Step 1 and Step 5."
else
# Bind Workload Identity User role to the principalSet of your repository
gcloud iam service-accounts add-iam-policy-binding "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--role="roles/iam.workloadIdentityUser" \
--member="principalSet://iam.googleapis.com/${POOL_ID}/attribute.repository/${GITHUB_REPOSITORY}"
# Verify the principalSet binding on the Service Account
gcloud iam service-accounts get-iam-policy "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}"
fi
Schritt 8: Konfigurationswerte für GitHub-Secrets abrufen
Rufen Sie den vollständigen Ressourcennamen Ihres Workload Identity-Anbieters ab und speichern Sie ihn in einer Umgebungsvariablen für die automatische Registrierung im nächsten Schritt:
# Retrieve full Workload Identity Provider name
export WORKLOAD_PROVIDER_NAME=$(gcloud iam workload-identity-pools providers describe ${WORKLOAD_IDENTITY_PROVIDER} \
--workload-identity-pool=${WORKLOAD_IDENTITY_POOL} \
--location="global" \
--project=${PROJECT_ID} \
--format="value(name)")
echo "=========================================================="
echo "WIF CONFIGURATION READY:"
echo "=========================================================="
echo "GCP_WORKLOAD_IDENTITY_PROVIDER: ${WORKLOAD_PROVIDER_NAME}"
echo "GCP_SERVICE_ACCOUNT: ${SERVICE_ACCOUNT_EMAIL}"
echo "=========================================================="
5. GitHub-Repository-Secrets und Workflow-Berechtigungen konfigurieren
Nachdem Google Cloud WIF bereitgestellt wurde, konfigurieren Sie GitHub-Repository-Secrets und gewähren die erforderlichen Workflow-Berechtigungen für automatisierte Sicherheitsscans und Pull-Anfragen zur automatischen Fehlerbehebung.
Sie können diese Einstellungen direkt über Cloud Shell mit der GitHub CLI (gh) konfigurieren. So müssen Sie lange Ressourcennamen nicht manuell kopieren und einfügen.
Schritt 1: Repository-Secrets mit der GitHub-Befehlszeile festlegen
Führen Sie im Cloud Shell-Terminal die folgenden Befehle aus, um die beiden erforderlichen Repository-Secrets mithilfe der aktiven Umgebungsvariablen sicher festzulegen:
# 1. Set the Workload Identity Provider resource name
gh secret set GCP_WORKLOAD_IDENTITY_PROVIDER \
--body "${WORKLOAD_PROVIDER_NAME}" \
--repo "${GITHUB_REPOSITORY}"
# 2. Set the CI/CD Service Account email
gh secret set GCP_SERVICE_ACCOUNT \
--body "${SERVICE_ACCOUNT_EMAIL}" \
--repo "${GITHUB_REPOSITORY}"
# 3. Verify the secrets are registered
gh secret list --repo "${GITHUB_REPOSITORY}"
Schritt 2: Workflow-Berechtigungen für automatisierte PRs gewähren
Standardmäßig werden GitHub Actions-Workflows mit Leseberechtigungen ausgeführt und können keine Pull-Anfragen erstellen. In Schritt 9 generiert und sendet CodeMender automatisch verifizierte Pull-Anfragen zur Fehlerbehebung.
Gewähren Sie Schreibberechtigungen und aktivieren Sie die Erstellung von Pull-Anfragen direkt über die GitHub API:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
gh api \
--method PUT \
-H "Accept: application/vnd.github+json" \
/repos/${GITHUB_REPOSITORY}/actions/permissions/workflow \
-f default_workflow_permissions="write" \
-F can_approve_pull_request_reviews=true
Schritt 3: Geerbte Upstream-Workflows für Juice Shop deaktivieren
Beim Forken von OWASP Juice Shop werden 16 Upstream-CI-Workflows (z. B. PR Compliance Check, CI/CD Pipeline und CodeQL Scan) sowie eine Upstream-PR-Vorlage für Mitwirkende übernommen, die PRs für master automatisch schließt. Deaktivieren Sie alle Workflows, die nicht zu CodeMender gehören, über die GitHub CLI und entfernen Sie die Upstream-Dateien lokal, damit Ihr Fork nur CodeMender-Workflows ausführt:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
# 1. Disable all inherited non-CodeMender workflows in GitHub Actions (and CodeQL default setup if active)
for WF_ID in $(gh workflow list --all --limit 100 --repo "${GITHUB_REPOSITORY}" --json id,path \
-q '.[] | select((.path | startswith(".github/workflows/")) and (.path | test("codemender-") | not)) | .id'); do
gh workflow disable "${WF_ID}" --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
done
gh api -X PATCH "/repos/${GITHUB_REPOSITORY}/code-scanning/default-setup" \
-f state=not-configured >/dev/null 2>&1 || true
# 2. Remove upstream workflow files and PR template from the local workspace
for f in .github/workflows/*; do
case "$f" in *codemender-*) ;; *) rm -f "$f" ;; esac
done
rm -f .github/PULL_REQUEST_TEMPLATE.md
6. Workflow für automatisches Scannen auf Sicherheitslücken mit SARIF erstellen
In diesem Schritt erstellen Sie den primären Workflow für kontinuierliches Sicherheitsscannen (.github/workflows/codemender-scan.yml), der Baseline-Scans bei Branch-Pushes, differenzielle Gates bei Pull-Anfragen und SARIF-Exporte in GitHub Code Scanning ausführt.
Schritt 1: CodeMender-Scan-Workflow herunterladen
Laden Sie codemender-scan.yml aus dem Starter-Repository in .github/workflows/ herunter:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
mkdir -p .github/workflows
curl -fsSL https://raw.githubusercontent.com/edwardc-gcp/codemender-github-actions/main/.github/workflows/codemender-scan.yml \
-o .github/workflows/codemender-scan.yml
Schritt 2: Commit, Push und CI-Scanning auslösen
Übernehmen Sie die Workflow-Änderungen und übertragen Sie sie direkt in den primären Zweig Ihres Repositorys (master für Juice Shop oder main):
# Stage workflow changes, commit, and push to primary branch
git add -A .github
git commit -m "ci: add CodeMender SARIF security scanning workflow"
git push origin $(git branch --show-current)
In Ihrem Browser:
Rufen Sie Ihr geforktes GitHub-Repository auf: https://github.com/YOUR_GITHUB_USER/juice-shop (z.B. https://github.com/octocat/juice-shop).
Klicken Sie in der oberen Navigationsleiste auf den Tab Aktionen.
Wählen Sie in der linken Seitenleiste unter Workflows die Option CodeMender Security Scan & SARIF Export aus.
Workflowausführung auslösen oder ansehen:
Automatischer Trigger: Wenn eine automatische Ausführung aufgeführt ist, die durch Ihren Push ausgelöst wurde, klicken Sie direkt darauf, um die Live-Ausführung zu überwachen.
Manueller On-Demand-Trigger (workflow_dispatch): Wenn noch keine Ausführung gestartet wurde, klicken Sie rechts auf den Button Workflow ausführen ▾, achten Sie darauf, dass Branch: master ausgewählt ist (lassen Sie das Kästchen deep_scan deaktiviert, damit der schnelle Baseline-Scan --quick ausgeführt wird) und klicken Sie auf den grünen Button Workflow ausführen.
Klicken Sie auf die laufende Ausführung und wählen Sie Autonomous Code Vulnerability Scan aus, um den Workflow in Echtzeit zu verfolgen.
In codemender-scan.yml: Ereignisbasiertes Scan-Routing
Während der --quick-Baseline-Scan in der Cloud ausgeführt wird (ca. 3–5 Minuten), können Sie sich ansehen, wie codemender-scan.yml (Zeilen 118–155) jedes GitHub-Ereignis an den entsprechenden Scanmodus im Runner weiterleitet:
# Excerpt from .github/workflows/codemender-scan.yml
if [ "${{ github.event_name }}" = "pull_request" ]; then
cm find . \
--diff="origin/${{ github.base_ref }}" \
--diff-workers=16 \
--fail-on="CRITICAL,HIGH" \
--sandbox=false --yes --bypass-warning || status=$?
elif [ "${{ github.event_name }}" = "schedule" ] || [ "${{ github.event.inputs.deep_scan }}" = "true" ]; then
cm find . \
--deep-workers=8 \
--sandbox=false --yes --bypass-warning || status=$?
else
cm find . \
--quick \
--sandbox=false --yes --bypass-warning || status=$?
fi
Hardened Runner Setup ( Zeilen 27–117): Überspringt nicht vertrauenswürdige externe Forks und dependabot[bot]-PRs, führt einen Checkout mit persist-credentials: false durch, speichert ~/.local/bin/cm und ~/.codemender/state.db im Cache und führt cm health --strict aus, bevor das Modellkontingent verbraucht wird.
Headless Sandbox Boundaries (--sandbox=false --yes --bypass-warning): Deaktiviert die Linux-Nutzernamespace-Isolation (eingeschränkt in nicht privilegierten GitHub Actions-Containern), während die Workspace-Pfadgrenzen (project_paths) und command_policy.yaml erzwungen bleiben.
Exit-Code Guarded SARIF & Artifact Export ( Zeilen 147–194): Legt steps.scan.outputs.completed=true nur fest, wenn cm find mit 0 (sauber) oder 1 (--fail-on-Schwellenwert erreicht) beendet wird. So wird sichergestellt, dass SARIF-Berichte (cm report -f sarif mit CVSS-Schweregraden), $GITHUB_STEP_SUMMARY-Tabellen (cm report -f md) und codemender-findings.json-Artefakte auch dann veröffentlicht werden, wenn --fail-on einen PR blockiert. Gleichzeitig wird der Export bei Einrichtungs- oder Kapazitätsfehlern (10–60) übersprungen, damit leere SARIF-Dateien vorhandene Benachrichtigungen nicht schließen.
7. GitHub-Code-Scanning-Benachrichtigungen und Sicherheitsdashboard prüfen
Nachdem der Baseline-Push-Workflow abgeschlossen ist, verarbeitet GitHub die hochgeladene SARIF-Datei und füllt sowohl die Zusammenfassung der Aktionsausführung als auch den Tab „Sicherheit“ des Repositorys aus.
Schritt 1: Native Jobzusammenfassung in GitHub Actions prüfen
Bei jeder Workflowausführung wird direkt an die Übersicht der GitHub Actions-Ausführung eine Markdown-Zusammenfassungstabelle (cm report -f md) angehängt:
Klicken Sie in Ihrem GitHub-Repository auf den Tab Actions.
Wählen Sie den abgeschlossenen Lauf CodeMender Security Scan & SARIF Export aus. (Push-Audits für Baseline-Branches werden nach der Veröffentlichung von SARIF-Ergebnissen mit einem grünen Häkchen ✅ abgeschlossen.)
Scrollen Sie nach unten zum Abschnitt 🛡️ CodeMender Security Scan Summary, um sich die Aufschlüsselung der Ergebnisse anzusehen:
🔒 CodeMender-Sicherheitsbericht
Zusammenfassung
Ergebnisse insgesamt: 28
Schweregrad | Anzahl |
🔴 KRITISCH | 6 |
🟠 HOCH | 16 |
🟡 MITTEL | 6 |
Status | Anzahl |
🔴 OFFEN | 28 |
Ergebnisse
ID | Schweregrad | Konfidenz | Status | Korrigieren | Datei | Titel |
| 🔴 KRITISCH | 100 % | ÖFFNEN | – |
| Code-Ausführung per Fernzugriff über serverseitige Code-Injektion im Nutzerprofil |
| 🔴 KRITISCH | 100 % | ÖFFNEN | – |
| SQL-Injection in der Route für die Nutzerauthentifizierung |
| 🔴 KRITISCH | 100 % | ÖFFNEN | – |
| Remote Code Execution via Sandbox Escape in B2B Order Processing |
Schritt 2: Zentrales Dashboard für das Code-Scanning ansehen
Klicken Sie in der oberen Navigationsleiste Ihres GitHub-Repositorys auf den Tab Sicherheit und Qualität (oder Sicherheit).
Wählen Sie in der linken Seitenleiste unter Ergebnisse die Option Code-Scans aus.
Wenn mehrere Tools aktiv sind, filtern Sie Tool nach CodeMender (is:open branch:master tool:CodeMender), um die Warnungen zu prüfen, die mit nativen CVSS-Schweregrad-Badges verknüpft sind:
Schweregrad-Badge | Überschrift der Sicherheitslücke | Erkannter Standort | Branch |
🔴 Kritisch | Code-Ausführung per Fernzugriff über serverseitige Code-Injektion im Nutzerprofil |
|
|
🔴 Kritisch | SQL-Injection in der Route für die Nutzerauthentifizierung |
|
|
🔴 Kritisch | Remote Code Execution via Sandbox Escape in B2B Order Processing |
|
|
Klicken Sie auf SQL-Injection in der Route für die Nutzerauthentifizierung (routes/login.ts:34), um den von Gemini synthetisierten fehlerhaften Datenfluss und die Ursachenanalyse zu prüfen.
8. Unsichere Pull-Anfrage mit differenziellem Scannen blockieren
Bei Ihrem Baseline-Scan wurden 28 bereits vorhandene Sicherheitslücken in OWASP Juice Shop gefunden. Bei herkömmlichen statischen Analysetools würden diese 28 veralteten Ergebnisse jeden zukünftigen Pull-Anfrage blockieren, bis der gesamte Rückstand behoben ist. Das zwingt Teams dazu, die Blockierung von Zusammenführungen zu deaktivieren.
Jetzt testen Sie das PR Differential AST Gate (--diff + --fail-on="CRITICAL,HIGH") von CodeMender in Aktion: Sie öffnen eine Pull-Anfrage, die eine neue Sicherheitslücke einführt, und beobachten, wie CodeMender das Delta isoliert, den Merge in etwa 15–25 Sekunden blockiert und die genauen fehlerhaften Zeilen kommentiert.
Schritt 1: Pull-Anfrage mit einer Befehlsinjektions-Schwachstelle öffnen
Erstellen Sie in Cloud Shell (im geklonten Repository-Arbeitsbereich) einen Feature-Branch, fügen Sie eine neue Express-Route mit einer Sicherheitslücke für die Einschleusung von Betriebssystembefehlen hinzu und öffnen Sie eine Pull-Anfrage für Ihren Fork:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
PRIMARY_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's@^origin/@@')
# Reset any previous demo PR/branch so this step can be re-run cleanly
gh pr close feat/diagnostics --repo "${GITHUB_REPOSITORY}" --delete-branch 2>/dev/null || true
git checkout "${PRIMARY_BRANCH}"
git checkout -B feat/diagnostics
# Introduce an Express endpoint vulnerable to OS Command Injection (CWE-78)
cat << 'EOF' > routes/diagnostics.ts
import { execSync } from 'node:child_process'
import { type Request, type Response } from 'express'
export function systemDiagnostics () {
return (req: Request, res: Response) => {
const host = String(req.query.host ?? '127.0.0.1')
const output = execSync(`ping -c 1 ${host}`).toString()
res.status(200).json({ status: 'ok', output })
}
}
EOF
git add routes/diagnostics.ts
git commit -m "feat: add network diagnostics endpoint"
git push -f -u origin feat/diagnostics
gh pr create \
--repo "${GITHUB_REPOSITORY}" \
--base "${PRIMARY_BRANCH}" \
--head feat/diagnostics \
--title "feat: add network diagnostics endpoint" \
--body "Adds a ping diagnostics handler."
Schritt 2: Differential Merge Gate und Inline-PR-Anmerkung prüfen
Öffnen Sie die Pull-Anfrage-URL, die am Ende der Terminalausgabe angezeigt wird.
Scrollen Sie auf der Konversationsseite des Pull Requests nach unten zum Feld Prüfungen und beobachten Sie den Autonomous Code Vulnerability Scan:
Delta-Geschwindigkeit: Anstatt alle über 680 Dateien im Repository zu scannen (~3–5 Minuten), beschränkt cm find . --diff="origin/${PRIMARY_BRANCH}" die Analyse strikt auf routes/diagnostics.ts (und alle 1-Hop-Aufrufer). Der Scan ist in ~15–25 Sekunden abgeschlossen.
Isolierung von Altlasten und Blockieren von Merges: Keine der 28 unberührten Altlasten von Juice Shop führt zu einem Fehler bei der Prüfung. Nur die neu eingeführte CRITICAL-Befehlsinjektion löst --fail-on="CRITICAL,HIGH" aus und wird mit dem Statuscode 1 (rotes ❌) beendet, um den PR-Merge zu blockieren.
Klicken Sie oben in der Pull-Anfrage auf den Tab Files changed (Geänderte Dateien):
Da der Exit-Code-Guard (steps.scan.outputs.completed == 'true') des Workflows results.sarif weiterhin exportiert und hochlädt, wenn --fail-on mit dem Code 1 beendet wird, rendert GitHub Code Scanning eine Inline-Sicherheitsanmerkung CodeMender – Kritisch direkt unter execSync in routes/diagnostics.ts.
Schritt 3: Test-PR bereinigen und zum primären Zweig zurückkehren
Wechseln Sie mit Ihrem Cloud Shell-Arbeitsbereich zurück zum primären Branch und schließen Sie die unsichere Test-Pull-Anfrage, bevor Sie mit der autonomen Fehlerbehebung fortfahren:
[ -d .git ] || cd ~/"${GITHUB_REPO:-juice-shop}"
export GITHUB_REPOSITORY="${GITHUB_REPOSITORY:-$(git remote get-url origin 2>/dev/null | sed -E 's#^.*github\.com[:/]##; s#\.git$##')}"
PRIMARY_BRANCH=$(git symbolic-ref --short refs/remotes/origin/HEAD | sed 's@^origin/@@')
git checkout "${PRIMARY_BRANCH}"
gh pr close feat/diagnostics --repo "${GITHUB_REPOSITORY}" --delete-branch
git branch -D feat/diagnostics 2>/dev/null || true
9. Workflow für autonome Fehlerbehebung und automatische PR erstellen
Nachdem Sie mit dem Pull-Anfragen-Gate verhindert haben, dass neue Sicherheitslücken in die Codebasis gelangen, stellen Sie jetzt Autonomous Remediation (.github/workflows/codemender-remediate.yml) bereit, um vorhandene Sicherheitslücken aktiv zu beheben und Pull-Anfragen zu öffnen, die zur Überprüfung bereit sind.
Schritt 1: Datei für den Abhilfeworkflow herunterladen
CodeMender bietet zwei Vorlagen für die Fehlerbehebung, je nach Sichtbarkeit des Repositorys:
Öffentliche/Open-Source-Repositories (codemender-remediate.yml): Modus für verantwortungsbewusste Offenlegung – Links zu SARIF-Benachrichtigungen zum GitHub-Code-Scanning, ohne dass Roh-Exploit-Vektoren öffentlich zugänglich gemacht werden.
Private/Enterprise-Repositories (codemender-remediate-private-repo.yml): Modus für interne Auditnachweise – bettet Verifizierungsartefakte (PLAN.md, REPORT.md, exploit.sh) in minimierbare PR-Abschnitte ein, schließt sie aber von Git-Commits aus.
Laden Sie den Workflow zur öffentlichen Behebung in Ihr Repository herunter:
mkdir -p .github/workflows
curl -fsSL https://raw.githubusercontent.com/edwardc-gcp/codemender-github-actions/main/.github/workflows/codemender-remediate.yml \
-o .github/workflows/codemender-remediate.yml
Schritt 2: Autonomen Abhilfeworkflow committen und auslösen
Führen Sie einen Commit für den Abhilfeworkflow aus und übertragen Sie ihn per Push in Ihren primären Zweig:
git add .github/workflows/codemender-remediate.yml
git commit -m "ci: add CodeMender autonomous remediation workflow"
git push origin $(git branch --show-current)
Rufen Sie in Ihrem Browser den Tab Actions (Aktionen) Ihres GitHub-Repositorys auf.
Wählen Sie in der linken Seitenleiste unter Workflows die Option CodeMender Autonomous Security Remediation & Auto-PR aus.
Klicken Sie rechts auf das grüne Drop-down-Menü Workflow ausführen:
Workflow verwenden von: Achten Sie darauf, dass der Standardzweig (master) ausgewählt ist.
Spezifische Ergebnis-ID oder Präfix zur Behebung: Geben Sie das 8-stellige Präfix für routes/login.ts ein, das Sie in Schritt 7 notiert haben (z. B. cd47b38a). Wenn Sie dieses Feld leer lassen, wird die Batch-Behebung für alle offenen kritischen und hohen Ergebnisse ausgeführt (~10–15 Minuten). Wenn Sie eine einzelne ID angeben, dauert es ~45–60 Sekunden.
Klicken Sie im Pop-over auf den grünen Button Workflow ausführen und öffnen Sie die Ausführung.
In codemender-remediate.yml: Autonome Patch-Synthese
Während CodeMender den Patch in der Cloud synthetisiert (~30–45 Sekunden), können Sie sich ansehen, wie codemender-remediate.yml (Zeilen 111–184) die Behebung im Runner orchestriert:
Zero-Scan Resume (cm report import): Lädt das codemender-findings.json-Artefakt aus dem Scan-Workflow herunter und importiert es in den Arbeitsbereich (cm report import -f codemender-findings.json). Es wird nur dann auf cm find . --quick zurückgegriffen, wenn kein vorheriges Artefakt vorhanden ist.
Headless Patch Synthesis (cm fix): Pinnt project_paths an $GITHUB_WORKSPACE, leitet < /dev/null weiter, um interaktive Hänger zu verhindern, und übergibt --no-reset während Batch-Schleifen, damit kumulative Korrekturen über Ergebnisse hinweg erhalten bleiben:
# Executed inside the GitHub Actions runner (codemender-remediate.yml)
cm fix "${SPECIFIC_TARGET}" --sandbox=false --yes --bypass-warning < /dev/null
Clean Production Commits ( Zeilen 155–252): Löscht .cm_project, .exploit/ und temporäre Dateien über .git/info/exclude, bevor peter-evans/create-pull-request@v8 den Branch (codemender/auto-remediation-${{ github.run_id }}) öffnet und ausschließlich Änderungen am Produktionscode committet:
--- a/routes/login.ts
+++ b/routes/login.ts
@@ -28,8 +28,8 @@ module.exports = function login () {
- models.sequelize.query(`SELECT * FROM Users WHERE email = '${req.body.email || ''}' AND password = '${security.hash(req.body.password || '')}' AND deletedAt IS NULL`, { model: models.User })
+ models.sequelize.query('SELECT * FROM Users WHERE email = :email AND password = :password AND deletedAt IS NULL', {
+ replacements: { email: req.body.email || '', password: security.hash(req.body.password || '') },
+ model: models.User
+ })
Schritt 3: Neu geöffnete Pull-Anfrage auf GitHub prüfen
Rufen Sie in Ihrem Repository den Tab Pull requests auf und öffnen Sie die neue Pull-Anfrage (z.B. 🛡️ [CodeMender] Fix: SQL Injection in User Authentication Route).
Klicken Sie auf Geänderte Dateien, um zu bestätigen, dass nur routes/login.ts geändert wurde und alle internen Laufzeitmetadaten ausgeschlossen sind.
Sehen Sie sich die PR-Beschreibung an, die direkt mit der GitHub Code Scanning (SARIF)-Warnung für die Freigabe durch den Maintainer verknüpft ist.
10. Grenzfälle und private Repositories beheben
Private Repositories ohne GitHub Advanced Security (GHAS)
Öffentliche GitHub-Repositories erhalten kostenlose, unbegrenzte SARIF-Aufnahme für GitHub Code Scanning. Wenn Sie diesen Workflow jedoch in einem privaten Enterprise-Repository bereitstellen, das keine aktive GHAS-Lizenz (GitHub Advanced Security) hat, schlägt der Schritt upload-sarif mit folgendem Fehler fehl:
HTTP 403: Advanced Security must be enabled for this repository to use code scanning.
Lösung: Fallback für eigenständigen interaktiven HTML-Bericht
Der integrierte HTML-Berichtsgenerator von CodeMender (cm report -f html) erstellt ein eigenständiges, interaktives Sicherheits-Dashboard mit Karten für Schweregradmesswerte, Code-Snippets mit Syntaxhervorhebung und Zeilennummern sowie einem Inline-Patch-Diff-Viewer ohne externe Webabhängigkeiten.
Wenn Sie private Repositories ohne GHAS-Lizenz unterstützen möchten, aktualisieren Sie .github/workflows/codemender-scan.yml, um ein HTML-Berichtsartefakt zu archivieren, anstatt SARIF hochzuladen:
Eigenständigen HTML-Bericht generieren: Exportieren Sie im Schritt Export Security Reports & Publish Job Summary ein HTML-Dashboard zusammen mit Ihrer Markdown-Zusammenfassung mit cm report -f html > codemender-audit-report.html.
Bericht als Workflow-Artefakt archivieren: Ersetzen Sie den Schritt Upload SARIF Report to GitHub Code Scanning (github/codeql-action/upload-sarif@v4) durch actions/upload-artifact@v4, der so konfiguriert ist, dass codemender-audit-report.html hochgeladen wird (z. B. unter dem Artefaktnamen codemender-security-report).
Lokal in einem beliebigen Browser prüfen: Laden Sie codemender-security-report.zip direkt von der Zusammenfassungsseite des GitHub Actions-Workflow-Ausführung herunter, extrahieren Sie die Datei und öffnen Sie codemender-audit-report.html in einem beliebigen Webbrowser, um die Ergebnisse visuell zu sichten.
Autonome Behebung von Problemen in privaten Repositories mit eingebetteten Audit-Nachweisen
In privaten Unternehmens-Repositories benötigen Entwicklungs- und Sicherheitsteams vollständigen Einblick in die Ursachenanalyse, den Proof of Concept für Exploits und den Abhilfeplan, ohne dass externe Tool-Dashboards erforderlich sind. Wenn Sie jedoch Exploit-Skripts (exploit.sh) oder interne Markdown-Dateien (PLAN.md, LOG.md) in den Repository-Zweig übertragen, wird der Git-Verlauf verunreinigt und es können Fehlalarme von anderen Sicherheitsscannern ausgelöst werden.
Stellen Sie dazu den dedizierten Workflow zur Behebung von Problemen mit privaten Repositories (codemender-remediate-private-repo.yml) bereit:
curl -fsSL https://raw.githubusercontent.com/edwardc-gcp/codemender-github-actions/main/.github/workflows/codemender-remediate-private-repo.yml \
-o .github/workflows/codemender-remediate.yml
git add .github/workflows/codemender-remediate.yml
git commit -m "ci: switch to private repository remediation workflow with embedded audit evidence"
git push origin $(git branch --show-current)
Funktionsweise der Fehlerbehebung in privaten Repositories
Dynamische PoC-Überprüfung (cm verify): Synthetisiert und testet einen funktionierenden Exploit, bevor die Fehlerbehebung generiert wird, um die Ausnutzbarkeit zu bestätigen. cm fix wird automatisch übersprungen, wenn die Überprüfung ein nicht ausnutzbares Ergebnis als DISMISSED markiert.
Eingebettete PR-Audit-Klappmenüs: Extrahiert REPORT.md, PLAN.md und exploit.sh in /tmp/codemender-evidence/ und formatiert sie direkt in der Pull-Anfrage-Beschreibung in <details open>-Klappmenüs, damit Prüfer sie mit einem Klick einsehen können.
Artefaktarchivierung: Archiviert den gesamten Nachweisordner über actions/upload-artifact@v4.
Unberührte Git-Commits: Löscht alle Laufzeitmetadaten und .exploit-Verzeichnisse, sodass der Git-Commit der Pull-Anfrage nur Änderungen am Produktionscode enthält.
Checkliste zur Fehlerbehebung bei der Workload Identity-Föderation (WIF)
Standardmäßig schreibt google-github-actions/auth@v2 während der Einrichtung eine lokale Konfigurationsdatei für föderierte Anmeldedaten. Der eigentliche OAuth 2.0-Tokenaustausch erfolgt, wenn cm health --strict oder cm find gestartet wird. Verwenden Sie die folgende Checkliste, um HTTP 400- oder HTTP 403-Authentifizierungsfehler zu diagnostizieren:
Fehlersymptom | Häufige Ursache | Überprüfung und Korrektur |
HTTP 403 ( | Fehlende | Prüfen Sie, ob |
HTTP 400 ( | Der OIDC-Repository-Name (oder die Groß-/Kleinschreibung) von | Führen Sie Schritt 4 (Schritte 1 und 6) noch einmal aus. Achten Sie darauf, dass |
HTTP 400 ( | Fehlerhafte | Prüfen Sie, ob |
Vorübergehender HTTP 403-Fehler unmittelbar nach der Einrichtung | Die globale IAM- und Workload Identity-Föderationsweitergabe kann bei neu erstellten Bindungen 1–5 Minuten dauern. | Warten Sie 1–2 Minuten und klicken Sie dann in GitHub Actions auf Fehlgeschlagene Jobs noch einmal ausführen. |
Führen Sie den folgenden Befehl aus, um die Live-Workload Identity-Bindung für Ihr CI/CD-Dienstkonto in Cloud Shell zu prüfen:
gcloud iam service-accounts get-iam-policy "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--flatten="bindings[].members" \
--filter="bindings.role=roles/iam.workloadIdentityUser"
Prüfen Sie, ob in der Ausgabe roles/iam.workloadIdentityUser an principalSet://iam.googleapis.com/<POOL_ID>/attribute.repository/<GITHUB_USER>/<GITHUB_REPO> gebunden ist:
--- bindings: members: principalSet://iam.googleapis.com/.../attribute.repository/<OWNER>/<REPO> role: roles/iam.workloadIdentityUser
Fehlerbehebung bei CI/CD-Preflight- und CLI-Exit-Codes
CodeMender-Befehle (cm health --strict, cm find, cm verify und cm fix) geben deterministische Exitcodes zurück, sodass CI/CD-Pipelines Sicherheitsergebnisse sofort von Einrichtungs- oder Dienstfehlern unterscheiden können:
Exit-Code | Kategorie | Häufige Ursachen und Abhilfemaßnahmen |
| Erfolgreich | Systemdiagnosen bestanden oder Scan ohne blockierende Ergebnisse abgeschlossen. |
| Ergebnisse / Allgemein |
|
|
| WIF-OAuth/ADC-Tokenaustausch fehlgeschlagen ( |
|
| Fehlerhafte |
|
| Runner kann |
|
| Dem Dienstkonto fehlt |
|
| Die Preflight-Prüfung |
|
| Der Agent hat das Limit für gleichzeitige aktive Aufgaben erreicht. Führen Sie den Workflow nach einer kurzen Verzögerung noch einmal aus. |
Weitere Laufzeitfehler wie die Auflösung des Git-Diff-Basis-Branch (fetch-depth: 0), Verzögerungen bei der Ressourcenweitergabe oder Berechtigungen zum Erstellen von GitHub Actions-Pull-Anfragen finden Sie im offiziellen CodeMender-Leitfaden zur Fehlerbehebung für CI/CD.
11. Ressourcen bereinigen
Führen Sie die folgenden Bereinigungsschritte aus, um einen laufenden Ressourcenverbrauch zu verhindern oder Testkonfigurationen in Ihren Google Cloud- und GitHub-Umgebungen zu bereinigen.
Schritt 1: GitHub-Repository-Secrets entfernen und Workflows über die gh CLI deaktivieren
Verwenden Sie die GitHub CLI (gh), um die Aktions-Secrets des Repositorys sauber zu löschen und die CodeMender-Workflows zu deaktivieren:
# Delete the repository Actions secrets
gh secret delete GCP_WORKLOAD_IDENTITY_PROVIDER --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
gh secret delete GCP_SERVICE_ACCOUNT --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
# Disable the CodeMender workflows to prevent unwanted automatic triggers
gh workflow disable codemender-scan.yml --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
gh workflow disable codemender-remediate.yml --repo "${GITHUB_REPOSITORY}" 2>/dev/null || true
Schritt 2: Google Cloud Workload Identity-Föderationsressourcen deaktivieren oder löschen
Für Workload Identity-Pools, ‑Anbieter und ‑Dienstkonten fallen keine Kosten für Inaktivität an, wenn keine Tokens ausgetauscht werden. Wählen Sie den Bereinigungsmodus aus, der zu Ihrem Workflow passt:
Option A – Zugriff pausieren (empfohlen, wenn Sie die Ausführung in diesem Projekt noch einmal planen): Deaktiviert den OIDC-Tokenaustausch sofort, ohne die 30-tägige Aufbewahrungsfrist für das vorläufige Löschen von Google Cloud IAM oder die Verzögerungen bei der Weitergabe von Dienstkonten (uniqueId) auszulösen:
gcloud iam workload-identity-pools providers update-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--disabled \
--project="${PROJECT_ID}"
Option B – Vollständiger Abbau: Löscht den WIF-Anbieter, den Pool (wird 30 Tage lang im Status DELETED beibehalten) und das dedizierte Dienstkonto:
# Delete Workload Identity Provider
gcloud iam workload-identity-pools providers delete "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}" \
--quiet
# Delete Workload Identity Pool
gcloud iam workload-identity-pools delete "${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--project="${PROJECT_ID}" \
--quiet
# Delete CI/CD Service Account
gcloud iam service-accounts delete "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--quiet
12. Glückwunsch
Glückwunsch! Sie haben das Codelab CI/CD-Pipeline mit CodeMender sichern abgeschlossen.
Sie haben erfolgreich eine produktionsreife Zero-Trust-DevSecOps-Pipeline mit Google Cloud Workload Identity Federation, CodeMender und GitHub Actions entworfen, erstellt und automatisiert.
Was Sie gelernt haben
Schlüssellose Zero-Trust-Authentifizierung: Riskante, langlebige JSON-Schlüssel für Dienstkonten wurden eliminiert, indem kurzlebige GitHub-OIDC-Tokens über die Workload Identity-Föderation (WIF) an Google Cloud IAM gebunden wurden.
PR-differenzielles AST-Scanning und Geräuschunterdrückung von Legacy-Rauschen: Kontinuierliches Scannen, das auf geänderte Dateien und Abhängigkeiten (--diff="origin/$BASE_REF") beschränkt ist, wobei Legacy-technische Schulden ([LEGACY / UNTOUCHED]) isoliert werden, um die Feedback Loop für Entwickler unter 15 Sekunden zu halten.
Berichte in mehreren Formaten und native Jobzusammenfassungen: Kombiniertes OASIS SARIF v2.1.0 für zentralisiertes GitHub-Code-Scanning mit nativem Markdown (cm report -f md >> $GITHUB_STEP_SUMMARY) für sofortige Sichtbarkeit für Führungskräfte direkt auf den Seiten der CI-Workflow-Ausführung.
Autonome Behebung mit Human-in-the-Loop-Überprüfung: Wir sind von passiven Benachrichtigungen zu aktiven Behebungspipelines übergegangen, die autonom vorgeschlagene Code-Patches synthetisieren, anhand von Regressionstest-Suites verifizieren und Pull-Anfragen mit Audit-Artefakten zur Überprüfung durch Entwickler öffnen.
Automatisierte Qualitätssicherung: Es wurden strenge Branch-Schutzmaßnahmen und Merge-Gates (--fail-on) erzwungen, um zu verhindern, dass gefährliche Sicherheitslücken in die Produktion gelangen.
Artefaktgesteuerte Statusübertragung und Arbeitsbereichsisolierung: Ergebnisse wurden nahtlos zwischen CI-Jobs mit cm report import übertragen, während .git/info/exclude verwendet wurde, um den ursprünglichen Git-Verlauf beizubehalten und das Durchsickern von Anmeldedaten zu verhindern.
Umdenken bei Entwicklern
Traditionelle DevSecOps-Praxis | Autonome CI/CD-Pipeline von CodeMender |
Passive Alert Dumping: Scanner geben unformatierte Terminalprotokolle oder statische Fehlerlisten aus, sodass die Entwickler die gesamte Triage-Arbeit übernehmen müssen. | Aktiver Co-Developer: Synthetisiert verifizierte Code-Patches und öffnet Pull-Anfragen, die von Entwicklern genehmigt werden können. |
Hohe Anzahl falsch positiver Ergebnisse: Statische AST-Heuristiken melden Tausende theoretische Sicherheitslücken, ohne dass ein Nachweis der Ausnutzbarkeit vorliegt. | Zweistufige Exploit-Überprüfung: Durch die dynamische Generierung von Sandbox-Tests ( |
Risikoreiche Secret-Speicherung: Langlebige JSON-Schlüssel für Dienstkonten, die in CI-Secrets gespeichert sind, bergen das Risiko von versehentlichen Leaks und einer unkontrollierten Verbreitung von Anmeldedaten. | Zero-Trust-WIF: Schlüssellose Authentifizierung über kurzlebige OIDC-Tokens, die bei Bedarf mit Google Cloud STS ausgetauscht werden. |
Monolithische erneute Scans: Jeder Commit löst vollständige Repository-Audits aus, was CI-Workflows verzögert und teure Tokens verschwendet. | Ereignisbewusstes AST-Routing: Pull-Anfragen führen 15-sekündige differenzielle AST-Scans ( |
Verunreinigter Repository-Verlauf: Temporäre Exploit-Skripts und Angriffslogs, die direkt in Repository-Branches übertragen wurden. | Workspace-Hygiene für Unternehmen: Angriffsbelege werden sauber in PR-Beschreibungen und Workflow-Artefakte eingebettet, sodass Code-Commits unverändert bleiben. |
Weiteres Vorgehen
🚀 CodeMender-Lernpfad fortsetzen:
Teil 1: Anwendung mit CodeMender sichern – Lernen Sie, wie Sie Sicherheitslücken in Repositories autonom erkennen, PoC-Exploits verifizieren und lokale Patches erstellen.
Shift Left Locally & Serverless Cloud Native CI/CD: Sehen Sie sich die Referenzimplementierungen im offiziellen CI/CD-Leitfaden für Google Cloud Build (cloudbuild.yaml) und lokale Git-Pre-Commit-Hooks (cm find . --diff --staged) an.
📖 Dokumentation und Ressourcen ansehen:
Offizieller Leitfaden zur Integration von Google Cloud CodeMender in CI/CD
Offizielle Google Cloud CodeMender-Dokumentation
CodeMender GitHub Actions Starter Template Repository
Dokumentation zur Workload Identity-Föderation von Google Cloud
💡 Auf eigene Repositories anwenden:
Erstellen Sie einen Fork des Starter-Workflows und sichern Sie die Python-, Go-, Java-, Rust- und Node.js-Repositories Ihrer Organisation mit CodeMender.