Dependency Scanning and Software Composition Analysis

When Log4Shell Hit: Managing 200+ Microservices Under Attack

December 9, 2021, 11:47 PM. I was about to go to bed when my phone exploded with alerts. A critical zero-day vulnerability had been discovered in Log4j, one of the most widely used Java logging libraries. Within hours, it was being actively exploited in the wild. CVE-2021-44228. CVSS score: 10.0. Critical.

The problem? We had over 200 microservices, and I had no idea which ones used Log4j. Some were Java services we wrote. Others were third-party Docker images. Some dependencies were obvious in our pom.xml files, but what about transitive dependencies—the dependencies of our dependencies?

By 2 AM, I had a grim realization: we had no comprehensive inventory of what was actually running in production. Our dependency management was reactive, not proactive. We knew what we installed, but not what came along for the ride.

That night turned into a three-day firefight. We patched 47 services directly using Log4j. But the real shock came when dependency scanning revealed 23 additional services vulnerable through transitive dependencies—libraries we didn't even know we were using.

This article is about the dependency scanning and Software Composition Analysis (SCA) strategy I built after Log4Shell. Never again would I wake up to an "unknown surface area" crisis.

What You'll Learn

• Understanding Software Composition Analysis (SCA)

• Implementing automated dependency scanning

• Managing transitive dependencies

• Vulnerability prioritization and remediation

• License compliance automation

• Preventing dependency confusion attacks

• Building a continuous dependency monitoring system

The Hidden Iceberg of Dependencies

Modern applications are built on layers of dependencies. When you npm install express, you're not just installing Express—you're installing its 50+ dependencies, and their dependencies, and so on.

The dependency iceberg:

• Direct dependencies: What you explicitly install

• Transitive dependencies: Dependencies of your dependencies

• Dev dependencies: Testing, building tools

• System dependencies: OS packages, container base layers

What is Software Composition Analysis (SCA)?

SCA is the automated process of identifying and analyzing all components (open source and third-party) in your application.

SCA answers critical questions:

• What dependencies am I using?

• What versions are installed?

• Are there known vulnerabilities?

• What licenses apply?

• Are there newer, safer versions?

• Where are dependencies used in my code?

Implementing Dependency Scanning

GitLab Dependency Scanning

# .gitlab-ci.yml
stages:
  - build
  - test
  - security
  - deploy

variables:
  # Fail pipeline on high/critical vulnerabilities
  DS_EXCLUDED_PATHS: "spec, test, tests, tmp, node_modules"
  SECURE_LOG_LEVEL: "info"

dependency_scanning:
  stage: security
  variables:
    DS_ANALYZER_IMAGE_TAG: "latest"
  artifacts:
    reports:
      dependency_scanning: gl-dependency-scanning-report.json
    paths:
      - gl-dependency-scanning-report.json
    expire_in: 30 days
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
    - if: '$CI_MERGE_REQUEST_ID'

# Custom vulnerability threshold check
check_dependency_vulnerabilities:
  stage: security
  image: alpine:latest
  before_script:
    - apk add --no-cache jq
  script:
    - |
      CRITICAL=$(cat gl-dependency-scanning-report.json | jq '[.vulnerabilities[] | select(.severity == "Critical")] | length')
      HIGH=$(cat gl-dependency-scanning-report.json | jq '[.vulnerabilities[] | select(.severity == "High")] | length')
      
      echo "Found $CRITICAL critical and $HIGH high severity vulnerabilities"
      
      if [ "$CRITICAL" -gt 0 ]; then
        echo "❌ CRITICAL vulnerabilities found! Pipeline failed."
        cat gl-dependency-scanning-report.json | jq '.vulnerabilities[] | select(.severity == "Critical") | {name: .name, version: .version, cve: .identifiers[0].value}'
        exit 1
      fi
      
      if [ "$HIGH" -gt 5 ]; then
        echo "⚠️ Too many HIGH vulnerabilities ($HIGH > 5 threshold)"
        exit 1
      fi
      
      echo "✅ Dependency vulnerabilities within acceptable thresholds"
  dependencies:
    - dependency_scanning
  needs:
    - dependency_scanning

