Intégrer des contrôles d’analyse de composition logicielle dans des pipelines

  • 9 minutes

L’intégration de l’analyse de la composition logicielle dans les pipelines CI/CD permet de vérifier la sécurité et la conformité automatisées et continues des dépendances tout au long du cycle de vie du développement logiciel. Au lieu d’effectuer des évaluations de sécurité une fois avant la mise en production, la SCA intégrée au pipeline valide en permanence les dépendances avec chaque modification de code, en interceptant les vulnérabilités dès qu’elles sont plus faciles et moins coûteuses à corriger.

Pourquoi intégrer SCA dans des pipelines ?

Les approches de sécurité traditionnelles ont créé des modèles dangereux où les équipes de sécurité ont découvert des vulnérabilités en retard dans le développement lorsque la pression pour libérer était la plus élevée. Ce modèle a entraîné l’expédition de logiciels vulnérables ou d’efforts de correction coûteux de dernière minute qui retardent les versions.

Avantages de la sécurité déplacée vers la gauche

Détection précoce des vulnérabilités :

  • Commentaires immédiats : Les développeurs reçoivent des notifications de vulnérabilité en quelques minutes après l’introduction de dépendances vulnérables.
  • Réduction des coûts de correction : Résoudre les vulnérabilités pendant le développement coûte beaucoup moins cher que de les corriger en production.
  • Conservation du contexte : Les développeurs ont un contexte complet sur les choix de dépendance lorsque des vulnérabilités sont découvertes immédiatement.
  • Correctifs incrémentiels : Les petites améliorations de sécurité continue sont plus faciles à implémenter que les efforts de correction volumineux.

Conformité continue :

  • Mise en œuvre des politiques : Les vérifications automatisées des pipelines imposent les politiques de licence et de sécurité à chaque validation.
  • Pistes d’audit : Les résultats de l’analyse du pipeline fournissent des preuves de conformité et des pistes d’audit.
  • Normes cohérentes : Toutes les modifications de code subissent la même révision de sécurité, quelle que soit la personne qui les envoie.
  • Prévention des risques : Le blocage des dépendances vulnérables avant la fusion empêche l’accumulation de dettes de sécurité.

Vitesse de développement :

  • Révisions automatisées : Les outils SCA effectuent automatiquement une analyse des dépendances sans nécessiter de révisions manuelles de l’équipe de sécurité.
  • Traitement parallèle : Les analyses de sécurité s’exécutent en parallèle avec d’autres étapes de génération, ce qui réduit l’impact sur les temps de génération.
  • Versions plus rapides : La validation continue de la sécurité tout au long du développement permet des versions plus rapides et plus confiantes.
  • Remaniement réduit : L’interception précoce des problèmes élimine les remaniements coûteux pendant la préparation de la mise en production.

Points d’intégration de pipeline

Une implémentation SCA efficace comprend plusieurs points d’intégration dans le pipeline CI/CD.

Validation des demandes de tirage

Vérifications de sécurité avant fusion : La validation des demandes de tirage intercepte les dépendances vulnérables avant qu’elles ne soient fusionnées dans les branches principales, ce qui empêche l’accumulation de dettes de sécurité.

Validation des requêtes de tirage Azure Pipelines :

trigger: none

pr:
  branches:
    include:
      - main
      - develop

pool:
  vmImage: "ubuntu-latest"

steps:
  - task: UseNode@1
    inputs:
      version: "18.x"
    displayName: "Install Node.js"

  - script: npm ci
    displayName: "Install dependencies"

  - task: WhiteSource@21
    inputs:
      cwd: "$(System.DefaultWorkingDirectory)"
      projectName: "$(Build.Repository.Name)"
    displayName: "Run Mend SCA scan"

  - task: PublishTestResults@2
    inputs:
      testResultsFormat: "JUnit"
      testResultsFiles: "**/test-results.xml"
    displayName: "Publish scan results"

Validation des demandes de tirage GitHub Actions :

name: Security Scan

on:
  pull_request:
    branches: [main, develop]

jobs:
  sca-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "18"

      - name: Install dependencies
        run: npm ci

      - name: Run Snyk security scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

      - name: Upload scan results
        uses: github/codeql-action/upload-sarif@v2
        if: always()
        with:
          sarif_file: snyk.sarif

Vérifications des pull requests :

  • Modifications des dépendances : Identifier les dépendances qui ont changé dans la demande de fusion.
  • Nouvelles vulnérabilités : Identifiez les nouvelles vulnérabilités introduites par les modifications de dépendance.
  • Violations de licence : Marquer les violations de stratégie de licence avant la fusion.
  • Portes de qualité : Bloquer les requêtes de pull qui violent les politiques de sécurité ou de conformité.
  • Commentaires d’examen : Publiez les résultats de l’analyse en tant que commentaires de requête de tirage pour la visibilité de l’examinateur.

