Integracja kontroli analizy kompozycji oprogramowania do przepływów pracy

  • 9 min

Integracja analizy składu oprogramowania z potokami ciągłej integracji/ciągłego wdrażania umożliwia automatyczne ciągłe sprawdzanie zabezpieczeń zależności i zgodności w całym cyklu życia tworzenia oprogramowania. Zamiast przeprowadzania oceny zabezpieczeń raz przed wydaniem, zintegrowane z potokiem rozwiązanie SCA stale weryfikuje zależności przy każdej zmianie kodu, wychwytując luki w zabezpieczeniach na wczesnym etapie, kiedy są najłatwiejsze i najtańsze do naprawy.

Dlaczego warto zintegrować usługę SCA z potokami?

Tradycyjne podejścia do zabezpieczeń stworzyły niebezpieczne wzorce, w których zespoły ds. zabezpieczeń wykryły luki w zabezpieczeniach pod koniec opracowywania, gdy presja na wydanie była najwyższa. Ten wzorzec spowodował wysyłanie oprogramowania podatnego na zagrożenia lub kosztowne działania korygowania w ostatniej chwili opóźniające wydania.

Korzyści wynikające z przesunięcia uwagi na bezpieczeństwo na wcześniejsze etapy开发

Wczesne wykrywanie luk w zabezpieczeniach:

  • Natychmiastowa opinia: Deweloperzy otrzymują powiadomienia o lukach w zabezpieczeniach w ciągu kilku minut od wprowadzenia zależności podatnych na zagrożenia.
  • Niższe koszty usuwania luk: Naprawianie luk w zabezpieczeniach podczas tworzenia kosztuje znacznie mniej niż naprawianie ich w produkcji.
  • Zachowywanie kontekstu: Deweloperzy mają pełny kontekst wyboru zależności w przypadku natychmiastowego odnalezienia luk w zabezpieczeniach.
  • Poprawki przyrostowe: Małe, ciągłe ulepszenia zabezpieczeń są łatwiejsze do wdrożenia niż duże wysiłki naprawcze.

Ciągła zgodność:

  • Wymuszanie polityk: Automatyczne kontrole procesu wymuszają polityki licencyjne i zabezpieczeń przy każdym zatwierdzeniu.
  • Ślady audytu: Wyniki skanowania pipeline zapewniają dowody zgodności i ślady audytu.
  • Spójne standardy: Wszystkie zmiany kodu przechodzą ten sam przegląd zabezpieczeń niezależnie od tego, kto je przesyła.
  • Zapobieganie ryzyku: Blokowanie podatnych na zagrożenia zależności przed scaleniem uniemożliwia akumulację zadłużenia zabezpieczeń.

Szybkość opracowywania:

  • Zautomatyzowane przeglądy: Narzędzia SCA automatycznie wykonują analizę zależności bez konieczności ręcznego przeprowadzania przeglądów zespołu ds. zabezpieczeń.
  • Przetwarzanie równoległe: Skanowania zabezpieczeń są uruchamiane równolegle z innymi krokami kompilacji, minimalizując wpływ na czas kompilacji.
  • Szybsze wersje: Ciągła walidacja zabezpieczeń w trakcie opracowywania umożliwia szybsze i bardziej pewne wydania.
  • Zmniejszenie przeróbek: Wczesne uchwycenie problemów eliminuje konieczność kosztownych przeróbek podczas przygotowywania wydania.

Punkty integracji rurociągu

Efektywna implementacja SCA obejmuje wiele punktów integracji w potoku ciągłej integracji/ciągłego wdrażania.

Walidacja żądania ściągnięcia

Kontrole zabezpieczeń przed scaleniem: Walidacja żądań ściągnięcia identyfikuje wrażliwe zależności przed ich scaleniem z głównymi gałęziami, zapobiegając gromadzeniu się długu technicznego dotyczącego zabezpieczeń.

Weryfikacja żądania ściągnięcia usługi 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"

Weryfikacja pull request w 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

