Integrer kontrol af softwarekompositionsanalyse i pipelines

Fuldført

Integration af Software Composition Analysis i CI/CD-pipelines muliggør automatiseret, kontinuerlig afhængighedssikkerhed og overensstemmelseskontrol gennem hele softwareudviklingens livscyklus. I stedet for at udføre sikkerhedsvurderinger én gang før udgivelse validerer pipelineintegreret SCA løbende afhængigheder ved hver kodeændring og fanger sårbarheder tidligt, når de er nemmest og billigst at løse.

Hvorfor integrere SCA i pipelines?

Traditionelle sikkerhedstilgange skabte farlige mønstre, hvor sikkerhedsteams opdagede sårbarheder sent i udviklingen, når presset for at frigive var størst. Dette mønster resulterede i enten forsendelse af sårbar software eller dyre afhjælpningsindsatser i sidste øjeblik, der forsinkede udgivelser.

Sikkerhedsfordele ved skift til venstre

Tidlig registrering af sårbarheder:

  • Øjeblikkelig feedback: Udviklere modtager meddelelser om sårbarheder inden for få minutter efter introduktion af sårbare afhængigheder.
  • Lavere afhjælpningsomkostninger: At rette sårbarheder under udvikling koster betydeligt mindre end at rette dem i produktionen.
  • Bevarelse af kontekst: Udviklere har fuld kontekst om afhængighedsvalg, når sårbarheder opdages med det samme.
  • Trinvise rettelser: Små, kontinuerlige sikkerhedsforbedringer er nemmere at implementere end store afhjælpningsindsatser.

Løbende overholdelse:

  • Håndhævelse af politikker: Automatiserede pipelinekontroller håndhæver licens- og sikkerhedspolitikker for hver commit.
  • Revisionsspor: Pipelinescanningsresultater giver bevis for overholdelse af angivne standarder og revisionsspor.
  • Ensartede standarder: Alle kodeændringer gennemgår den samme sikkerhedsgennemgang, uanset hvem der indsender dem.
  • Risikoforebyggelse: Blokering af sårbare afhængigheder før sammenlægning forhindrer akkumulering af sikkerhedsgæld.

Udviklingshastighed:

  • Automatiserede anmeldelser: SCA-værktøjer udfører afhængighedsanalyser automatisk uden at kræve manuelle gennemgange af sikkerhedsteamet.
  • Parallel behandling: Sikkerhedsscanninger kører parallelt med andre buildtrin, hvilket minimerer indvirkningen på byggetider.
  • Hurtigere udgivelser: Løbende sikkerhedsvalidering gennem hele udviklingen giver hurtigere og mere sikre udgivelser.
  • Reduceret efterbearbejdning: At fange problemer tidligt eliminerer dyr omarbejdning under forberedelse af frigivelse.

Pipeline-integrationspunkter

Effektiv SCA-implementering omfatter flere integrationspunkter i hele CI/CD-pipelinen.

Validering af pull-anmodning

Sikkerhedstjek før fletning: Validering af pullanmodninger fanger sårbare afhængigheder, før de flettes ind i hovedgrene, hvilket forhindrer akkumulering af sikkerhedsgæld.

Validering af Azure Pipelines-pullanmodning:

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"

Validering af GitHub Actions pullanmodning:

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

Kontrol af pull-anmodninger:

  • Afhængighed ændringer: Registrer, hvilke afhængigheder der er ændret i pullanmodningen.
  • Nye sårbarheder: Identificer nye sårbarheder, der opstår som følge af afhængighedsændringer.
  • Overtrædelser af licensen: Markér overtrædelser af licenspolitikken før fletning.
  • Kvalitets porte: Bloker pullanmodninger, der overtræder sikkerheds- eller overholdelsespolitikker.
  • Gennemgå kommentarer: Send scanningsresultater som pull-anmodningskommentarer for at få korrekturlæserens synlighed.

Løbende integrationsopbygning

SCA-scanning i byggetid: Hvert CI-build skal indeholde SCA-scanning for at validere afhængigheder i hele programkonteksten.

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

GitHub Actions CI-integration:

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

CI-build-funktioner:

  • Scanning af fuld afhængighed: Scan alle afhængigheder, herunder transitive afhængigheder.
  • Håndhævelse af politikker: Fejlbehæftede builds, der overtræder sikkerheds- eller overholdelsespolitikker.
  • SBOM-generering: Opret softwarestyklisteartefakter til downstreamforbrug.
  • Sammenligning af baseline: Sammenlign aktuelle scanningsresultater med tidligere builds for at registrere regressioner.
  • Indsamling af målepunkter: Spor antal sårbarheder, afhjælpningsrater og overholdelsesscorer over tid.

Planlagte dybe scanninger

Omfattende periodisk analyse: Planlagte scanninger giver grundige analyser uden at blokere udviklerens arbejdsgang.

Planlagt scanning af 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"

Fordele ved planlagt scanning:

  • Grundig analyse: Dyb scanning med alle sværhedsgrader uden at blokere udvikling.
  • Ny sårbarhedsregistrering: Registrer nyligt afslørede sårbarheder i uændrede afhængigheder.
  • Omfattende rapportering: Generer detaljerede rapporter til sikkerhedsteams og ledelse.
  • Tendensanalyse: Spor ændringer i sikkerhedsniveauet over tid gennem ensartet scanning.

