Integración de comprobaciones de análisis de composición de software en canalizaciones

  • 9 minutos

La integración del análisis de composición de software en las canalizaciones de CI/CD permite la comprobación automatizada y continua de la seguridad y el cumplimiento de las dependencias a lo largo del ciclo de vida del desarrollo de software. En lugar de realizar evaluaciones de seguridad una vez antes de la versión, la SCA integrada por canalización valida continuamente las dependencias con cada cambio de código, detectando vulnerabilidades al principio cuando son más fáciles y menos costosas de corregir.

¿Por qué integrar SCA en canalizaciones?

Los enfoques de seguridad tradicionales crearon patrones peligrosos en los que los equipos de seguridad detectaron vulnerabilidades en tiempo de desarrollo cuando la presión para liberar era mayor. Este patrón dio como resultado el envío de software vulnerable o los esfuerzos de corrección de última hora costosos retrasando las versiones.

Ventajas de seguridad de desplazamiento a la izquierda

Detección temprana de vulnerabilidades:

  • Comentarios inmediatos: Los desarrolladores reciben notificaciones de vulnerabilidad en cuestión de minutos después de introducir dependencias vulnerables.
  • Menores costos de remediación: Corregir vulnerabilidades durante el desarrollo cuesta significativamente menos que corregirlas en producción.
  • Conservación del contexto: Los desarrolladores tienen contexto completo sobre las opciones de dependencia cuando se detectan vulnerabilidades inmediatamente.
  • Correcciones incrementales: Las mejoras de seguridad continuas pequeñas son más fáciles de implementar que los grandes esfuerzos de corrección.

Cumplimiento continuo:

  • Cumplimiento de directivas: las comprobaciones automatizadas de canalización aplican directivas de seguridad y licencias en cada confirmación.
  • Seguimientos de auditoría: los resultados del examen de canalización proporcionan pruebas de cumplimiento y seguimientos de auditoría.
  • Estándares coherentes: Todos los cambios de código se someten a la misma revisión de seguridad independientemente de quién los envíe.
  • Prevención de riesgos: Bloquear las dependencias vulnerables antes de la combinación impide la acumulación de deudas de seguridad.

Velocidad de desarrollo:

  • Revisiones automatizadas: Las herramientas de SCA realizan análisis de dependencias automáticamente sin necesidad de revisiones manuales del equipo de seguridad.
  • Procesamiento paralelo: Los exámenes de seguridad se ejecutan en paralelo con otros pasos de compilación, lo que minimiza el impacto en los tiempos de compilación.
  • Versiones más rápidas: La validación continua de seguridad en todo el desarrollo permite versiones más rápidas y seguras.
  • Reducción de rehacer el trabajo: la detección temprana de problemas elimina un trabajo costoso durante la preparación para el lanzamiento.

Puntos de integración de tubería

La implementación eficaz de SCA incluye varios puntos de integración en toda la canalización de CI/CD.

Validación de solicitudes de incorporación de cambios

Verificaciones de seguridad previas a la fusión: la validación de solicitudes de incorporación de cambios detecta dependencias vulnerables antes de su integración en ramas principales, lo que impide la acumulación de pasivo de seguridad.

Validación de pull requests de 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"

Validación de solicitudes de incorporación de cambios de Acciones de GitHub:

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

Comprobaciones de solicitudes de pull:

  • Cambios de dependencia: Detecte qué dependencias han cambiado en la solicitud de incorporación de cambios.
  • Nuevas vulnerabilidades: Identifique las nuevas vulnerabilidades introducidas por los cambios de dependencia.
  • Infracciones de licencia: Marca las infracciones de la directiva de licencia antes de la combinación.
  • Puertas de calidad: Bloquear las solicitudes de incorporación de cambios que infringen las directivas de seguridad o cumplimiento.
  • Comentarios de revisión: publique los resultados del examen como comentarios de solicitud de incorporación de cambios para la visibilidad del revisor.

Compilaciones de integración continua

Examen de SCA en tiempo de compilación: Cada compilación de CI debe incluir el examen de SCA para validar las dependencias en el contexto completo de la aplicación.

Integración de CI de Azure Pipelines:

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"

Integración de Acciones de GitHub CI:

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

Características de compilación de CI:

  • Examen completo de dependencias: Examine todas las dependencias, incluidas las dependencias transitivas.
  • Cumplimiento de directivas: se produce un error en las compilaciones que infringen las directivas de seguridad o cumplimiento.
  • Generación SBOM: cree artefactos de materiales de facturación de software para el consumo de bajada.
  • Comparación de línea base: Compare los resultados del examen actual con las compilaciones anteriores para detectar regresiones.
  • Recopilación de métricas: Realice un seguimiento de los recuentos de vulnerabilidades, las tasas de corrección y las puntuaciones de cumplimiento a lo largo del tiempo.

Exámenes profundos programados

Análisis periódico completo: Los exámenes programados proporcionan un análisis exhaustivo sin bloquear el flujo de trabajo del desarrollador.

Examen programado de 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"

Ventajas del análisis programado:

  • Análisis exhaustivo: Análisis profundo con todos los niveles de gravedad sin bloquear el desarrollo.
  • Nueva detección de vulnerabilidades: Detecte vulnerabilidades recién divulgadas en dependencias sin cambios.
  • Informes completos: Generar informes detallados para los equipos de seguridad y la administración.
  • Análisis de tendencias: Realice un seguimiento de los cambios de postura de seguridad a lo largo del tiempo mediante un escaneo constante.

