Cet article a été co-écrit par Mikey Strauss et Viktor Kartachov.
Transformez les 10 principaux risques de l'OWASP en contrôles automatisés et auditables
Dans les environnements DevOps modernes, les pipelines CI/CD constituent l'épine dorsale de la distribution logicielle. Mais cette rapidité implique une grande exposition. À mesure que les entreprises accélèrent les livraisons, les attaquants ciblent de plus en plus les pipelines non sécurisés pour injecter du code malveillant, exfiltrer des secrets ou compromettre l'intégrité de la chaîne d'approvisionnement.
Pour y remédier, le cadre OWASP Top 10 CI/CD Security Risks met en évidence les faiblesses les plus courantes et les plus critiques des pipelines de développement. Scribe Sécurité, nous avons adopté ce cadre pour aider les organisations à intégrer la sécurité CI/CD directement dans leurs flux de travail grâce à des preuves signées, une application basée sur des initiatives et une politique en tant que code.
Pourquoi les risques CI/CD de l'OWASP sont importants
Les outils de sécurité traditionnels peinent à suivre la vitesse des pipelines modernes. Sans application et visibilité automatisées, des problèmes courants passent inaperçus :
❌ Secrets codés en dur dans les configurations de pipeline
❌ Artefacts de construction falsifiés sans provenance
❌ Images de base non sécurisées extraites de registres publics
❌ Accès de niveau administrateur sans 2FA ni contrôles de révision
Le framework OWASP formalise ces risques en fournissant un langage et une structure communs pour la correction. Chez Scribe, nous l'utilisons pour définir des initiatives qui vérifient automatiquement la sécurité de vos pipelines CI/CD, sans nécessiter de modifications majeures de votre processus de build.
La sécurité commence par des preuves signées
Pour valider que votre pipeline est sécurisé, nous collectons et signons cryptographiquement des preuves telles que :
- Git SBOM et Image SBOM
Généré à l'aide scribe-sécurité/action-bom, ils offrent une visibilité complète sur ce qui se trouve dans votre code et vos conteneurs. - Provenance SLSA
Capture comment, où et par qui vos artefacts ont été construits. - Analyses de l'organisation et du dépôt GitHub
Courir via plateformes d'action pour vérifier les secrets, les dérives de configuration et les accès mal configurés.
Toutes ces preuves sont signées, garantissant l'intégrité et la traçabilité, et mappées à des produits et versions spécifiques pour le suivi du cycle de vie.
📌 Nous avons abordé ce modèle basé sur des preuves dans nos articles précédents sur Conformité SLSA et Application de la SP 800–190.
🔒 Application des contrôles OWASP via Policy-as-Code
Chez Scribe, nous cartographions les 10 principaux risques CI/CD de l'OWASP dans un initiative de politique en tant que code qui s'exécute directement dans votre pipeline d'intégration continue. Chaque risque est représenté par une règle configurable définie localement. owasp-top10-cicd.yaml fichier. Ces règles sont évaluées automatiquement pendant la phase de vérification, fournissant des commentaires exploitables et des conseils de correction.
Voici quelques-unes des commandes clés incluses :
- CICD-SEC-1 : Appliquer les règles de protection des succursales
Empêchez les modifications de code non autorisées en limitant les pushs directs aux branches critiques telles que principal. - CICD-SEC-2 : Contrôles de gestion des identités et des accès
Exigez une authentification multifacteur (MFA) et limitez les privilèges administratifs dans votre fournisseur Git. - CICD-SEC-3 : Vérification des dépendances
Assurez-vous que toutes les images de base et les dépendances tierces sont extraites de registres approuvés et fiables. - CICD-SEC-4 : Prévention de l'exécution des pipelines empoisonnés
Limitez les personnes autorisées à modifier les scripts CI/CD pour éviter d'introduire une logique malveillante dans vos flux de travail. - CICD-SEC-6 : Application de l'hygiène des informations d'identification
Recherchez les secrets codés en dur, les jetons expirés ou les informations d'identification divulguées, puis signalez-les avant leur publication.
Chacun de ces contrôles peut être personnalisé en fonction de la tolérance au risque, de l'environnement et des exigences de conformité de votre organisation. Parce qu'il s'agit d'un code, votre posture de sécurité devient vérifiable, version contrôléeet exécutoire par automatisation.
✅ Astuce supplémentaire : Vous pouvez inclure ou exclure des règles spécifiques, définir des seuils de gravité et même personnaliser des conseils de correction, directement dans votre fichier de configuration d'initiative.
En intégrant ces contrôles dans votre pipeline, vous passez des examens ponctuels aux application automatisée et vérifiable de la sécurité – une étape cruciale dans la protection de votre chaîne d’approvisionnement en logiciels.
Actions GitHub : intégration CI/CD concrète
Voici un exemple de flux de travail utilisant les actions de Scribe pour créer, collecter des preuves, analyser l'organisation et vérifier la conformité par rapport au cadre CI/CD Top 10 de l'OWASP :
nom : OWASP CI/CD Secure Build sur : push : branches : - principal env : PRODUCT_NAME : my-app PRODUCT_VERSION : v1.0 jobs : build : runs-on : ubuntu-latest sorties : image-name : ${{ steps.meta.outputs.image }} étapes : - utilise : actions/checkout@v4 - utilise : docker/setup-buildx-action@v3 - exécuter : echo "${{ secrets.REGISTRY_PASSWORD }}" | docker login ${{ secrets.REGISTRY_URL }} -u ${{ secrets.REGISTRY_USER }} --password-stdin - id : meta utilise : docker/build-push-action@v5 avec : contexte : . push : true tags : ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} - utilise : scribe-security/action-bom@master avec : cible : 'git:.' clé-produit : ${{ env.PRODUCT_NAME }} version-produit : ${{ env.PRODUCT_VERSION }} format : attest - utilise : scribe-security/action-bom@master avec : cible : ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} image-base : Dockerfile clé-produit : ${{ env.PRODUCT_NAME }} version-produit : ${{ env.PRODUCT_VERSION }} format : attest - utilise : scribe-security/action-verify@master avec : cible : ${{ secrets.REGISTRY_URL }}/my-app:${{ github.sha }} clé-produit : ${{ env.PRODUCT_NAME }} version-produit : ${{ env.PRODUCT_VERSION }} initiative : slsa.l2@v2 provenance : true format : attest embellir : true org-scan: s'exécute sur: ubuntu-latest étapes: - utilise: scribe-security/action-platforms@master avec: commande: découvrir la plateforme: github signer: true atteste-par défaut: sigstore arguments: >- --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 vérifier: s'exécute sur: ubuntu-latest a besoin de : [build, org-scan] étapes : - utilise : scribe-security/action-verify@master avec : initiative : owasp-top10-cicd.yaml clé-produit : ${{ env.PRODUCT_NAME }} version-produit : ${{ env.PRODUCT_VERSION }} format : atteste toutes les preuves : vrai embellir : vrai
Conformité continue en action
Ce workflow génère une attestation vérifiable indiquant les risques OWASP que votre pipeline respecte ou non. Chaque violation est traçable grâce à des preuves spécifiques (SBOM, journaux de workflow et configurations organisationnelles), permettant aux équipes de résoudre les problèmes rapidement et en toute confiance.
Vous souhaitez voir à quoi cela ressemble en pratique ? Voici un exemple de résultat d'analyse de l'un de nos pipelines internes :
Vue récapitulative
Vue de violation
Vue des preuves
Ce contenu vous est proposé par Scribe Security, l'un des principaux fournisseurs de solutions de sécurité de bout en bout pour la chaîne d'approvisionnement logicielle, offrant une sécurité de pointe aux artefacts de code ainsi qu'aux processus de développement et de livraison de code tout au long des chaînes d'approvisionnement logicielles. En savoir plus.
articles similaires