Validering af udgivelsespipeline

Sikkerhedsporte før implementering: Frigivelsespipelines skal validere artefakter, før de udrulles i produktionsmiljøer.

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

Kontrol af godkendelse af frigivelse:

  • Scanning af artefakter: Scan kompilerede artefakter og objektbeholderafbildninger før udrulning.
  • Produktionsspecifikke politikker: Anvend strengere sikkerhedspolitikker for produktionsinstallationer.
  • Verifikation af overholdelse: Kontrollér licensoverholdelse før produktionsudgivelse.
  • Godkendelsesporte: Kræv manuel godkendelse for installationer med kendte, men accepterede risici.

Kvalitetsdøre og håndhævelse af politikker

Definition af sikkerhedspolitikker: SCA-værktøjer håndhæver politikker, der definerer acceptable sikkerheds- og overholdelsesstandarder.

Politikker baseret på alvorsgrad

Bloker builds baseret på sværhedsgraden af sårbarhed:

Eksempel på Reparationspolitik:

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

Denne politik mislykkes builds, der indeholder høje eller kritiske sårbarheder og mellemstore sårbarheder, der er ældre end 30 dage.

Eksempel på Snyk-politik:

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

Licensbaserede politikker

Gennemtving licensoverholdelse:

Eksempel på licenspolitik:

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

Kategorier af licenspolitik:

  • Afviste licenser: Licenser forbudt under alle omstændigheder (stærk copyleft til proprietær software).
  • Godkendelseskrævede licenser: Licenser, der kræver juridisk gennemgang før brug (svag copyleft, brugerdefinerede licenser).
  • Tilladte licenser: Tilladte licenser accepteres uden gennemgang (MIT, Apache 2.0, BSD).

Brugerdefinerede politikregler

Avancerede forsikringsbetingelser:

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

SBOM-generering i rørledninger

Software Bill of Materials (SBOM) -dokumenter giver en omfattende oversigt over alle softwarekomponenter.

Generer SBOM-artefakter

CycloneDX SBOM-generation:

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"

SPDX SBOM-generation:

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"

SBOM-brugssager:

  • Bevis for overholdelse: Giv kunder eller revisorer, der demonstrerer gennemsigtighed i afhængighed.
  • Sporing af sårbarheder: Brug SBOM til hurtigt at afgøre, om nyligt afslørede sårbarheder påvirker implementeret software.
  • Sikkerhed i forsyningskæden: Spor softwarens oprindelse, og opdag angreb i forsyningskæden.
  • Overholdelse af licens: Dokumentér alle licensforpligtelser i implementeret software.

Værktøjsspecifikke integrationer

Mend (tidligere WhiteSource)

Azure Pipelines Reend-opgave:

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

Snyk

Azure Pipelines Snyk-opgave:

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

OWASP-Dependency-Check

Azure Pipelines OWASP-opgave:

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

Sort and

Azure Pipelines Black Duck-opgave:

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

Bedste praksis for pipelineintegration

Optimer scanningens ydeevne:

  • Trinvis scanning: Brug trinvise scanninger til pullanmodninger, komplette scanninger til hovedgrensbuilds.
  • Cachelagring: Cacheafhængighedsopløsning og scanningsresultater for at fremskynde efterfølgende kørsler.
  • Parallel udførelse: Kør SCA-scanninger parallelt med andre build-trin, når det er muligt.
  • Planlægning af scanninger: Kør omfattende scanninger efter tidsplaner i stedet for at blokere alle commit.

Administrer falske positiver:

  • Undertrykkelse filer: Vedligehold undertrykkelsesfiler for kendte falske positiver.
  • Kontekstbevidste politikker: Konfigurer politikker under hensyntagen til, om sårbar kode rent faktisk bruges.
  • Regelmæssig gennemgang: Gennemgå regelmæssigt undertrykte resultater for at sikre, at de forbliver falske positiver.

Giv brugbar feedback:

  • Klare budskaber: Giv klare forklaringer på politikovertrædelser og afhjælpningstrin.
  • Vejledning til afhjælpning: Link til dokumentation, der forklarer, hvordan du løser sårbarheder.
  • Prioritering: Rangordn resultater efter alvorsgrad og udnyttelsesmuligheder for at hjælpe udviklere med at prioritere.

Overvåg og forbedre:

  • Dashboards til målinger: Spor sårbarhedstendenser, afhjælpningstid og overholdelsesrater.
  • Holduddannelse: Træn udviklere i sikker afhængighedsudvælgelse og afhjælpning af sårbarheder.
  • Proces iteration: Forfin løbende politikker og integration baseret på teamfeedback og målinger.

Integration af Software Composition Analysis i CI/CD-pipelines forvandler sikkerhed fra en sen fase til en kontinuerlig valideringsproces gennem hele udviklingen. Automatiseret, politikdrevet scanning fanger sårbarheder tidligt, håndhæver løbende overholdelse og danner grundlaget for sikker softwarelevering. Den næste enhed undersøger specifikke SCA-værktøjer, og hvordan man evaluerer deres muligheder for din organisations behov.