Questo articolo è stato scritto in collaborazione con Mikey Strauss e Viktor Kartashov.
Trasforma i 10 principali rischi OWASP in controlli automatizzati e verificabili
Negli ambienti DevOps moderni, le pipeline CI/CD sono la spina dorsale della distribuzione del software. Ma una grande velocità comporta una maggiore esposizione. Con l'accelerazione dei rilasci da parte delle organizzazioni, gli aggressori prendono sempre più di mira le pipeline non sicure per iniettare codice dannoso, esfiltrare segreti o compromettere l'integrità della supply chain.
Per affrontare questo problema, il framework OWASP Top 10 CI/CD Security Risks evidenzia le debolezze più comuni e critiche nelle pipeline di sviluppo. Scriba SicurezzaAbbiamo adottato questo framework per aiutare le organizzazioni a integrare la sicurezza CI/CD direttamente nei loro flussi di lavoro tramite prove firmate, applicazione basata su iniziative e policy-as-code.
Perché i rischi CI/CD OWASP sono importanti
Gli strumenti di sicurezza tradizionali faticano a tenere il passo con la velocità dei moderni processi. Senza un'applicazione automatizzata e una visibilità adeguata, i problemi più comuni sfuggono:
❌ Segreti codificati nelle configurazioni della pipeline
❌ Artefatti di costruzione manomessi senza provenienza
❌ Immagini di base non sicure estratte da registri pubblici
❌ Accesso a livello di amministratore senza 2FA o controlli di revisione
Il framework OWASP formalizza questi rischi, fornendo un linguaggio e una struttura condivisi per la correzione. In Scribe, lo utilizziamo per definire iniziative che verificano automaticamente la sicurezza delle pipeline CI/CD, senza richiedere modifiche sostanziali al processo di build.
La sicurezza inizia con le prove firmate
Per convalidare la sicurezza del tuo pipeline, raccogliamo e firmiamo crittograficamente prove quali:
- Git SBOM e Image SBOM
Generato utilizzando scribe-security/action-bom, questi forniscono piena visibilità su ciò che è presente nel tuo codice e nei tuoi contenitori. - Provenienza SLSA
Registra come, dove e da chi sono stati realizzati i tuoi manufatti. - Scansioni di GitHub org e repo
Esegui tramite piattaforme d'azione per verificare la presenza di segreti, deviazioni di configurazione e accessi configurati in modo errato.
Tutte queste prove sono firmate, garantendone l'integrità e la tracciabilità, e mappate su prodotti e versioni specifici per il monitoraggio del ciclo di vita.
???? Abbiamo trattato questo modello basato sulle prove nei nostri post precedenti su Conformità SLSA e Applicazione SP 800–190.
🔒 Applicazione dei controlli OWASP tramite Policy-as-Code
In Scribe, mappiamo i 10 principali rischi CI/CD OWASP in un iniziativa politica come codice che viene eseguito direttamente nella pipeline CI. Ogni rischio è rappresentato come una regola configurabile definita in un ambiente locale owasp-top10-cicd.yaml file. Queste regole vengono valutate automaticamente durante la fase di verifica, fornendo feedback concreti e indicazioni per la correzione.
Ecco alcuni dei controlli chiave inclusi:
- CICD-SEC-1 : Applicare le regole di protezione delle filiali
Previeni modifiche non autorizzate al codice limitando gli invii diretti a rami critici come principale. - CICD-SEC-2 : Controlli di gestione dell'identità e dell'accesso
Richiedi l'autenticazione a più fattori (MFA) e limita i privilegi amministrativi nel tuo provider Git. - CICD-SEC-3 : Verifica della dipendenza
Assicurarsi che tutte le immagini di base e le dipendenze di terze parti vengano estratte da registri approvati e attendibili. - CICD-SEC-4 : Prevenzione dell'esecuzione di condotte avvelenate
Limita chi può modificare gli script CI/CD per evitare di introdurre logica dannosa nei tuoi flussi di lavoro. - CICD-SEC-6 : Applicazione dell'igiene delle credenziali
Esegui la scansione alla ricerca di segreti hardcoded, token scaduti o credenziali trapelate, quindi segnalali prima del rilascio.
Ciascuno di questi controlli può essere personalizzato in base alla tolleranza al rischio, all'ambiente o ai requisiti di conformità della tua organizzazione. Poiché è definito come codice, la tua strategia di sicurezza diventa verificabile, versione controllatae esecutiva tramite automazione.
✅ Punta Pro: Puoi includere o escludere regole specifiche, impostare soglie di gravità e persino personalizzare i consigli di correzione, direttamente nel file di configurazione dell'iniziativa.
Introducendo questi controlli nella tua pipeline, passi dalle revisioni ad hoc a applicazione automatizzata e verificabile della sicurezza – un passaggio fondamentale per proteggere la catena di fornitura del software.
GitHub Actions: integrazione CI/CD nel mondo reale
Ecco un esempio di flusso di lavoro che utilizza le azioni di Scribe per creare, raccogliere prove, analizzare l'organizzazione e verificare la conformità al framework OWASP Top 10 CI/CD:
nome: OWASP CI/CD Secure Build su: push: branches: - main env: PRODUCT_NAME: my-app PRODUCT_VERSION: v1.0 jobs: build: runs-on: ubuntu-latest outputs: image-name: ${{ steps.meta.outputs.image }} steps: - uses: actions/checkout@v4 - uses: docker/setup-buildx-action@v3 - run: echo "${{ secrets.REGISTRY_PASSWORD }}" | docker login ${{ secrets.REGISTRY_URL }} -u ${{ secrets.REGISTRY_USER }} --password-stdin - id: meta uses: docker/build-push-action@v5 with: context: . push: true tag: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} - usa: scribe-security/action-bom@master con: target: 'git:.' chiave prodotto: ${{ env.PRODUCT_NAME }} versione prodotto: ${{ env.PRODUCT_VERSION }} formato: attest - usa: scribe-security/action-bom@master con: destinazione: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} immagine base: Dockerfile chiave prodotto: ${{ env.PRODUCT_NAME }} versione prodotto: ${{ env.PRODUCT_VERSION }} formato: attest - usa: scribe-security/action-verify@master con: destinazione: ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} chiave prodotto: ${{ env.PRODUCT_NAME }} versione prodotto: ${{ env.PRODUCT_VERSION }} iniziativa: slsa.l2@v2 provenienza: vero formato: attest abbellimento: vero org-scan: viene eseguito su: ubuntu-latest steps: - utilizza: scribe-security/action-platforms@master con: comando: discover piattaforma: github segno: true attest-default: sigstore argomenti: >- --token ${{ secrets.GITHUB_PAT }} --organization.mapping ${{ github.repository_owner }}::${{ env.PRODUCT_NAME }}::${{ env.PRODUCT_VERSION }} --repository.mapping $(basename ${{ github.repository }})::${{ env.PRODUCT_NAME }}::${{ env.PRODUCT_VERSION }} --scope.workflow.past_days 1 --scope.branch ${{ github.ref_name }} --hook trivy_iac_and_secrets_sarif verifica: viene eseguito su: ubuntu-latest necessita di: [build, org-scan] passaggi: - usa: scribe-security/action-verify@master con: iniziativa: owasp-top10-cicd.yaml chiave prodotto: ${{ env.PRODUCT_NAME }} versione prodotto: ${{ env.PRODUCT_VERSION }} formato: attestare tutte le prove: vero abbellire: vero
Conformità continua in azione
Questo flusso di lavoro genera un'attestazione verificabile che mostra quali rischi OWASP la pipeline supera o fallisce. Ogni violazione è riconducibile a prove specifiche (SBOM, log del flusso di lavoro e configurazioni dell'organizzazione), consentendo ai team di risolvere i problemi in modo rapido e sicuro.
Vuoi vedere come funziona nel mondo reale? Ecco un esempio di risultato di scansione da una delle nostre pipeline interne:
Vista riassuntiva
Visualizzazione della violazione
Visualizzazione delle prove
Questo contenuto è offerto da Scribe Security, un fornitore leader di soluzioni di sicurezza end-to-end per la catena di fornitura di software, che offre sicurezza all'avanguardia per artefatti di codice e processi di sviluppo e distribuzione del codice attraverso le catene di fornitura di software. Per saperne di più.
Post Correlati