Snyk Integration for Deep Analysis

# .gitlab-ci.yml - Snyk integration
snyk_test:
  stage: security
  image: snyk/snyk:node
  before_script:
    - snyk auth $SNYK_TOKEN
  script:
    # Test for vulnerabilities
    - snyk test --json > snyk-report.json || true
    
    # Monitor project in Snyk dashboard
    - snyk monitor --project-name="${CI_PROJECT_NAME}" --org="${SNYK_ORG_ID}"
    
    # Generate detailed report
    - snyk test --severity-threshold=high --json-file-output=snyk-detailed.json
    
    # Check results
    - |
      CRITICAL_ISSUES=$(cat snyk-report.json | jq '.vulnerabilities | map(select(.severity == "critical")) | length')
      if [ "$CRITICAL_ISSUES" -gt 0 ]; then
        echo "❌ Found $CRITICAL_ISSUES critical vulnerabilities"
        cat snyk-report.json | jq '.vulnerabilities[] | select(.severity == "critical") | {package: .packageName, version: .version, cve: .identifiers.CVE[0]}'
        exit 1
      fi
  artifacts:
    reports:
      dependency_scanning: snyk-report.json
    paths:
      - snyk-report.json
      - snyk-detailed.json
    expire_in: 30 days
  allow_failure: false

Multi-Language Scanning Strategy

# .gitlab-ci.yml - Multi-language project
include:
  - template: Security/Dependency-Scanning.gitlab-ci.yml

variables:
  DS_JAVA_VERSION: 17
  DS_PYTHON_VERSION: 3
  DS_EXCLUDED_ANALYZERS: "gemnasium-maven, gemnasium-python"

# Node.js dependencies
scan_nodejs:
  stage: security
  image: node:18-alpine
  before_script:
    - npm ci
  script:
    - npm audit --json > npm-audit.json
    - npx audit-ci --config audit-ci.json
  artifacts:
    paths:
      - npm-audit.json

# Python dependencies
scan_python:
  stage: security
  image: python:3.11-alpine
  before_script:
    - pip install safety pip-audit
  script:
    # Safety check
    - safety check --json > safety-report.json || true
    
    # pip-audit check
    - pip-audit --desc --format json > pip-audit.json || true
    
    # Parse results
    - |
      SAFETY_VULNS=$(cat safety-report.json | jq 'length')
      echo "Safety found $SAFETY_VULNS vulnerabilities"
  artifacts:
    paths:
      - safety-report.json
      - pip-audit.json

# Java dependencies  
scan_java:
  stage: security
  image: maven:3.9-eclipse-temurin-17
  script:
    - mvn org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7
    - cat target/dependency-check-report.json
  artifacts:
    paths:
      - target/dependency-check-report.json

Real Log4Shell Response Strategy

Here's exactly how we handled the Log4Shell crisis:

Step 1: Immediate Discovery

#!/bin/bash
# scripts/find-log4j.sh

echo "🔍 Scanning for Log4j vulnerabilities..."

# Search in source code
echo "\n=== Searching source code ==="
find . -name "pom.xml" -o -name "build.gradle" | xargs grep -l "log4j"

# Search in Docker images
echo "\n=== Scanning Docker images ==="
docker images --format "{{.Repository}}:{{.Tag}}" | while read image; do
  echo "Scanning $image..."
  docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
    aquasec/trivy image --severity CRITICAL,HIGH \
    --pkg-types library \
    $image | grep log4j
done

# Search in running containers
echo "\n=== Checking running containers ==="
kubectl get pods --all-namespaces -o json | \
  jq -r '.items[] | .metadata.namespace + "/" + .metadata.name' | \
  while read pod; do
    echo "Checking $pod..."
    kubectl exec -n $(echo $pod | cut -d/ -f1) $(echo $pod | cut -d/ -f2) -- \
      find / -name "*log4j*.jar" 2>/dev/null | grep -v "Permission denied"
  done