Builds d’intégration continue

Analyse SCA au moment de la génération : Chaque build CI doit inclure l’analyse SCA pour valider les dépendances dans le contexte complet de l’application.

Intégration d’Azure Pipelines CI :

trigger:
  branches:
    include:
      - main
      - develop
      - feature/*

pool:
  vmImage: "ubuntu-latest"

variables:
  buildConfiguration: "Release"

steps:
  - task: UseDotNet@2
    inputs:
      packageType: "sdk"
      version: "7.x"
    displayName: "Install .NET SDK"

  - task: DotNetCoreCLI@2
    inputs:
      command: "restore"
      projects: "**/*.csproj"
    displayName: "Restore NuGet packages"

  - task: WhiteSource@21
    inputs:
      cwd: "$(System.DefaultWorkingDirectory)"
      projectName: "$(Build.Repository.Name)"
      scanComment: "CI Build $(Build.BuildNumber)"
      checkPolicies: true
      failBuildOnPolicyViolation: true
    displayName: "Mend SCA scan with policy enforcement"

  - task: DotNetCoreCLI@2
    inputs:
      command: "build"
      projects: "**/*.csproj"
      arguments: "--configuration $(buildConfiguration)"
    displayName: "Build application"

  - task: PublishBuildArtifacts@1
    inputs:
      pathToPublish: "$(Build.ArtifactStagingDirectory)"
      artifactName: "drop"
    displayName: "Publish build artifacts"

Intégration CI de GitHub Actions :

name: CI Build

on:
  push:
    branches: [main, develop]
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: "3.11"

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Run OWASP Dependency-Check
        uses: dependency-check/Dependency-Check_Action@main
        with:
          project: "my-application"
          path: "."
          format: "SARIF"
          args: >
            --failOnCVSS 7
            --suppression suppression.xml

      - name: Upload scan results to GitHub Security
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: dependency-check-report.sarif

      - name: Build application
        run: python setup.py build

      - name: Generate SBOM
        run: |
          pip install cyclonedx-bom
          cyclonedx-py -i requirements.txt -o sbom.json

      - name: Upload SBOM artifact
        uses: actions/upload-artifact@v3
        with:
          name: sbom
          path: sbom.json

Fonctionnalités de build CI :

  • Analyse complète des dépendances : Analysez toutes les dépendances, y compris les dépendances transitives.
  • Application des politiques : Rendre échoués les builds qui ne respectent pas les politiques de sécurité ou de conformité.
  • Génération de SBOM : Créez une facture logicielle d’artefacts de matériaux pour la consommation en aval.
  • Comparaison de référence : Comparez les résultats d’analyse actuels par rapport aux builds précédentes pour détecter les régressions.
  • Collection de métriques : Suivez les nombres de vulnérabilités, les taux de correction et les scores de conformité au fil du temps.

Analyses approfondies planifiées

Analyse périodique complète : Les analyses planifiées fournissent une analyse approfondie sans bloquer le flux de travail du développeur.

Scan programmé d’Azure Pipelines :

schedules:
  - cron: "0 2 * * *"
    displayName: "Nightly security scan"
    branches:
      include:
        - main
    always: true

trigger: none
pr: none

pool:
  vmImage: "ubuntu-latest"

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: "18.x"
    displayName: "Install Node.js"

  - script: npm ci
    displayName: "Install dependencies"

  - task: Snyk@1
    inputs:
      serviceConnectionEndpoint: "SnykConnection"
      testType: "app"
      severityThreshold: "low"
      monitorOnBuild: true
      failOnIssues: false
      projectName: "$(Build.Repository.Name)"
    displayName: "Deep Snyk scan (all severities)"

  - task: BlackDuck@1
    inputs:
      BlackDuckService: "BlackDuckConnection"
      ScanMode: "intelligent"
      DetectArguments: "--detect.policy.check.fail.on.severities ALL"
    displayName: "Black Duck comprehensive scan"

  - task: PublishBuildArtifacts@1
    inputs:
      pathToPublish: "$(Build.ArtifactStagingDirectory)/SecurityReports"
      artifactName: "SecurityReports"
    displayName: "Publish detailed scan reports"

Avantages de l’analyse planifiée :

  • Analyse approfondie : Analyse approfondie avec tous les niveaux de gravité sans bloquer le développement.
  • Nouvelle détection de vulnérabilité : Détecter les vulnérabilités nouvellement divulguées dans les dépendances inchangées.
  • Rapports complets : Générez des rapports détaillés pour les équipes de sécurité et la gestion.
  • Analyse des tendances : Suivez les changements de posture de sécurité au fil du temps grâce à une analyse cohérente.

Validation du pipeline de déploiement

Portes de sécurité de prédéploiement : Les pipelines de mise en production doivent valider les artefacts avant de les déployer dans des environnements de production.