Sprawdzanie żądań ściągnięcia:

  • Zmiany zależności: Wykryj, które zależności uległy zmianie w pull request.
  • Nowe luki w zabezpieczeniach: Identyfikowanie nowych luk w zabezpieczeniach wprowadzonych przez zmiany zależności.
  • Naruszenia licencji: Flaguj naruszenia zasad licencji przed scaleniem.
  • Progi jakości: Blokuj prośby o scalanie naruszające zasady zabezpieczeń lub zgodności.
  • Przejrzyj komentarze: Opublikuj wyniki skanowania jako komentarze do pull requestu, aby były widoczne dla recenzenta.

Budowania ciągłej integracji

Skanowanie SCA w czasie kompilacji: Każda kompilacja ciągłej integracji powinna obejmować skanowanie SCA w celu zweryfikowania zależności w pełnym kontekście aplikacji.

Integracja CI usługi 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"

Integracja CI z 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

Funkcje kompilacji ciągłej integracji:

  • Pełne skanowanie zależności: Skanuj wszystkie zależności, w tym zależności przechodnie.
  • Egzekwowanie zasad: Kompilacje, które naruszają zasady zabezpieczeń lub zgodności, kończą się niepowodzeniem.
  • Generowanie SBOM: Tworzenie rachunku za oprogramowanie artefaktów materiałów na potrzeby użycia podrzędnego.
  • Porównanie linii bazowej: Porównaj bieżące wyniki skanowania z poprzednimi kompilacjami, aby wykryć regresje.
  • Kolekcja metryk: Śledzenie liczby luk w zabezpieczeniach, współczynników korygowania i wyników zgodności w czasie.

Zaplanowane głębokie skanowania

Kompleksowa okresowa analiza: Zaplanowane skanowania zapewniają dokładną analizę bez blokowania przepływu pracy dewelopera.

Zaplanowane skanowanie w usłudze 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"

Zalety zaplanowanego skanowania:

  • Dokładna analiza: Głębokie skanowanie ze wszystkimi poziomami ważności bez blokowania programowania.
  • Nowe wykrywanie luk w zabezpieczeniach: Wykrywanie nowo ujawnionych luk w zabezpieczeniach w niezmienionych zależnościach.
  • Kompleksowe raportowanie: Generowanie szczegółowych raportów dla zespołów ds. zabezpieczeń i zarządzania nimi.
  • Analiza trendów: Śledzenie zmian stanu zabezpieczeń w czasie dzięki spójnemu skanowaniu.

Walidacja ścieżki wydania

Bramy zabezpieczeń przed wdrożeniem: Potoki wydania powinny weryfikować artefakty oprogramowania przed wdrożeniem do środowisk produkcyjnych.

Brama wydania usługi 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"

Sprawdzanie poprawności wersji:

  • Skanowanie artefaktów: Skanuj skompilowane artefakty i obrazy kontenerów przed wdrożeniem.
  • Zasady specyficzne dla środowiska produkcyjnego: Stosowanie bardziej rygorystycznych zasad zabezpieczeń dla wdrożeń produkcyjnych.
  • Weryfikacja zgodności: Sprawdź zgodność licencji przed wydaniem produkcyjnym.
  • Bramy zatwierdzania: Wymagaj ręcznego zatwierdzania wdrożeń ze znanymi, ale akceptowanymi zagrożeniami.

Bramy jakości i wymuszanie zasad

Definiowanie zasad zabezpieczeń: Narzędzia SCA wymuszają zasady definiujące akceptowalne standardy zabezpieczeń i zgodności.

Zasady oparte na dotkliwości

Blokuj kompilacje na podstawie stopnia luk w zabezpieczeniach:

Przykładowa zasada 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"
    }
  ]
}

Polityka powoduje zakończenie procesu kompilacji, gdy zawiera ona wysokie lub krytyczne luki w zabezpieczeniach, oraz średnie luki w zabezpieczeniach starsze niż 30 dni.

Przykładowe zasady Snyk:

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

Zasady oparte na licencjach

Wymuszanie zgodności licencji:

Przykładowe zasady licencji:

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

Kategorie zasad licencji:

  • Licencje odrzucone: Licencje zakazane we wszystkich okolicznościach (surowy copyleft dla oprogramowania własnościowego).
  • Licencje wymagające zatwierdzenia: Licencje, które wymagają przeglądu prawnego przed użyciem (słabe copyleft, licencje niestandardowe).
  • Dozwolone licencje: Licencje permissive dopuszczalne bez przeglądu (MIT, Apache 2.0, BSD).

