1. Prima di iniziare
Ti diamo il benvenuto nel codelab pratico per proteggere la tua pipeline CI/CD con CodeMender.
Nella distribuzione di software moderna, gli strumenti di analisi statica (come CodeQL) sono essenziali per individuare pattern sintattici noti, ma spesso non rilevano vulnerabilità sfumate nascoste nella logica di business e generano avvisi rumorosi e non verificati.
CodeMender (eseguibile CLI: cm) migliora la tua pipeline CI/CD, operando insieme agli strumenti SAST esistenti, implementando gli agenti di ragionamento di sicurezza basati su Gemini di Google per:
Scopri i difetti della logica di business complessa: ragiona sul contesto dell'applicazione e sui flussi di dati dell'architettura oltre alle rigide regole dei pattern statici.
Riduci drasticamente i falsi positivi tramite la verifica dell'auto-exploit: dimostra dinamicamente la possibilità di exploit in ambienti sandbox prima di avvisare gli sviluppatori.
Correggi autonomamente i risultati verificati: sintetizza le patch di codice, convalida rispetto alle suite di test per evitare regressioni e invia richieste di pull pronte per la revisione.
In questo codelab, integrerai CodeMender nel repository OWASP Juice Shop utilizzando GitHub Actions e la federazione delle identità per i carichi di lavoro (WIF) di Google Cloud senza chiavi.
Prerequisiti
- Consigliato: familiarità di base con i concetti di CodeMender (trattati in Proteggi la tua applicazione con CodeMender)
- Conoscenza di base dei flussi di lavoro, dei trigger e della sintassi YAML di GitHub Actions
- Conoscenza di base dei comandi Git e dei flussi di lavoro di revisione delle richieste di pull
- Conoscenza di base dei concetti di Google Cloud IAM (service account, ruoli e API)
- Familiarità con le vulnerabilità più comuni delle applicazioni web (come SQL injection e XSS)
Cosa imparerai a fare
- Come configurare l'autenticazione keyless zero trust tra GitHub Actions e Google Cloud tramite la federazione delle identità per i carichi di lavoro (WIF)
- Come creare un workflow di analisi delle vulnerabilità automatizzato utilizzando CodeMender e
gemini-3.8-flash - Come pubblicare report sulla sicurezza utili utilizzando OASIS SARIF v2.1.0 e i riepiloghi dei job di GitHub Actions nativi
- Come creare un workflow di correzione autonomo che genera patch di codice verificate dai test e apre richieste di pull per la revisione umana
- Come applicare controlli di qualità automatizzati (
--fail-on) e la memorizzazione nella cache della pipeline per una sicurezza continua ad alta velocità
Che cosa ti serve
- Un progetto Google Cloud con la fatturazione abilitata e le autorizzazioni di Project Owner/Editor
- Un account GitHub con autorizzazioni per creare repository, configurare secret e gestire azioni (nel passaggio 3, crei un fork del repository GitHub OWASP Juice Shop utilizzando l'interfaccia a riga di comando di GitHub).
2. Comprendi l'architettura CI/CD di CodeMender
Nel DevSecOps aziendale moderno, la sicurezza basata sull'AI non può essere semplicemente uno strumento desktop manuale. Deve funzionare come un gatekeeper automatizzato (bloccando le richieste di pull non sicure) e come un co-sviluppatore autonomo (proponendo patch verificate direttamente in Git).
Per farlo, implementerai un'architettura a doppio workflow basata sulla federazione delle identità per i workload (WIF) di Google Cloud e sui modelli di ragionamento di Gemini Enterprise.
Architettura a doppio workflow
Anziché inserire il rilevamento e la correzione in un unico script monolitico, la pipeline suddivide la sicurezza in due workflow disaccoppiati e dedicati:
Workflow | Trigger principale | Responsabilità principale | Quality Hard Gate |
1. Scanner di vulnerabilità( | Richieste di pull, push principali, cron settimanale, invio manuale | • Esegue scansioni AST differenziali rapide sulle PR (~15 s), scansioni rapide della base di riferimento sui push ( | Blocca l'unione delle PR se vengono rilevate vulnerabilità di livello alto o critico appena introdotte ( |
2. Autonomous Remediator( | Trigger manuale ( | • Ripristina lo stato dagli artefatti di scansione ( | Garantisce diff di produzione puliti prima di aprire una PR |
Tre principi fondamentali di progettazione aziendale
Man mano che crei questi workflow nelle sezioni successive, tieni presente questi tre pilastri architettonici fondamentali:
🔑 Autenticazione keyless Zero Trust e convalida preflight:
Nessuna chiave JSON dell'account di servizio Google Cloud di lunga durata viene archiviata in GitHub Secrets. Il runner genera un token OIDC di breve durata scambiato tramite Google Cloud STS per una credenziale temporanea di 1 ora, imposta persist-credentials: false sui checkout Git ed esegue cm health --strict per verificare le credenziali, la connettività di rete e le autorizzazioni IAM prima di consumare la quota del modello.
⚡ Routing di scansione adattivo ed eliminazione dei rumori precedente:
Anziché eseguire lenti controlli completi del repository su ogni richiesta di pull, CodeMender indirizza ogni evento CI alla modalità di scansione ottimale: le richieste di pull attivano l'analisi AST differenziale (--diff="origin/$BASE_REF") sui file modificati e sui chiamanti a 1 hop in meno di 15 secondi; i push del branch principale eseguono scansioni rapide della base di riferimento in una singola sessione (--quick); e le pianificazioni settimanali eseguono controlli approfonditi simultanei file per file (cm find . predefinito). Le vulnerabilità preesistenti della codebase non toccate da una richiesta di pull sono etichettate come [LEGACY / UNTOUCHED]; vengono visualizzate nei report SARIF per visibilità, ma non bloccano il gate di unione della richiesta di pull e non attivano la correzione automatica.
🛡️ Osservabilità della sicurezza resiliente e non bloccante:
Anche quando --fail-on esce con il codice 1 per bloccare una PR non sicura, la protezione dei passaggi di esportazione del report e caricamento SARIF con steps.scan.outputs.completed == 'true' e hashFiles('results.sarif') != '' garantisce che gli avvisi SARIF OASIS e i riepiloghi dei job vengano comunque pubblicati, saltando l'esportazione e il caricamento se un'esecuzione viene annullata o interrotta a causa di un errore di configurazione o di capacità (10–60).
3. Autentica e prepara il repository di destinazione in Cloud Shell
Per stabilire l'autenticazione senza chiave ed eseguire pipeline di sicurezza automatizzate, devi disporre di un repository GitHub di destinazione accessibile di tua proprietà. In questo codelab, utilizzerai OWASP Juice Shop, un'applicazione web Node.js intenzionalmente vulnerabile, come playground di sicurezza pronto all'uso.
Utilizzerai l'interfaccia a riga di comando di GitHub (gh), preinstallata in Google Cloud Shell, per autenticarti con GitHub, acquisire automaticamente i dettagli dell'utente e preparare il repository in un unico flusso semplificato.
Passaggio 1: apri Cloud Shell e autentica l'interfaccia a riga di comando di GitHub
Apri la console Google Cloud e attiva Cloud Shell (icona >_ nella barra di navigazione in alto).
Autentica l'interfaccia a riga di comando di GitHub (gh) per configurare la gestione delle credenziali Git:
gh auth login --hostname github.com --git-protocol https --web
Segui le istruzioni sullo schermo:
Copia il codice monouso di 8 caratteri stampato in Cloud Shell (ad es. 1234-ABCD).
Premi Invio per aprire https://github.com/login/device nel browser.
Incolla il codice e fai clic su Autorizza GitHub.
Passaggio 2: esporta dinamicamente le variabili ed esegui il fork di OWASP Juice Shop
Esegui questi comandi in Cloud Shell per acquisire automaticamente il tuo nome utente GitHub e preparare il repository:
# 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. Configura la federazione delle identità per i workload di Google Cloud tramite gcloud
In questo passaggio, utilizzerai l'interfaccia a riga di comando gcloud in Google Cloud Shell per abilitare le API richieste, creare un service account CI/CD dedicato, configurare il pool di identità del workload e stabilire l'attendibilità OIDC con il tuo repository GitHub (${GITHUB_REPOSITORY}).
Passaggio 1: imposta le variabili di ambiente Google Cloud
Nel terminale Cloud Shell (all'interno dell'area di lavoro del repository clonato), acquisisci l'ID progetto Google Cloud attivo, verifica la variabile del repository GitHub e definisci i nomi delle risorse WIF:
# 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
Passaggio 2: abilita le API Google Cloud richieste
Abilita l'API IAM, l'API Security Token Service, l'API IAM Credentials, l'API Agent Platform e l'API Resource Manager:
gcloud services enable \
iam.googleapis.com \
iamcredentials.googleapis.com \
sts.googleapis.com \
aiplatform.googleapis.com \
cloudresourcemanager.googleapis.com \
--project=${PROJECT_ID}
Passaggio 3: crea un service account CI/CD dedicato
Crea un service account Google Cloud con privilegi minimi dedicato all'esecuzione della pipeline CI/CD (riutilizzandolo in sicurezza se esiste già):
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}"
Passaggio 4: concedi le autorizzazioni IAM di Agent Platform
Concedi il ruolo roles/aiplatform.user (Utente Agent Platform) al service account in modo che possa comunicare con Gemini Enterprise Agent Platform:
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
--member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
--role="roles/aiplatform.user"
Passaggio 5: crea il pool di identità del workload
Crea il pool di identità del workload per gestire le asserzioni di identità di GitHub Actions (o ripristinalo e abilitalo automaticamente se esiste già nel tuo progetto):
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
Passaggio 6: Creare il provider di identità del carico di lavoro con GitHub OIDC
Crea (o aggiorna) il provider OIDC all'interno del pool, associando l'URL dell'emittente https://token.actions.githubusercontent.com e mappando le asserzioni del token GitHub agli attributi STS di Google:
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
Passaggio 7: consenti al repository GitHub di impersonare l'account di servizio
Associa il ruolo roles/iam.workloadIdentityUser per consentire ai token provenienti dal tuo repository di simulare l'identità del service account del runner CI e verifica l'associazione della policy:
# 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
Passaggio 8: recupera i valori di configurazione per i secret di GitHub
Recupera il nome completo della risorsa del provider di identità del workload e memorizzalo in una variabile di ambiente per la registrazione automatica nel passaggio successivo:
# 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. Configura i secret del repository GitHub e le autorizzazioni del workflow
Ora che Google Cloud WIF è stato sottoposto a provisioning, configurerai i secret del repository GitHub e concederai le autorizzazioni di workflow necessarie per l'analisi automatica della sicurezza e le richieste di pull di correzione automatica.
Puoi configurare queste impostazioni direttamente da Cloud Shell utilizzando l'interfaccia a riga di comando di GitHub (gh), eliminando completamente il copia e incolla manuale di nomi di risorse lunghi.
Passaggio 1: imposta i secret del repository utilizzando l'interfaccia a riga di comando di GitHub
Nel terminale Cloud Shell, esegui i comandi seguenti per impostare in modo sicuro i due secret del repository richiesti utilizzando le variabili di ambiente attive:
# 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}"
Passaggio 2: concedi le autorizzazioni del workflow per le PR automatiche
Per impostazione predefinita, i workflow di GitHub Actions vengono eseguiti con autorizzazioni di sola lettura e non possono creare richieste di pull. Nel passaggio 9, CodeMender genererà e invierà autonomamente richieste di pull di correzione verificate.
Concedi le autorizzazioni in scrittura e abilita la creazione di richieste di pull direttamente tramite l'API GitHub:
[ -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
Passaggio 3: disattiva i workflow di Juice Shop upstream ereditati
Il fork di OWASP Juice Shop comporta il trasferimento di oltre 16 workflow di CI upstream (come PR Compliance Check, CI/CD Pipeline e CodeQL Scan) insieme a un modello di PR per i collaboratori upstream che chiude automaticamente le PR destinate a master. Disabilita tutti i workflow non CodeMender tramite GitHub CLI e rimuovi i file upstream localmente in modo che il tuo fork esegua rigorosamente i workflow CodeMender:
[ -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. Crea il workflow di analisi delle vulnerabilità automatizzata con SARIF
In questo passaggio, creerai il workflow principale di scansione di sicurezza continua (.github/workflows/codemender-scan.yml) che esegue scansioni di base sui push dei branch, controlli differenziali sulle richieste di pull ed esportazioni SARIF in GitHub Code Scanning.
Passaggio 1: scarica il workflow di scansione di CodeMender
Scarica codemender-scan.yml dal repository iniziale in .github/workflows/:
[ -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
Passaggio 2: esegui il commit, il push e l'attivazione dell'analisi CI
Esegui il commit delle modifiche al workflow e il push direttamente nel branch principale del repository (master per Juice Shop o 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)
Nel browser:
Vai al tuo repository GitHub con fork: https://github.com/YOUR_GITHUB_USER/juice-shop (ad es. https://github.com/octocat/juice-shop).
Fai clic sulla scheda Azioni nella barra di navigazione in alto.
Nella barra laterale sinistra, in Workflows (Workflow), seleziona CodeMender Security Scan & SARIF Export (Analisi della sicurezza CodeMender ed esportazione SARIF).
Attiva o visualizza l'esecuzione del workflow:
Trigger automatico: se è presente un'esecuzione automatica attivata dal tuo push, fai clic direttamente su questa esecuzione per monitorare l'esecuzione in tempo reale.
Trigger manuale on demand (workflow_dispatch): se non è ancora stata avviata alcuna esecuzione, fai clic sul pulsante Esegui workflow ▾ a destra, assicurati che sia selezionato Branch: master (lascia deselezionata la casella di controllo deep_scan in modo che venga eseguita la scansione rapida della baseline --quick) e fai clic sul pulsante verde Esegui workflow.
Fai clic sull'esecuzione in corso e seleziona Autonomous Code Vulnerability Scan per osservare l'avvio del workflow in tempo reale.
All'interno di codemender-scan.yml: routing di scansione basato sugli eventi
Mentre l'analisi di base di --quick viene eseguita nel cloud (~3-5 minuti), controlla come codemender-scan.yml (righe 118-155) indirizza ogni evento GitHub alla modalità di analisi dedicata all'interno del runner:
# 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
Configurazione di Hardened Runner ( righe 27-117): ignora i fork esterni non attendibili e le PR dependabot[bot], esegue il checkout con persist-credentials: false, memorizza nella cache ~/.local/bin/cm e ~/.codemender/state.db ed esegue cm health --strict prima di consumare la quota del modello di consumo.
Headless Sandbox Boundaries (--sandbox=false --yes --bypass-warning): disattiva l'isolamento dello spazio dei nomi utente Linux (limitato all'interno di container GitHub Actions non privilegiati) mantenendo l'applicazione dei limiti dei percorsi dell'area di lavoro (project_paths) e di command_policy.yaml.
Exit-Code Guarded SARIF & Artifact Export ( righe 147-194): imposta steps.scan.outputs.completed=true rigorosamente quando cm find esce con 0 (pulito) o 1 (soglia --fail-on soddisfatta). In questo modo, i report SARIF (cm report -f sarif con punteggi di gravità CVSS), le tabelle $GITHUB_STEP_SUMMARY (cm report -f md) e gli artefatti codemender-findings.json vengono comunque pubblicati quando --fail-on blocca una PR, mentre l'esportazione viene saltata in caso di errori di configurazione o capacità (10–60), in modo che i file SARIF vuoti non chiudano mai gli avvisi esistenti.
7. Esamina gli avvisi di GitHub Code Scanning e la dashboard di sicurezza
Al termine del workflow di push della base di riferimento, GitHub elabora il file SARIF caricato e compila sia il riepilogo dell'esecuzione delle azioni sia la scheda Sicurezza del repository.
Passaggio 1: esamina il riepilogo del job nativo su GitHub Actions
Ogni esecuzione del workflow aggiunge una tabella di riepilogo Markdown (cm report -f md) direttamente alla panoramica dell'esecuzione di GitHub Actions:
Nel repository GitHub, fai clic sulla scheda Actions (Azioni).
Seleziona l'esecuzione completata di CodeMender Security Scan & SARIF Export (i controlli di push del branch di riferimento terminano con un segno di spunta verde ✅ dopo la pubblicazione dei risultati SARIF).
Scorri verso il basso fino alla sezione 🛡️ CodeMender Security Scan Summary per esaminare la suddivisione dei risultati:
🔒 Report sulla sicurezza di CodeMender
Riepilogo
Risultati totali: 28
Gravità | Conteggio |
🔴 CRITICO | 6 |
🟠 ALTO | 16 |
🟡 MEDIUM | 6 |
Stato | Conteggio |
🔴 APERTO | 28 |
Risultati
ID | Gravità | Sicurezza di sé | Stato | Correggi | File | Titolo |
| 🔴 CRITICO | 100% | APRI | — |
| Esecuzione di codice da remoto tramite inserimento di codice lato server nel profilo utente |
| 🔴 CRITICO | 100% | APRI | — |
| SQL injection nel percorso di autenticazione utente |
| 🔴 CRITICO | 100% | APRI | — |
| Remote Code Execution via Sandbox Escape in B2B Order Processing |
Passaggio 2: esplora la dashboard centralizzata di Code Scanning
Nella barra di navigazione in alto del repository GitHub, fai clic sulla scheda Sicurezza e qualità (o Sicurezza).
Nella barra laterale sinistra, in Risultati, seleziona Analisi del codice.
Se sono attivi più strumenti, filtra Strumento in CodeMender (is:open branch:master tool:CodeMender) per ispezionare gli avvisi mappati con i badge di gravità CVSS nativi:
Badge di gravità | Titolo della vulnerabilità | Posizione rilevata | Branch |
🔴 Critica | Esecuzione di codice da remoto tramite inserimento di codice lato server nel profilo utente |
|
|
🔴 Critica | SQL injection nel percorso di autenticazione utente |
|
|
🔴 Critica | Remote Code Execution via Sandbox Escape in B2B Order Processing |
|
|
Fai clic su SQL Injection in User Authentication Route (routes/login.ts:34) per esaminare il flusso di dati contaminato e l'analisi delle cause principali sintetizzata da Gemini.
8. Blocca una richiesta di pull non sicura con la scansione differenziale
La scansione di riferimento ha rilevato 28 vulnerabilità preesistenti in OWASP Juice Shop. Con gli analizzatori statici tradizionali, questi 28 risultati legacy avrebbero bloccato ogni futura richiesta di pull fino alla correzione dell'intero backlog, costringendo i team a disattivare il blocco dell'unione.
Ora testerai il PR Differential AST Gate (--diff + --fail-on="CRITICAL,HIGH") di CodeMender in azione: apri una richiesta di pull che introduce una nuova vulnerabilità e osserva CodeMender isolare il delta, bloccare l'unione in circa 15-25 secondi e annotare le righe incriminate esatte.
Passaggio 1: apri una richiesta di pull che introduce un difetto di command injection
In Cloud Shell (all'interno del workspace del repository clonato), crea un branch delle funzionalità, aggiungi una nuova route Express contenente una vulnerabilità di inserimento di comandi del sistema operativo e apri una richiesta di pull per il 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."
Passaggio 2: verifica il gate di unione differenziale e l'annotazione della PR in linea
Apri l'URL della richiesta di pull stampato alla fine dell'output del terminale.
Scorri fino alla casella di controllo Controlli in fondo alla pagina della conversazione della richiesta di pull e osserva Autonomous Code Vulnerability Scan:
Velocità delta: invece di scansionare tutti gli oltre 680 file nel repository (~3-5 minuti), cm find . --diff="origin/${PRIMARY_BRANCH}" limita l'analisi rigorosamente a routes/diagnostics.ts (e a qualsiasi chiamante a 1 hop), completando la scansione in ~15-25 secondi.
Isolamento del debito legacy e blocco dell'unione: nessuna delle 28 vulnerabilità legacy non toccate di Juice Shop non supera il controllo; solo la vulnerabilità CRITICAL Command Injection appena introdotta attiva --fail-on="CRITICAL,HIGH", uscendo con il codice di stato 1 (❌ rosso) per bloccare l'unione della PR.
Fai clic sulla scheda Files changed (File modificati) nella parte superiore della richiesta di pull:
Poiché il controllo del codice di uscita del workflow (steps.scan.outputs.completed == 'true') esporta e carica comunque results.sarif quando --fail-on esce con il codice 1, GitHub Code Scanning esegue il rendering di un'annotazione di sicurezza CodeMender — Critical in linea direttamente sotto execSync in routes/diagnostics.ts.
Passaggio 3: pulisci la PR di test e torna al branch principale
Torna al branch principale dell'area di lavoro di Cloud Shell e chiudi la richiesta di pull di test non sicura prima di procedere alla correzione autonoma:
[ -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. Crea il workflow di correzione autonoma e PR automatica
Ora che il gate della richiesta di pull impedisce l'ingresso di nuove vulnerabilità nel codebase, eseguirai il deployment della correzione autonoma (.github/workflows/codemender-remediate.yml) per correggere attivamente le vulnerabilità esistenti e aprire richieste di pull pronte per la revisione.
Passaggio 1: scarica il file del workflow di correzione
CodeMender fornisce due modelli di correzione a seconda della visibilità del repository:
Repository pubblici/open source (codemender-remediate.yml): Modalità di divulgazione responsabile: link agli avvisi SARIF di GitHub Code Scanning senza esporre pubblicamente i vettori di exploit non elaborati.
Repository privati/aziendali (codemender-remediate-private-repo.yml): Modalità di audit interno: incorpora gli artefatti di verifica (PLAN.md, REPORT.md, exploit.sh) all'interno di sezioni di PR comprimibili, escludendoli dai commit Git.
Scarica il workflow di correzione sicuro per il pubblico nel tuo repository:
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
Passaggio 2: esegui il commit e attiva il workflow di correzione autonomo
Esegui il commit e il push del workflow di correzione nel branch principale:
git add .github/workflows/codemender-remediate.yml
git commit -m "ci: add CodeMender autonomous remediation workflow"
git push origin $(git branch --show-current)
Nel browser, vai alla scheda Azioni del repository GitHub.
Nella barra laterale sinistra, in Workflows (Flussi di lavoro), seleziona CodeMender Autonomous Security Remediation & Auto-PR (CodeMender Autonomous Security Remediation e Auto-PR).
Fai clic sul menu a discesa verde Esegui workflow a destra:
Utilizza il workflow da: assicurati che sia selezionato il branch predefinito (master).
Specific Finding ID or prefix to fix (ID o prefisso del risultato specifico da correggere): inserisci il prefisso di 8 caratteri per routes/login.ts annotato nel passaggio 7 (ad esempio, cd47b38a). Se lasci questo campo vuoto, la correzione in batch viene eseguita su tutti i risultati aperti con gravità Critica e Alta (~10-15 minuti); il targeting di un singolo ID viene completato in ~45-60 secondi.
Fai clic sul pulsante verde Esegui workflow all'interno del popup e apri l'esecuzione in corso.
All'interno di codemender-remediate.yml: sintesi autonoma delle patch
Mentre CodeMender sintetizza la patch nel cloud (~30-45 secondi), controlla come codemender-remediate.yml (righe 111-184) orchestra la correzione all'interno del runner:
Ripristino senza scansione (cm report import): scarica l'artefatto codemender-findings.json dal workflow di scansione e lo importa nel workspace (cm report import -f codemender-findings.json), tornando a cm find . --quick solo se non esiste un artefatto precedente.
Sintesi di patch headless (cm fix): blocca project_paths su $GITHUB_WORKSPACE, invia < /dev/null per evitare blocchi interattivi e passa --no-reset durante i loop batch in modo che le correzioni cumulative vengano conservate tra i risultati:
# Executed inside the GitHub Actions runner (codemender-remediate.yml)
cm fix "${SPECIFIC_TARGET}" --sandbox=false --yes --bypass-warning < /dev/null
Clean Production Commits ( righe 155-252): elimina .cm_project, .exploit/ e i file temporanei tramite .git/info/exclude prima che peter-evans/create-pull-request@v8 apra il branch (codemender/auto-remediation-${{ github.run_id }}), eseguendo il commit rigorosamente delle modifiche al codice di produzione:
--- 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
+ })
Passaggio 3: esamina la richiesta di pull appena aperta su GitHub
Vai alla scheda Richieste di pull nel tuo repository e apri la nuova richiesta di pull (ad es. 🛡️ [CodeMender] Fix: SQL Injection in User Authentication Route).
Fai clic su File modificati per confermare che è stato modificato solo routes/login.ts, con tutti i metadati di runtime interni esclusi.
Esamina la descrizione della PR che rimanda direttamente all'avviso di GitHub Code Scanning (SARIF) per l'approvazione del gestore.
10. Risolvi i problemi relativi a casi limite e repository privati
Repository privati senza GitHub Advanced Security (GHAS)
I repository GitHub pubblici ricevono l'importazione SARIF di GitHub Code Scanning illimitata e senza costi. Tuttavia, se esegui il deployment di questo workflow in un repository aziendale privato che non dispone di una licenza GitHub Advanced Security (GHAS) attiva, il passaggio upload-sarif non andrà a buon fine e verrà visualizzato il seguente messaggio:
HTTP 403: Advanced Security must be enabled for this repository to use code scanning.
Risoluzione: fallback del report HTML interattivo autonomo
Il generatore di report HTML integrato di CodeMender (cm report -f html) crea una dashboard di sicurezza interattiva e autonoma con schede delle metriche di gravità, snippet di codice con evidenziazione della sintassi e numeri di riga e un visualizzatore di differenze delle patch in linea senza dipendenze web esterne.
Per supportare i repository privati senza una licenza GHAS, aggiorna .github/workflows/codemender-scan.yml per archiviare un artefatto del report HTML anziché caricare SARIF:
Genera il report HTML autonomo: nel passaggio Export Security Reports & Publish Job Summary, esporta una dashboard HTML insieme al riepilogo Markdown utilizzando cm report -f html > codemender-audit-report.html.
Archivia il report come artefatto del workflow: sostituisci il passaggio Upload SARIF Report to GitHub Code Scanning (github/codeql-action/upload-sarif@v4) con actions/upload-artifact@v4 configurato per caricare codemender-audit-report.html (ad esempio, con il nome dell'artefatto codemender-security-report).
Ispeziona localmente in qualsiasi browser: scarica codemender-security-report.zip direttamente dalla pagina di riepilogo dell'esecuzione del workflow di GitHub Actions, estrailo e apri codemender-audit-report.html in qualsiasi browser web per il triage visivo.
Correzione autonoma del repository privato con prove di audit incorporate
Nei repository aziendali privati, i team di ingegneria e sicurezza hanno bisogno di una visibilità completa sull'analisi delle cause principali, sulla proof of concept dell'exploit e sul piano di correzione senza dover utilizzare dashboard di strumenti esterni. Tuttavia, il commit di script di exploit (exploit.sh) o file markdown interni (PLAN.md, LOG.md) nel branch del repository inquina la cronologia di Git e può attivare falsi avvisi da altri scanner di sicurezza.
Per risolvere il problema, esegui il deployment del workflow di correzione del repository privato dedicato (codemender-remediate-private-repo.yml):
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)
Come funziona la correzione dei repository privati
Verifica dinamica del PoC (cm verify): sintetizza e testa un exploit funzionante prima di generare la correzione per confermare la possibilità di exploit, saltando automaticamente cm fix se la verifica contrassegna un risultato non sfruttabile come DISMISSED.
Embedded PR Audit Collapsibles: estrae REPORT.md, PLAN.md e exploit.sh in /tmp/codemender-evidence/ e li formatta direttamente nella descrizione della richiesta di pull all'interno di blocchi comprimibili <details open> per l'ispezione con un solo clic da parte del revisore.
Archiviazione degli artefatti: archivia l'intera cartella delle prove tramite actions/upload-artifact@v4.
Pristine Git Commits: elimina tutti i metadati di runtime e le directory .exploit in modo che il commit Git della richiesta di pull contenga rigorosamente le modifiche al codice di produzione.
Elenco di controllo per la risoluzione dei problemi relativi alla federazione delle identità per i workload (WIF)
Per impostazione predefinita, google-github-actions/auth@v2 scrive un file di configurazione delle credenziali federate locali durante la configurazione e lo scambio effettivo di token OAuth 2.0 avviene all'avvio di cm health --strict o cm find. Utilizza l'elenco di controllo riportato di seguito per diagnosticare gli errori di autenticazione HTTP 400 o HTTP 403:
Sintomo dell'errore | Causa principale comune | Verifica e correzione |
HTTP 403 ( | Binding | Conferma che |
HTTP 400 ( | Il nome (o l'uso delle maiuscole) del repository OIDC | Esegui di nuovo il passaggio 4 (passaggi 1 e 6) assicurandoti che |
HTTP 400 ( | Mappatura | Verifica che |
Errore HTTP 403 temporaneo immediatamente dopo la configurazione | La propagazione globale di IAM e della federazione delle identità per i workload può richiedere da 1 a 5 minuti per le associazioni appena create. | Attendi 1-2 minuti e fai clic su Esegui di nuovo i job non riusciti in GitHub Actions. |
Per esaminare l'associazione Workload Identity attiva sul tuo service account CI/CD in Cloud Shell, esegui:
gcloud iam service-accounts get-iam-policy "${SERVICE_ACCOUNT_EMAIL}" \
--project="${PROJECT_ID}" \
--flatten="bindings[].members" \
--filter="bindings.role=roles/iam.workloadIdentityUser"
Verifica che l'output associ roles/iam.workloadIdentityUser a principalSet://iam.googleapis.com/<POOL_ID>/attribute.repository/<GITHUB_USER>/<GITHUB_REPO>:
--- bindings: members: principalSet://iam.googleapis.com/.../attribute.repository/<OWNER>/<REPO> role: roles/iam.workloadIdentityUser
Risoluzione dei problemi relativi ai controlli preflight CI/CD e ai codici di uscita dell'interfaccia a riga di comando
I comandi CodeMender (cm health --strict, cm find, cm verify e cm fix) restituiscono codici di uscita deterministici in modo che le pipeline CI/CD possano distinguere immediatamente i risultati di sicurezza dagli errori di configurazione o di servizio:
Codice di uscita | Categoria | Causa principale comune e correzione |
| Operazione riuscita | Controlli di integrità superati o scansione completata senza risultati bloccanti. |
| Risultati/Generale |
|
|
| Scambio di token OAuth/ADC WIF non riuscito ( |
|
| Sintassi |
|
| Il runner non riesce a raggiungere |
|
| Al service account manca |
|
| Il controllo preflight |
|
| L'agente ha raggiunto il limite di attività attive simultanee. Esegui nuovamente il workflow dopo un breve ritardo. |
Per altri errori di runtime, come la risoluzione del branch di base della differenza Git (fetch-depth: 0), i ritardi nella propagazione delle risorse o le autorizzazioni di creazione delle richieste di pull di GitHub Actions, consulta la guida ufficiale alla risoluzione dei problemi di CI/CD di CodeMender.
11. Esegui la pulizia delle risorse
Per evitare il consumo continuo di risorse o per eseguire la pulizia delle configurazioni di test negli ambienti Google Cloud e GitHub, esegui i seguenti passaggi di pulizia.
Passaggio 1: rimuovi i secret del repository GitHub e disabilita i workflow tramite l'interfaccia a riga di comando gh
Utilizza l'interfaccia a riga di comando di GitHub (gh) per eliminare in modo pulito i secret delle azioni del repository e disattivare i workflow di CodeMender:
# 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
Passaggio 2: disattiva o elimina le risorse di federazione delle identità per i workload di Google Cloud
I pool di identità del workload, i provider e i service account non comportano costi di inattività quando non scambiano token. Scegli la modalità di pulizia corrispondente al tuo flusso di lavoro:
Opzione A - Sospendi l'accesso (consigliata se prevedi di eseguire nuovamente il progetto): disattiva immediatamente lo scambio di token OIDC senza attivare la conservazione con eliminazione temporanea di 30 giorni di Google Cloud IAM o i ritardi di propagazione di uniqueId del service account:
gcloud iam workload-identity-pools providers update-oidc "${WORKLOAD_IDENTITY_PROVIDER}" \
--workload-identity-pool="${WORKLOAD_IDENTITY_POOL}" \
--location="global" \
--disabled \
--project="${PROJECT_ID}"
Opzione B - Eliminazione completa: elimina il provider WIF, il pool (conservato nello stato DELETED per 30 giorni) e l'account di servizio dedicato:
# 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. Complimenti
Complimenti! Hai completato il codelab Proteggi la pipeline CI/CD con CodeMender.
Hai progettato, creato e automatizzato con successo una pipeline DevSecOps Zero Trust di livello di produzione utilizzando la federazione delle identità per i workload di Google Cloud, CodeMender e GitHub Actions.
Argomenti trattati
Autenticazione keyless Zero Trust: abbiamo eliminato le chiavi JSON degli account di servizio rischiose e di lunga durata associando i token OIDC GitHub temporanei a Google Cloud IAM tramite la federazione delle identità per i workload (WIF).
Scansione AST differenziale delle PR ed eliminazione dei rumori legacy: scansione continua limitata ai file modificati e ai file dipendenti (--diff="origin/$BASE_REF"), isolando il debito tecnico legacy ([LEGACY / UNTOUCHED]) per mantenere i cicli di feedback degli sviluppatori al di sotto dei 15 secondi.
Report multiformato e riepiloghi dei job nativi: OASIS SARIF v2.1.0 combinato per la scansione del codice GitHub centralizzata con Markdown nativo (cm report -f md >> $GITHUB_STEP_SUMMARY) per una visibilità immediata dei dirigenti direttamente sulle pagine di esecuzione del workflow CI.
Correzione autonoma con revisione human-in-the-loop: siamo passati dalle notifiche di avviso passive alle pipeline di correzione attiva che sintetizzano autonomamente le patch di codice proposte, le verificano rispetto alle suite di test di regressione e aprono richieste di pull di revisione con artefatti di audit per l'approvazione degli ingegneri.
Controlli di qualità automatizzati: applicazione di una protezione rigorosa dei branch e di un controllo dei merge (--fail-on) per impedire che vulnerabilità pericolose raggiungano la produzione.
Trasferimento dello stato basato sugli artefatti e isolamento dell'area di lavoro: i risultati sono stati trasferiti senza problemi tra i job CI utilizzando cm report import, mentre .git/info/exclude è stato utilizzato per preservare la cronologia Git originale e impedire la fuga di credenziali.
Cambiamento di mentalità degli sviluppatori
Pratica DevSecOps tradizionale | Pipeline CI/CD autonoma di CodeMender |
Dump passivo degli avvisi: gli scanner stampano log del terminale non elaborati o elenchi di errori statici, spostando l'onere del triage interamente sugli sviluppatori. | Co-sviluppatore attivo: sintetizza patch di codice verificate e apre richieste di pull pronte per l'unione per l'approvazione degli ingegneri. |
Elevato numero di falsi positivi: le euristiche AST statiche segnalano migliaia di vulnerabilità teoriche senza prove di sfruttabilità. | Verifica degli exploit a due livelli: la generazione di test sandbox dinamici ( |
Archiviazione di secret rischiosa: le chiavi JSON degli account di servizio di lunga durata archiviate nei secret di CI rischiano fughe di dati accidentali e proliferazione delle credenziali. | WIF Zero Trust: autenticazione senza chiavi tramite token OIDC temporanei scambiati con Google Cloud STS on demand. |
Nuove scansioni monolitiche: ogni commit attiva audit completi del repository, ritardando i workflow di CI e sprecando token costosi. | Routing AST basato sugli eventi: le richieste di pull eseguono scansioni AST differenziali di 15 secondi ( |
Cronologia del repository inquinata: script di exploit temporanei e log degli attacchi di cui è stato eseguito il commit direttamente nei branch del repository. | Igiene dell'area di lavoro aziendale: le prove dell'attacco sono incorporate in modo pulito nelle descrizioni delle PR e negli artefatti del flusso di lavoro, mantenendo puri i commit del codice. |
Passaggi successivi
🚀 Continua il percorso di apprendimento di CodeMender:
Parte 1: Proteggi la tua applicazione con CodeMender - Padroneggia il rilevamento autonomo delle vulnerabilità dei repository, la verifica degli exploit PoC e la sintesi delle patch locali.
Shift Left Locally & Serverless Cloud Native CI/CD: esplora le implementazioni di riferimento della guida ufficiale alla CI/CD per Google Cloud Build (cloudbuild.yaml) e Local Git Pre-commit Hooks (cm find . --diff --staged).
📖 Esplora la documentazione e le risorse:
Guida ufficiale all'integrazione di Google Cloud CodeMender CI/CD
Documentazione ufficiale di Google Cloud CodeMender
Repository di modelli di avvio di GitHub Actions di CodeMender
Documentazione relativa alla federazione delle identità per i workload di Google Cloud
💡 Applica ai tuoi repository:
Crea un fork del workflow iniziale e proteggi i repository Python, Go, Java, Rust e Node.js della tua organizzazione con CodeMender.