Porte de publication d’Azure Pipelines :

stages:
  - stage: Build
    jobs:
      - job: BuildJob
        steps:
          - task: DotNetCoreCLI@2
            inputs:
              command: "build"

  - stage: SecurityValidation
    dependsOn: Build
    jobs:
      - job: SCAValidation
        steps:
          - task: DownloadBuildArtifacts@0
            inputs:
              artifactName: "drop"

          - task: WhiteSource@21
            inputs:
              cwd: "$(System.ArtifactsDirectory)/drop"
              projectName: "$(Build.Repository.Name)"
              checkPolicies: true
              failBuildOnPolicyViolation: true
            displayName: "Validate artifact dependencies"

  - stage: DeployProduction
    dependsOn: SecurityValidation
    condition: succeeded()
    jobs:
      - deployment: DeployToProduction
        environment: "production"
        strategy:
          runOnce:
            deploy:
              steps:
                - task: AzureWebApp@1
                  inputs:
                    azureSubscription: "AzureConnection"
                    appName: "my-web-app"
                    package: "$(Pipeline.Workspace)/drop"

Vérifications de validation des mises en production :

  • Analyse des artefacts : Analysez les artefacts compilés et les images conteneur avant le déploiement.
  • Stratégies spécifiques à la production : Appliquez des stratégies de sécurité plus strictes pour les déploiements de production.
  • Vérification de conformité : Vérifiez la conformité des licences avant la mise en production.
  • Portes d’approbation : Exiger une approbation manuelle pour les déploiements avec des risques connus mais acceptés.

Portes de qualité et application des politiques

Définition de stratégies de sécurité : Les outils SCA appliquent des stratégies qui définissent des normes de sécurité et de conformité acceptables.

Stratégies basées sur la gravité

Bloquer les builds en fonction de la gravité des vulnérabilités :

Exemple de stratégie Mend :

{
  "name": "Production Security Policy",
  "enabled": true,
  "rules": [
    {
      "type": "VULNERABILITY_SEVERITY",
      "action": "FAIL_BUILD",
      "minSeverity": "HIGH"
    },
    {
      "type": "VULNERABILITY_AGE",
      "action": "FAIL_BUILD",
      "maxAge": 30,
      "minSeverity": "MEDIUM"
    }
  ]
}

Cette stratégie échoue avec des builds contenant des vulnérabilités élevées ou critiques et des vulnérabilités moyennes antérieures à 30 jours.

Exemple de stratégie Snyk :

# .snyk policy file
version: v1.0.0
patch: {}
ignore: {}
policies:
  - severity:
      low: ignore
      medium: warn
      high: fail
      critical: fail

Stratégies basées sur des licences

Appliquer la conformité des licences :

Exemple de stratégie de licence :

{
  "name": "License Compliance Policy",
  "enabled": true,
  "rules": [
    {
      "type": "LICENSE_TYPE",
      "action": "FAIL_BUILD",
      "deniedLicenses": ["GPL-2.0", "GPL-3.0", "AGPL-3.0"]
    },
    {
      "type": "LICENSE_TYPE",
      "action": "REQUIRE_APPROVAL",
      "approvalRequired": ["LGPL-2.1", "LGPL-3.0", "MPL-2.0"]
    }
  ]
}

Catégories de stratégie de licence :

  • Licences refusées : Licences interdites en toutes circonstances (copyleft fort pour les logiciels propriétaires).
  • Licences devant être approuvées : Licences nécessitant une révision légale avant l’utilisation (faible copyleft, licences personnalisées).
  • Licences autorisées : Licences permissives acceptables sans révision (MIT, Apache 2.0, BSD).

Règles de stratégie personnalisées

Conditions de stratégie avancées :

{
  "name": "Advanced Security Policy",
  "enabled": true,
  "rules": [
    {
      "type": "VULNERABILITY_CVSS_SCORE",
      "action": "FAIL_BUILD",
      "minScore": 7.0,
      "condition": "exploitMaturity == 'FUNCTIONAL' OR exploitMaturity == 'HIGH'"
    },
    {
      "type": "DEPENDENCY_AGE",
      "action": "WARN",
      "maxAge": 365,
      "message": "Dependency has not been updated in over a year"
    },
    {
      "type": "MAINTAINER_STATUS",
      "action": "WARN",
      "condition": "abandonedProject == true"
    }
  ]
}

Génération de SBOM dans les chaînes de production

Les documents SBOM (Software Bill of Materials) fournissent un inventaire complet de tous les composants logiciels.

Générer des éléments SBOM

Génération de CycloneDX SBOM :