Validación de canalización de versión

Puertas de seguridad previas a la implementación: Las canalizaciones de versión deben validar los artefactos antes de implementarlos en entornos de producción.

Puerta de lanzamiento de 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"

Comprobaciones de validación de versión:

  • Examen de artefactos: Examine los artefactos compilados y las imágenes de contenedor antes de la implementación.
  • Directivas específicas de producción: Aplique directivas de seguridad más estrictas para las implementaciones de producción.
  • Comprobación de cumplimiento: Compruebe el cumplimiento de licencias antes de la versión de producción.
  • Puertas de aprobación: Requerir aprobación manual para implementaciones con riesgos conocidos pero aceptados.

Puertas de calidad y aplicación de directivas

Definición de directivas de seguridad: Las herramientas de SCA aplican directivas que definen estándares de seguridad y cumplimiento aceptables.

Políticas basadas en la gravedad

Bloquear compilaciones basadas en la gravedad de vulnerabilidad:

Directiva de ejemplo de 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"
    }
  ]
}

Esta directiva produce un error en las compilaciones que contienen vulnerabilidades críticas o altas y vulnerabilidades medias anteriores a 30 días.

Ejemplo de directiva de Snyk:

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

Directivas basadas en licencias

Exigir el cumplimiento de licencias:

Directiva de licencia de ejemplo:

{
  "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"]
    }
  ]
}

Categorías de directivas de licencia:

  • Licencias denegadas: licencias prohibidas en todas las circunstancias (copia fuerte para software propietario).
  • Licencias que requieren aprobación: Licencias que requieren revisión legal antes de su uso (copyleft débil, licencias personalizadas).
  • Licencias permitidas: Licencias permisivas aceptables sin revisión (MIT, Apache 2.0, BSD).

Reglas de directiva personalizadas

Condiciones avanzadas de política:

{
  "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"
    }
  ]
}

Generación SBOM en canalizaciones

Los documentos de lista de materiales de software (SBOM) proporcionan un inventario completo de todos los componentes de software.

Generación de artefactos SBOM

Generación 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"

Generación de SBOM de 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"

Casos de uso de SBOM:

  • Evidencia de cumplimiento: Proporcionar a los clientes o auditores para demostrar la transparencia de las dependencias.
  • Seguimiento de vulnerabilidades: Use SBOM para determinar rápidamente si las vulnerabilidades recién divulgadas afectan al software implementado.
  • Seguridad de la cadena de suministro: Realice un seguimiento de la procedencia del software y detecte ataques de cadena de suministro.
  • Cumplimiento de licencias: Documente todas las obligaciones de licencia en el software implementado.

Integraciones específicas de herramientas

Mend (anteriormente WhiteSource)

Tarea Mend de Azure Pipelines:

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

Snyk

Tarea de Snyk de Azure Pipelines:

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

OWASP Dependency-Check

Tarea OWASP de Azure Pipelines:

- 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"

Pato negro

Tarea de Black Duck en Azure Pipelines:

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

Procedimientos recomendados para la integración de canalizaciones

Optimizar el rendimiento del escaneo:

  • Examen incremental: use exámenes incrementales para solicitudes de incorporación de cambios, exámenes completos para compilaciones de rama principal.
  • Caché: Almacenar en caché la resolución de dependencias y los resultados del escaneo para acelerar las ejecuciones posteriores.
  • Ejecución en paralelo: Ejecute exámenes de SCA en paralelo con otros pasos de compilación siempre que sea posible.
  • Planificación de análisis: efectúe análisis completos según el cronograma establecido en vez de bloquear todos los commits de código.

Administrar falsos positivos:

  • Archivos de supresión: mantenga los archivos de supresión para falsos positivos conocidos.
  • Directivas compatibles con el contexto: Configure directivas teniendo en cuenta si realmente se usa código vulnerable.
  • Revisión periódica: Revise periódicamente los resultados suprimidos para asegurarse de que permanecen falsos positivos.

Proporcione comentarios accionables:

  • Mensajes claros: Proporcione explicaciones claras de las violaciones de políticas y los pasos de corrección.
  • Guía de corrección: Vínculo a la documentación que explica cómo corregir vulnerabilidades.
  • Priorización: Clasificar los resultados por gravedad y vulnerabilidad de seguridad para ayudar a los desarrolladores a priorizar.

Supervisión y mejora:

  • Paneles de métricas: Realice un seguimiento de las tendencias de vulnerabilidades, el tiempo de corrección y las tasas de cumplimiento.
  • Formación en equipo: Entrene a los desarrolladores en la selección de dependencia segura y corrección de vulnerabilidades.
  • Iteración del proceso: Refina continuamente las directivas y la integración en función de los comentarios y las métricas del equipo.

La integración del análisis de composición de software en canalizaciones de CI/CD transforma la seguridad de una puerta en fase tardía en un proceso de validación continua durante todo el desarrollo. El examen automatizado controlado por directivas detecta las vulnerabilidades al principio, aplica el cumplimiento continuamente y proporciona la base para la entrega segura de software. En la siguiente unidad se examinan herramientas de SCA específicas y cómo evaluar sus capacidades para las necesidades de su organización.