Niestandardowe zasady polityki

Zaawansowane warunki zasad:

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

Generowanie SBOM w linii produkcyjnych

Dokumenty dotyczące rozliczania oprogramowania (SBOM) zawierają kompleksowy spis wszystkich składników oprogramowania.

Generowanie artefaktów SBOM

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

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

Przypadki użycia SBOM:

  • Dowody zgodności: Zapewnienie klientom lub audytorom wykazania przejrzystości zależności.
  • Śledzenie luk w zabezpieczeniach: Użyj rozwiązania SBOM, aby szybko określić, czy nowo ujawnione luki w zabezpieczeniach mają wpływ na wdrożone oprogramowanie.
  • Bezpieczeństwo łańcucha dostaw: Śledzenie pochodzenia oprogramowania i wykrywanie ataków łańcucha dostaw.
  • Zgodność licencji: Udokumentowanie wszystkich zobowiązań licencyjnych dotyczących wdrożonego oprogramowania.

Integracje specyficzne dla narzędzi

Mend (dawniej WhiteSource)

Zadanie naprawcze usługi 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

Zadanie Snyk Azure Pipelines:

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

Dependency-Check OWASP

Azure Pipelines OWASP Task:

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

Czarna Kaczka

Zadanie Black Duck w usłudze Azure Pipelines:

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

Najlepsze praktyki dotyczące integracji rurociągu

Optymalizowanie wydajności skanowania:

  • Skanowanie przyrostowe: Używaj skanów przyrostowych dla pull requestów, pełnych skanów dla kompilacji gałęzi głównej.
  • Buforowanie: Rozwiązywanie zależności pamięci podręcznej i przechowywanie wyników skanowania w celu przyspieszenia kolejnych przebiegów.
  • Wykonywanie równoległe: Uruchom skanowanie SCA równolegle z innymi krokami kompilacji, jeśli to możliwe.
  • Planowanie skanowania: Uruchamiaj kompleksowe skany zgodnie z harmonogramem zamiast blokować każde zatwierdzenie.

Zarządzaj fałszywymi alarmami:

  • Pliki tłumienia: Utrzymywanie plików tłumienia dla znanych fałszywych wyników pozytywnych.
  • Zasady obsługujące kontekst: Skonfiguruj zasady, biorąc pod uwagę, czy kod podatny na zagrożenia jest rzeczywiście używany.
  • Regularne przeglądy: Okresowo sprawdzaj pominięte wyniki, aby upewnić się, że pozostają fałszywie dodatnie.

Prześlij opinię z możliwością działania:

  • Jasne komunikaty: Podaj jasne wyjaśnienia naruszeń zasad i kroków korygowania.
  • Wskazówki dotyczące korygowania: Link do dokumentacji wyjaśniającej sposób naprawiania luk w zabezpieczeniach.
  • Priorytetyzacja: Uszereguj wyniki według ważności i możliwości wykorzystania, aby ułatwić deweloperom ustalanie priorytetów.

Monitorowanie i ulepszanie:

  • Pulpity nawigacyjne metryk: Śledzenie trendów luk w zabezpieczeniach, czasu korygowania i współczynników zgodności.
  • Edukacja zespołowa: Szkolenie deweloperów na temat bezpiecznego wyboru zależności i korygowania luk w zabezpieczeniach.
  • Iteracja procesu: Stale uściślij zasady i integrację na podstawie opinii i metryk zespołu.

Integrując analizę składu oprogramowania z potokami CI/CD przekształca bezpieczeństwo z bramki późnego etapu w proces ciągłej weryfikacji w całym procesie rozwoju. Automatyczne skanowanie oparte na zasadach wcześnie przechwytuje luki w zabezpieczeniach, wymusza ciągłą zgodność i zapewnia podstawę bezpiecznego dostarczania oprogramowania. W następnej lekcji zapoznasz się z konkretnymi narzędziami analizy głównej przyczyny i sposobem oceny ich możliwości dla potrzeb organizacji.