steps:
  - task: UseNode@1
    inputs:
      version: "18.x"

  - script: |
      npm ci
      npm install -g @cyclonedx/cyclonedx-npm
      cyclonedx-npm --output-file sbom.json
    displayName: "Generate CycloneDX SBOM"

  - task: PublishBuildArtifacts@1
    inputs:
      pathToPublish: "sbom.json"
      artifactName: "SBOM"

Génération SBOM SPDX :

steps:
  - script: |
      pip install spdx-tools
      pip-licenses --format=json --output-file=licenses.json
      # Convert to SPDX format using custom script
      python scripts/generate_spdx.py licenses.json sbom.spdx
    displayName: "Generate SPDX SBOM"

Cas d’usage de SBOM :

  • Preuve de conformité : Fournir aux clients ou aux auditeurs une preuve de transparence des dépendances.
  • Suivi des vulnérabilités : Utilisez SBOM pour déterminer rapidement si les vulnérabilités nouvellement divulguées affectent les logiciels déployés.
  • Sécurité de la chaîne logistique : Effectuez le suivi de la provenance logicielle et détectez les attaques de chaîne logistique.
  • Conformité des licences : Documentez toutes les obligations de licence dans les logiciels déployés.

Intégrations spécifiques aux outils

Mend (anciennement WhiteSource)

Tâche Azure Pipelines Mend :

- task: WhiteSource@21
  inputs:
    cwd: "$(System.DefaultWorkingDirectory)"
    projectName: "$(Build.Repository.Name)"
    checkPolicies: true
    failBuildOnPolicyViolation: true
    scanComment: "Build $(Build.BuildNumber)"
  displayName: "Mend SCA scan"

Snyk

Tâche Azure Pipelines Snyk :

- task: SnykSecurityScan@1
  inputs:
    serviceConnectionEndpoint: "SnykConnection"
    testType: "app"
    severityThreshold: "high"
    monitorOnBuild: true
    failOnIssues: true
  displayName: "Snyk security scan"

Vérification de dépendance OWASP

Tâche Azure Pipelines OWASP :

- script: |
    wget https://github.com/jeremylong/DependencyCheck/releases/download/v8.0.0/dependency-check-8.0.0-release.zip
    unzip dependency-check-8.0.0-release.zip
    ./dependency-check/bin/dependency-check.sh \
      --project "$(Build.Repository.Name)" \
      --scan . \
      --format ALL \
      --failOnCVSS 7
  displayName: "OWASP Dependency-Check scan"

Canard noir

Tâche Azure Pipelines Black Duck :

- task: BlackDuck@1
  inputs:
    BlackDuckService: "BlackDuckConnection"
    ScanMode: "intelligent"
    DetectArguments: "--detect.policy.check.fail.on.severities CRITICAL,HIGH"
  displayName: "Black Duck scan"

Meilleures pratiques pour l’intégration de pipelines

Optimiser les performances de la numérisation :

  • Analyse incrémentielle : Utilisez des analyses incrémentielles pour les demandes d’extraction, des analyses complètes pour les builds de la branche principale.
  • Cache: Résolution des dépendances de cache et résultats d’analyse pour accélérer les exécutions suivantes.
  • Exécution parallèle : Exécutez des analyses SCA en parallèle avec d’autres étapes de génération si possible.
  • Planification de l’analyse : Exécutez des analyses complètes selon des planifications plutôt que de bloquer chaque validation.

Gérer les faux positifs :

  • Fichiers de suppression : Conservez les fichiers de suppression pour les faux positifs connus.
  • Stratégies prenant en compte le contexte : Configurez des stratégies en tenant compte de l’utilisation du code vulnérable.
  • Révision régulière : Examinez régulièrement les résultats supprimés pour s’assurer qu’ils restent faux positifs.

Fournissez des commentaires actionnables :

  • Messages clairs : Fournissez des explications claires sur les violations de politique et les étapes de correction.
  • Conseils de correction : Lien vers la documentation expliquant comment corriger les vulnérabilités.
  • Hiérarchisation : Classer les résultats par gravité et exploitabilité pour aider les développeurs à hiérarchiser.

Surveillez et améliorez :

  • Métriques tableaux de bord : Suivez les tendances des vulnérabilités, le temps de correction et les taux de conformité.
  • Formation d’équipe : Former des développeurs sur la sélection des dépendances sécurisées et la correction des vulnérabilités.
  • Itération de processus : Affinez en permanence les stratégies et l’intégration en fonction des commentaires et des métriques de l’équipe.

L’intégration de l’analyse de composition logicielle dans les pipelines CI/CD transforme la sécurité d'un contrôle en fin de processus en un processus de validation continue tout au long du développement. L’analyse automatisée basée sur les stratégies intercepte les vulnérabilités dès le début, applique la conformité en continu et fournit la base de la livraison sécurisée de logiciels. L’unité suivante examine des outils SCA spécifiques et explique comment évaluer leurs capacités en fonction des besoins de votre organisation.