# Check with Snyk
echo "\n=== Running Snyk scan ==="
snyk test --all-projects --detection-depth=6 --severity-threshold=critical

Step 2: Automated Remediation PR Creation

// scripts/create-remediation-prs.js
const { Octokit } = require('@octokit/rest');
const fs = require('fs');
const yaml = require('js-yaml');

class RemediationAutomation {
  constructor() {
    this.octokit = new Octokit({ auth: process.env.GITHUB_TOKEN });
    this.vulnReport = JSON.parse(fs.readFileSync('snyk-report.json'));
  }

  async createRemediationPRs() {
    const vulnerabilities = this.groupByPackage(this.vulnReport.vulnerabilities);
    
    for (const [packageName, vulns] of Object.entries(vulnerabilities)) {
      await this.createPR(packageName, vulns);
    }
  }

  groupByPackage(vulnerabilities) {
    return vulnerabilities.reduce((acc, vuln) => {
      const pkg = vuln.packageName;
      if (!acc[pkg]) acc[pkg] = [];
      acc[pkg].push(vuln);
      return acc;
    }, {});
  }

  async createPR(packageName, vulnerabilities) {
    const repo = process.env.GITHUB_REPOSITORY.split('/')[1];
    const owner = process.env.GITHUB_REPOSITORY.split('/')[0];
    
    // Determine fix version
    const fixVersion = this.determineFixVersion(vulnerabilities);
    
    // Create branch
    const branchName = `security/fix-${packageName}-${Date.now()}`;
    await this.createBranch(owner, repo, branchName);
    
    // Update package.json
    const packageJson = JSON.parse(fs.readFileSync('package.json'));
    packageJson.dependencies[packageName] = fixVersion;
    
    // Commit changes
    await this.commitFile(
      owner,
      repo,
      branchName,
      'package.json',
      JSON.stringify(packageJson, null, 2),
      `fix: upgrade ${packageName} to ${fixVersion} for security`
    );
    
    // Create PR
    const pr = await this.octokit.pulls.create({
      owner,
      repo,
      title: `🔒 Security: Fix ${vulnerabilities.length} vulnerabilities in ${packageName}`,
      head: branchName,
      base: 'main',
      body: this.generatePRBody(packageName, vulnerabilities, fixVersion)
    });
    
    // Add labels
    await this.octokit.issues.addLabels({
      owner,
      repo,
      issue_number: pr.data.number,
      labels: ['security', 'dependencies', 'automated']
    });
    
    console.log(`✅ Created PR #${pr.data.number} for ${packageName}`);
  }

  determineFixVersion(vulnerabilities) {
    // Get the minimum version that fixes all vulnerabilities
    const fixVersions = vulnerabilities
      .map(v => v.fixedIn)
      .flat()
      .filter(v => v);
    
    // Return highest version
    return fixVersions.sort().pop();
  }

  generatePRBody(packageName, vulnerabilities, fixVersion) {
    let body = `## 🔒 Security Fix\n\n`;
    body += `This PR upgrades \`${packageName}\` to version \`${fixVersion}\` to fix ${vulnerabilities.length} security vulnerabilities.\n\n`;
    body += `### Vulnerabilities Fixed\n\n`;
    
    vulnerabilities.forEach(v => {
      body += `- **${v.title}**\n`;
      body += `  - Severity: ${v.severity}\n`;
      body += `  - CVE: ${v.identifiers.CVE?.[0] || 'N/A'}\n`;
      body += `  - CVSS: ${v.cvssScore}\n`;
      body += `  - [More info](${v.url})\n\n`;
    });
    
    body += `### Testing\n\n`;
    body += `- [ ] Run full test suite\n`;
    body += `- [ ] Verify no breaking changes\n`;
    body += `- [ ] Deploy to staging\n`;
    body += `- [ ] Security scan passes\n\n`;
    
    body += `---\n`;
    body += `*Automatically generated by security remediation bot*`;
    
    return body;
  }
}

// Run
new RemediationAutomation().createRemediationPRs();

Step 3: Prioritized Rollout

