Scanners for Software Supply Chain Security¶

Scanner Types in the Supply Chain¶

Security scanning tools target different parts of the software supply chain, each addressing specific risks and vulnerabilities:

graph TD
    classDef scanner fill:#3498db, stroke:#333, stroke-width:1px, color:white
    classDef area fill:#2ecc71, stroke:#333, stroke-width:1px

    A[Security Scanner Types]:::scanner

    A --> B[Source Code<br/>Analysis]:::scanner
    B --> B1[SAST]:::area
    B --> B2[Secret Scanning]:::area
    B --> B3[Code Quality]:::area
    B --> B4[Secure Coding<br/>Standards]:::area

    A --> C[Dependency<br/>Analysis]:::scanner
    C --> C1[SCA]:::area
    C --> C2[License<br/>Compliance]:::area
    C --> C3[SBOM<br/>Generation]:::area

    A --> D[Build & Package<br/>Analysis]:::scanner
    D --> D1[Container<br/>Scanning]:::area
    D --> D2[Binary<br/>Analysis]:::area
    D --> D3[Integrity<br/>Verification]:::area

    A --> E[Runtime<br/>Analysis]:::scanner
    E --> E1[DAST]:::area
    E --> E2[IAST]:::area
    E --> E3[Penetration<br/>Testing]:::area

    A --> F[Infrastructure<br/>Analysis]:::scanner
    F --> F1[IaC Scanning]:::area
    F --> F2[Cloud Security<br/>Posture]:::area
    F --> F3[Configuration<br/>Analysis]:::area

    click B1 "#static-application-security-testing-sast" "View SAST tools"
    click C1 "#software-composition-analysis-sca" "View SCA tools"
    click D1 "#container-security-scanners" "View Container scanners"

    style A stroke-width:3px

Static Application Security Testing (SAST)¶

Implementation Example: Semgrep in CI/CD¶

# GitHub Actions workflow for Semgrep SAST scanning
name: Semgrep SAST Scan

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

jobs:
  semgrep:
    name: Static Analysis
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Semgrep Scan
        uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/default
            p/security-audit
            p/r2c-security-audit
            p/secrets
            p/owasp-top-ten
          generateSarif: "1"
        env:
          SEMGREP_APP_TOKEN: ${{ secrets.SEMGREP_APP_TOKEN }}

      - name: Upload SARIF file
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: semgrep.sarif
          wait-for-processing: true

SAST Strengths and Limitations¶

Software Composition Analysis (SCA)¶

How SCA Works¶

1. Dependency Discovery: Identifies all direct and transitive dependencies
2. Vulnerability Matching: Checks components against vulnerability databases like NVD
3. License Analysis: Identifies licensing issues that may pose legal risks
4. Policy Enforcement: Applies organizational policies to dependency usage
5. SBOM Generation: Creates a comprehensive bill of materials

Key Features to Look For¶

• Dependency Tree Visualization: Graphical representation of dependencies
• Vulnerability Path Tracing: Identifies how vulnerabilities are introduced
• Remediation Guidance: Suggests fixed versions or alternative packages
• Automated PR Creation: Automatically creates pull requests to fix vulnerabilities
• Developer Tooling Integration: Integrates with IDEs and development workflows
• License Compliance: Ensures open source licenses align with organizational policies

Popular SCA Tools Comparison¶

Implementation Example: OWASP Dependency-Check¶

# Running Dependency-Check on a Java project

# Download and extract Dependency-Check
curl -L https://github.com/jeremylong/DependencyCheck/releases/download/v7.4.0/dependency-check-7.4.0-release.zip -o dc.zip
unzip dc.zip

# Run the scan
./dependency-check/bin/dependency-check.sh \
  --project "My Project" \
  --scan "/path/to/application" \
  --enableExperimental \
  --out "/path/to/reports" \
  --format "ALL"

# Maven plugin configuration
<plugin>
  <groupId>org.owasp</groupId>
  <artifactId>dependency-check-maven</artifactId>
  <version>7.4.0</version>
  <configuration>
    <failBuildOnCVSS>8</failBuildOnCVSS>
    <suppressionFiles>
      <suppressionFile>owasp-suppressions.xml</suppressionFile>
    </suppressionFiles>
  </configuration>
  <executions>
    <execution>
      <goals>
        <goal>check</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Container Security Scanners¶

# Example: Scanning with Trivy
# Install Trivy
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin v0.37.3

# Basic image scan
trivy image alpine:latest

# Comprehensive scan with SBOM generation
trivy image --format json \
  --output results.json \
  --list-all-pkgs \
  --scanners vuln,secret,config \
  --generate-sbom cyclonedx \
  --output-sbom-file sbom.json \
  mycompany/myapp:latest

# Scan with policy enforcement
trivy image --exit-code 1 \
  --severity HIGH,CRITICAL \
  mycompany/myapp:latest

Container Scanning Best Practices¶

1. Scan Base Images: Verify security of base images before building upon them
2. Implement Registry Scanning: Scan images automatically when pushed to registries
3. Use Admission Controllers: Block deployment of vulnerable containers in Kubernetes
4. Version Control Images: Use specific image tags rather than "latest"
5. Minimize Image Size: Reduce attack surface by using minimal images
6. Layer Analysis: Understand how vulnerabilities are introduced through layers
7. Regular Rescanning: Continuously monitor for newly discovered vulnerabilities

Kubernetes Admission Control Integration¶

# Example: Trivy-Operator deployment in Kubernetes
apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: trivy-operator
  namespace: cattle-system
spec:
  chart: trivy-operator
  repo: https://aquasecurity.github.io/helm-charts/
  targetNamespace: trivy-system
  valuesContent: |-
    trivy:
      ignoreUnfixed: true
    operator:
      policies:
        vulnerability:
          failOnSeverity: CRITICAL
          ignoreUnfixed: true
    vulnerabilityReports:
      scanner:
        trivy:
          resources:
            requests:
              cpu: 100m
              memory: 100M
            limits:
              cpu: 500m
              memory: 500M

Binary Analysis Tools¶

Binary analysis tools examine compiled applications and components to identify vulnerabilities and security issues without access to source code. These are particularly important for:

• Verifying Third-Party Components: Validating the security of precompiled libraries
• Legacy Code Analysis: Examining older systems where source code may be unavailable
• Supply Chain Verification: Ensuring final artifacts match expected security properties

Infrastructure as Code (IaC) Scanners¶

Common IaC Security Issues Detected¶

1. Excessive Permissions: Over-privileged roles and policies
2. Insecure Network Configurations: Open security groups, excessive ports
3. Unencrypted Resources: Missing encryption for data at rest or in transit
4. Authentication Weaknesses: Insecure authentication mechanisms
5. Logging Deficiencies: Insufficient audit trails or monitoring
6. Non-compliance: Violations of industry standards and regulations

Popular IaC Scanning Tools¶

# Install Checkov
pip install checkov

# Scan Terraform directory
checkov -d /path/to/terraform/files

# Scan Kubernetes manifests
checkov -d /path/to/kubernetes/manifests

# Creating a custom policy in Python
cat > custom_policy.py << 'EOL'
from checkov.common.models.enums import CheckResult, CheckCategories
from checkov.terraform.checks.resource.base_resource_check import BaseResourceCheck

class S3BucketMFADelete(BaseResourceCheck):
    def __init__(self):
        name = "Ensure S3 bucket has MFA delete enabled"
        id = "CKV_AWS_S3_MFA_DELETE"
        supported_resources = ['aws_s3_bucket']
        categories = [CheckCategories.S3]
        super().__init__(name=name, id=id, 
                         categories=categories,
                         supported_resources=supported_resources)

    def scan_resource_conf(self, conf):
        if 'versioning' in conf.keys():
            versioning = conf['versioning'][0]
            if 'mfa_delete' in versioning.keys():
                if versioning['mfa_delete'][0]:
                    return CheckResult.PASSED
        return CheckResult.FAILED
EOL

# Run with custom policy
checkov -d /path/to/terraform/files --external-checks-dir .

Secret Scanning Tools¶

Secret scanning tools identify leaked credentials, API keys, tokens, and other sensitive data within code, configuration files, and repositories. Preventing secrets from entering the supply chain is critical for security.

Key Secret Scanning Capabilities¶

1. Pattern Detection: Identifies common secret patterns like API keys and tokens
2. Entropy Analysis: Detects high-entropy strings that may be encrypted secrets
3. Validation: Verifies found secrets against known formats (e.g., AWS key format)
4. Pre-commit Hooks: Blocks commits containing secrets
5. Historical Scanning: Examines repository history for previously committed secrets

Popular Secret Scanning Tools¶

• GitLeaks: Open-source tool for discovering secrets in git repositories
• Trufflehog: Searches through git repositories for high entropy strings and secrets
• GitGuardian: Monitors public and private repositories for leaked secrets
• GitHub Secret Scanning: Built-in scanning for GitHub repositories
• Whispers: Identifies hardcoded secrets and dangerous behaviors in source code
• Detect Secrets: Airbnb's tool for detecting secrets in code

Implementation Example: GitLeaks Pre-Commit Hook¶

#!/bin/bash
# Pre-commit hook to prevent secrets from being committed