# rollout-strategy.yml
patches:
  # Phase 1: Non-customer-facing services (2 hours)
  - priority: critical
    services:
      - internal-admin-api
      - batch-processor
      - analytics-engine
    rollout: immediate
    
  # Phase 2: Customer-facing with redundancy (6 hours)
  - priority: high
    services:
      - api-gateway
      - user-service
      - notification-service
    rollout: blue-green
    testing:
      - smoke-tests
      - integration-tests
    
  # Phase 3: Core payment systems (12 hours)
  - priority: high
    services:
      - payment-processor
      - billing-service
      - fraud-detection
    rollout: canary
    canary_steps:
      - 10%
      - 25%
      - 50%
      - 100%
    monitoring:
      - error-rate < 0.1%
      - latency-p99 < 500ms
      - payment-success-rate > 99.9%

Managing Transitive Dependencies

The hardest part of dependency management is transitive dependencies—the dependencies you didn't choose.

Dependency Tree Analysis

# Node.js
npm ls --all --depth=10 | grep -A 5 "log4j"

# Python
pip install pipdeptree
pipdeptree -p requests --graph-output png > dependency-graph.png

# Java
mvn dependency:tree -Dincludes=org.apache.logging.log4j

# Display only security vulnerabilities
mvn dependency:tree -Dverbose | grep -A 3 "conflict"

Forcing Dependency Versions

// package.json - Override transitive dependency
{
  "name": "payment-service",
  "dependencies": {
    "express": "^4.18.0"
  },
  "overrides": {
    // Force all transitive dependencies to use safe version
    "log4j": "2.17.1",
    "minimist": "^1.2.6",
    "json-schema": "^0.4.0"
  },
  "resolutions": {
    "**/log4j": "2.17.1",
    "**/lodash": "^4.17.21"
  }
}

<!-- pom.xml - Maven dependency management -->
<dependencyManagement>
  <dependencies>
    <!-- Force all log4j versions to safe version -->
    <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-core</artifactId>
      <version>2.17.1</version>
    </dependency>
    <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-api</artifactId>
      <version>2.17.1</version>
    </dependency>
  </dependencies>
</dependencyManagement>

Automated Dependency Updates

Dependabot Configuration

# .github/dependabot.yml
version: 2
updates:
  # Node.js dependencies
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
      time: "03:00"
    open-pull-requests-limit: 10
    reviewers:
      - "security-team"
    labels:
      - "dependencies"
      - "security"
    
    # Security updates only
    allow:
      - dependency-type: "direct"
        update-type: "security"
      - dependency-type: "indirect"
        update-type: "security"
    
    # Version update strategy
    versioning-strategy: increase-if-necessary
    
    # Ignore specific packages
    ignore:
      - dependency-name: "webpack"
        versions: ["5.x"]
    
    # Commit message prefix
    commit-message:
      prefix: "fix"
      prefix-development: "chore"
      include: "scope"

  # Docker dependencies
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"
    labels:
      - "docker"
      - "security"

  # GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Renovate Bot for Advanced Control

// renovate.json
{
  "extends": ["config:base"],
  "timezone": "America/New_York",
  "schedule": ["after 10pm", "before 5am"],
  
  "packageRules": [
    {
      "description": "Auto-merge security patches",
      "matchUpdateTypes": ["patch"],
      "matchPackagePatterns": ["*"],
      "automerge": true,
      "automergeType": "pr",
      "platformAutomerge": true
    },
    {
      "description": "Group security vulnerabilities",
      "matchDatasources": ["npm"],
      "vulnerabilityAlerts": {
        "enabled": true
      },
      "groupName": "Security vulnerabilities",
      "labels": ["security", "priority-high"]
    },
    {
      "description": "Separate major updates",
      "matchUpdateTypes": ["major"],
      "labels": ["breaking-change"],
      "reviewers": ["@senior-engineers"],
      "automerge": false
    },
    {
      "description": "Group AWS SDK updates",
      "matchPackagePatterns": ["^aws-sdk", "^@aws-sdk/"],
      "groupName": "AWS SDK",
      "schedule": ["every weekend"]
    }
  ],
  
  "vulnerabilityAlerts": {
    "enabled": true,
    "labels": ["security"],
    "assignees": ["@security-team"],
    "semanticCommits": "enabled",
    "commitMessagePrefix": "fix(security):"
  },
  
  "lockFileMaintenance": {
    "enabled": true,
    "schedule": ["before 5am on monday"]
  }
}