# Install gitleaks if not already installed
if ! command -v gitleaks &> /dev/null; then
    echo "Installing gitleaks..."
    curl -sSfL https://raw.githubusercontent.com/zricethezav/gitleaks/master/install.sh | sh -s -- -b $(go env GOPATH)/bin v8.10.0
fi

# Run gitleaks on staged files
git diff --cached --name-only | xargs gitleaks detect --no-git -v

# If gitleaks found issues, prevent the commit
if [ $? -eq 1 ]; then
    echo "Error: Potential secrets found in commit"
    echo "Please remove any API keys, tokens, or credentials"
    exit 1
fi

exit 0

# GitHub Actions workflow for secret scanning
name: Secret Scanning

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

jobs:
  gitleaks:
    name: GitLeaks
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: GitLeaks Scan
        uses: zricethezav/gitleaks-action@master
        with:
          config-path: .gitleaks.toml

Dynamic Application Security Testing (DAST)¶

API Security Testing¶

With the proliferation of APIs in modern applications, specialized tools for API security testing have emerged:

• API-focused DAST: Tools like Insomnia, Postman, and APIsec for API testing
• API Schema Validation: Ensuring API implementations match their specifications
• Fuzzing: Testing APIs with unexpected or malformed inputs
• Authentication Testing: Verifying API authentication mechanisms

Integration with CI/CD¶

# GitHub Actions workflow for OWASP ZAP scanning
name: DAST Scan with ZAP

on:
  workflow_dispatch:
  schedule:
    - cron: '0 0 * * 0'  # Weekly scan on Sundays at midnight

jobs:
  zap-scan:
    name: OWASP ZAP Scan
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: ZAP Scan
        uses: zaproxy/action-full-scan@v0.4.0
        with:
          target: 'https://www.example.com'
          rules_file_name: 'zap-rules.tsv'
          cmd_options: '-a -j'

      - name: Upload ZAP Report
        uses: actions/upload-artifact@v3
        with:
          name: ZAP Full Scan Report
          path: |
            zap-full-scan-report.html
            zap-full-scan-report.json

Scanner Integration Strategy¶

To maximize the effectiveness of security scanners in your supply chain, integrate them at multiple points:

sequenceDiagram
    participant Dev as Developer
    participant IDE as IDE Integration
    participant VCS as Version Control
    participant CI as CI/CD Pipeline
    participant Reg as Registry/Repository
    participant Deploy as Deployment
    participant Run as Runtime

    Note over Dev,Run: Scanner Integration Points

    Dev->>IDE: Write code
    IDE->>IDE: SAST & secrets scanning (real-time)
    IDE->>VCS: Commit code
    VCS->>VCS: Pre-commit hooks<br>(secrets, linting)
    VCS->>CI: Trigger build

    CI->>CI: SAST (comprehensive)
    CI->>CI: SCA (dependencies)
    CI->>CI: IaC scanning
    CI->>CI: Container builds
    CI->>CI: Container scanning
    CI->>Reg: Push artifacts

    Reg->>Reg: Registry scanning
    Reg->>Reg: Signature verification

    Deploy->>Deploy: Deployment validation
    Deploy->>Run: Deploy to environment

    Run->>Run: Runtime scanning
    Run->>Run: DAST & IAST
    Run->>Run: Continuous monitoring

    Note over CI,Reg: Attestations & SBOMs generated
    Note over Deploy,Run: Policy enforcement

Implementation Considerations¶

Managing Scanner Results¶

Key Challenges in Scanner Result Management¶

1. False Positives: Tools often flag issues that aren't real vulnerabilities
2. Alert Fatigue: Too many alerts lead to important issues being overlooked
3. Prioritization: Determining which issues to fix first is challenging
4. Remediation Guidance: Developers need clear guidance on how to fix issues
5. Tracking Progress: Monitoring vulnerability trends over time

Best Practices for Scanner Result Management¶

// Example vulnerability management policy in code
public class VulnerabilityPolicy {
    public enum Severity { CRITICAL, HIGH, MEDIUM, LOW }

    private static Map<Severity, Integer> remediation_sla = Map.of(
        Severity.CRITICAL, 1,  // 1 day
        Severity.HIGH, 7,      // 7 days
        Severity.MEDIUM, 30,   // 30 days
        Severity.LOW, 90       // 90 days
    );

    private static Map<Severity, Boolean> block_build = Map.of(
        Severity.CRITICAL, true,
        Severity.HIGH, true,
        Severity.MEDIUM, false,
        Severity.LOW, false
    );

    public static boolean shouldBlockBuild(Severity severity) {
        return block_build.get(severity);
    }

    public static int getRemediationDays(Severity severity) {
        return remediation_sla.get(severity);
    }
}

1. Automation and Integration
2. Automatically create tickets for validated findings
3. Link scanning results to code review systems
4. Provide dashboards for visibility into security posture

Example: Scanner Integration Architecture¶

flowchart TD
    classDef tools fill:#3498db, stroke:#333, stroke-width:1px, color:white
    classDef platforms fill:#2ecc71, stroke:#333, stroke-width:1px
    classDef processes fill:#e74c3c, stroke:#333, stroke-width:1px, color:white

    A[Multiple Security Scanner Tools]:::tools --> B[Results Aggregation Layer]:::platforms
    B --> C[Central Vulnerability Database]:::platforms
    C --> D[Deduplication & Enrichment]:::processes
    D --> E[Risk Scoring & Prioritization]:::processes
    E --> F[Issue Tracking Integration]:::platforms
    F --> G[Developer Assignment]:::processes
    G --> H[Remediation]:::processes
    H --> I[Verification Scan]:::tools
    I --> J{Issue Fixed?}
    J -->|Yes| K[Close Issue]:::processes
    J -->|No| G

    C --> L[Security Dashboards]:::platforms
    C --> M[Compliance Reporting]:::platforms
    C --> N[Trend Analysis]:::platforms

Case Study: Implementing Scanner Strategy in a CI/CD Pipeline¶

Scanner Selection¶

1. SAST: SonarQube for Java and JavaScript analysis
2. SCA: OWASP Dependency-Check for Java dependencies, npm audit for JavaScript
3. Container Security: Trivy for container scanning
4. Secret Detection: GitLeaks for secret scanning
5. IaC Security: Checkov for Terraform and Kubernetes manifests
6. DAST: OWASP ZAP for deployed application testing

Pipeline Implementation¶

# Example multi-stage security scanning pipeline
name: Security Pipeline

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

jobs:
  code-security:
    name: Code Security Checks
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Set up JDK
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Secret scanning
        uses: gitleaks/gitleaks-action@v2

      - name: SonarQube scan
        uses: SonarSource/sonarcloud-github-action@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

      - name: Dependency check
        run: |
          mvn org.owasp:dependency-check-maven:check
          npm audit --production

      - name: Upload reports
        uses: actions/upload-artifact@v3
        with:
          name: security-reports
          path: |
            target/dependency-check-report.html
            npm-audit.json

  infrastructure-security:
    name: Infrastructure Security
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2

      - name: Terraform Format Check
        run: terraform fmt -check -recursive

      - name: Checkov IaC scan
        uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform/
          framework: terraform
          output_format: github_failed_only

      - name: Kubernetes manifests scan
        uses: bridgecrewio/checkov-action@master
        with:
          directory: k8s/
          framework: kubernetes
          output_format: github_failed_only

  container-security:
    name: Container Security
    runs-on: ubuntu-latest
    needs: [code-security, infrastructure-security]
    steps:
      - uses: actions/checkout@v3

      - name: Build container
        run: docker build -t myapp:${{ github.sha }} .

      - name: Trivy scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'myapp:${{ github.sha }}'
          format: 'sarif'
          output: 'trivy-results.sarif'
          severity: 'CRITICAL,HIGH'

      - name: Upload Trivy scan results
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: 'trivy-results.sarif'

      - name: Generate SBOM
        uses: anchore/sbom-action@v0.13.3
        with:
          image: myapp:${{ github.sha }}
          format: spdx-json
          output-file: sbom.spdx.json

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

  dast-scan:
    name: DAST Scanning
    runs-on: ubuntu-latest
    needs: [container-security]
    if: github.ref == 'refs/heads/main'
    environment: staging
    steps:
      - uses: actions/checkout@v3

      - name: Deploy to test environment
        run: |
          # Deploy application to testing environment
          echo "Deploying to test environment"

      - name: OWASP ZAP Scan
        uses: zaproxy/action-baseline@v0.7.0
        with:
          target: 'https://staging.example.com'
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a'

Emerging Trends in Software Supply Chain Scanning¶

Conclusion¶

1. Implement Multiple Scanner Types: Use complementary tools covering different aspects of the supply chain
2. Shift Security Left: Integrate scanners early in the development process
3. Focus on Developer Experience: Provide clear, actionable feedback with minimal noise
4. Automate Extensively: Integrate scanning throughout CI/CD pipelines
5. Manage Results Effectively: Prioritize findings based on risk and provide clear remediation guidance
6. Establish Policies: Define clear requirements for security scanning and vulnerability remediation
7. Monitor Continuously: Regularly scan existing artifacts for newly discovered vulnerabilities

By implementing a robust scanning strategy across the software supply chain, organizations can significantly reduce security risks, maintain compliance, and build trust in their software products.