License Compliance

Dependencies come with licenses that have legal implications.

License Scanning with FOSSA

# .gitlab-ci.yml
license_scanning:
  stage: security
  image: fossas/fossa-cli:latest
  script:
    # Analyze project
    - fossa analyze
    
    # Check for license policy violations
    - fossa test
    
    # Generate report
    - fossa report attribution --json > fossa-attribution.json
  artifacts:
    paths:
      - fossa-attribution.json
  only:
    - main
    - merge_requests

Custom License Policy

# license-policy.yml
allowed_licenses:
  - MIT
  - Apache-2.0
  - BSD-2-Clause
  - BSD-3-Clause
  - ISC
  - 0BSD

restricted_licenses:
  # Requires attribution
  - CC-BY-4.0
  - CC-BY-SA-4.0
  
prohibited_licenses:
  # Copyleft licenses
  - GPL-2.0
  - GPL-3.0
  - AGPL-3.0
  # Commercial restrictions
  - SSPL
  - Elastic-2.0
  # Unknown/no license
  - UNLICENSED
  - UNKNOWN

exceptions:
  # Allow GPL for dev dependencies only
  - package: "webpack"
    license: "MIT"
    scope: "dev"

License Checker Script

// scripts/check-licenses.js
const checker = require('license-checker');
const yaml = require('js-yaml');
const fs = require('fs');

const policy = yaml.load(fs.readFileSync('license-policy.yml'));

checker.init({
  start: '.',
  production: true,
  json: true
}, (err, packages) => {
  if (err) {
    console.error(err);
    process.exit(1);
  }
  
  const violations = [];
  
  for (const [pkg, info] of Object.entries(packages)) {
    const license = info.licenses;
    
    if (policy.prohibited_licenses.includes(license)) {
      violations.push({
        package: pkg,
        license: license,
        severity: 'CRITICAL',
        message: `Prohibited license: ${license}`
      });
    } else if (policy.restricted_licenses.includes(license)) {
      violations.push({
        package: pkg,
        license: license,
        severity: 'WARNING',
        message: `Restricted license: ${license} - review required`
      });
    }
  }
  
  if (violations.length > 0) {
    console.error('\n❌ License Policy Violations:\n');
    violations.forEach(v => {
      console.error(`  [${v.severity}] ${v.package}`);
      console.error(`    ${v.message}\n`);
    });
    
    const critical = violations.filter(v => v.severity === 'CRITICAL');
    if (critical.length > 0) {
      process.exit(1);
    }
  } else {
    console.log('✅ All licenses comply with policy');
  }
});

Dependency Confusion Prevention

In 2021, security researcher Alex Birsan demonstrated dependency confusion attacks, where attackers publish malicious packages with the same name as internal packages.

Protection Strategy

// .npmrc - Scope to private registry
@mycompany:registry=https://npm.mycompany.com
registry=https://registry.npmjs.org

# Always authenticate for scoped packages
//npm.mycompany.com/:_authToken=${NPM_TOKEN}

# Prevent fallback to public registry
//npm.mycompany.com/:always-auth=true

# .gitlab-ci.yml - Verify package sources
verify_dependencies:
  stage: security
  script:
    - |
      npm ls --json | jq -r '.dependencies | to_entries[] | 
        select(.value.resolved | contains("mycompany") | not) | 
        .key' > external-deps.txt
      
      while read dep; do
        if [[ $dep == @mycompany/* ]]; then
          echo "❌ ERROR: Internal package from public registry: $dep"
          exit 1
        fi
      done < external-deps.txt

Continuous Dependency Monitoring

Real-Time Vulnerability Monitoring

// scripts/continuous-monitoring.js
const snyk = require('snyk');
const slack = require('@slack/webhook');

class DependencyMonitor {
  constructor() {
    this.webhook = new slack.IncomingWebhook(process.env.SLACK_WEBHOOK);
    this.checkInterval = 3600000; // 1 hour
  }

  async start() {
    console.log('🔍 Starting continuous dependency monitoring...');
    setInterval(() => this.check(), this.checkInterval);
    
    // Initial check
    await this.check();
  }

  async check() {
    try {
      const results = await snyk.test('.');
      
      if (results.vulnerabilities.length > 0) {
        await this.handleVulnerabilities(results.vulnerabilities);
      }
    } catch (error) {
      console.error('Monitoring error:', error);
    }
  }

  async handleVulnerabilities(vulnerabilities) {
    const critical = vulnerabilities.filter(v => v.severity === 'critical');
    const high = vulnerabilities.filter(v => v.severity === 'high');
    
    if (critical.length > 0 || high.length > 0) {
      await this.alertTeam({
        critical: critical.length,
        high: high.length,
        details: [...critical, ...high].slice(0, 5)
      });
    }
  }

  async alertTeam(summary) {
    const message = {
      text: '🚨 New security vulnerabilities detected!',
      blocks: [
        {
          type: 'header',
          text: {
            type: 'plain_text',
            text: '🚨 Security Alert: New Vulnerabilities'
          }
        },
        {
          type: 'section',
          fields: [
            {
              type: 'mrkdwn',
              text: `*Critical:* ${summary.critical}`
            },
            {
              type: 'mrkdwn',
              text: `*High:* ${summary.high}`
            }
          ]
        },
        {
          type: 'section',
          text: {
            type: 'mrkdwn',
            text: '*Top Vulnerabilities:*\n' + 
              summary.details.map(v => 
                `• ${v.packageName}@${v.version}: ${v.title}`
              ).join('\n')
          }
        },
        {
          type: 'actions',
          elements: [
            {
              type: 'button',
              text: {
                type: 'plain_text',
                text: 'View Full Report'
              },
              url: 'https://snyk.io/dashboard',
              style: 'danger'
            }
          ]
        }
      ]
    };
    
    await this.webhook.send(message);
  }
}

// Start monitoring
new DependencyMonitor().start();

Best Practices

1. Scan Early, Scan Often

# Scan on every commit
on:
  push:
  pull_request:
  schedule:
    - cron: '0 */6 * * *'  # Every 6 hours

2. Prioritize Ruthlessly

Not all vulnerabilities are equal. Use this matrix:

Severity	Exploitability	Priority
Critical	Active Exploits	P0 - Immediate
Critical	Proof of Concept	P1 - 24 hours
High	Active Exploits	P1 - 24 hours
High	Theoretical	P2 - 1 week
Medium	Any	P3 - 1 month
Low	Any	P4 - Backlog

3. Automate Patching for Low-Risk Updates

# Auto-merge patch versions
automerge:
  enabled: true
  conditions:
    - updateType: patch
    - tests.pass: true
    - security.vulnerabilities: 0

4. Maintain an Exception Process

# exceptions.yml
exceptions:
  - package: "old-legacy-package"
    version: "1.2.3"
    vulnerability: "CVE-2020-12345"
    reason: "No fix available, mitigated by WAF"
    mitigations:
      - WAF rule blocking exploit pattern
      - Not exposed to internet
    approved_by: "CISO"
    expires: "2024-06-01"
    review_frequency: quarterly

Key Takeaways

✅ Know your dependencies - All of them, including transitive ones ✅ Automate scanning - Every commit, every deployment ✅ Prioritize by risk - Not all CVEs require immediate action ✅ Automate updates - Let robots handle the boring stuff ✅ Monitor licenses - Legal compliance matters ✅ Prevent dependency confusion - Lock down your package sources ✅ Plan for zero-days - Have a response process ready

What's Next

Dependencies are just one part of your supply chain. In the next article, we'll dive into container security—scanning base images, hardening containers, and securing your container runtime.

---

Next Article: Container Security and Image Scanning →

---

Part of the DevSecOps 101 Series