AD2005: DoNotShipVulnerableBinaries¶

Summary¶

Description¶

Binaries should not be shipped if they contain known security vulnerabilities. This rule checks the binary against vulnerability databases to identify known issues.

How It Works¶

The rule checks:

1. Binary hashes against known vulnerable binary databases
2. Version information for known vulnerable versions
3. Embedded metadata indicating vulnerable configurations

Why This Matters¶

Shipping known vulnerable binaries exposes users to exploitation with publicly available attack techniques.

Risk Assessment¶

Vulnerability Timeline¶

Vulnerability Discovered
    ↓
CVE Assigned (Public Knowledge)
    ↓
Exploit Developed (Attackers Ready)
    ↓
Your Users at Risk (Every Day You Ship Vulnerable Binary)
    ↓
Patch Applied (Risk Mitigated)

Compliance Requirements¶

Performance and Resolution¶

Performance Considerations¶

Addressing vulnerable binaries has no runtime performance penalty. The work is entirely in the patching and rebuild process:

In many cases, updated versions may include performance improvements alongside security fixes.

Resolution Steps¶

1. Identify the Vulnerability¶

Examine the CVE details and determine the affected component:

# Get CVE information
curl https://nvd.nist.gov/vuln/detail/CVE-XXXX-YYYY

# Check affected version ranges
# Look for: "Affected versions: < X.Y.Z"

2. Check Current Binary Version¶

# Windows - check file properties
(Get-Item binary.exe).VersionInfo | Format-List

# Check embedded version strings
strings binary.exe | Select-String -Pattern "version|[0-9]+\.[0-9]+\.[0-9]+"

# Linux - check binary metadata
file binary
strings binary | grep -iE "version|[0-9]+\.[0-9]+\.[0-9]+"

3. Update to Patched Version¶

For in-house builds:

# Pull latest source with security fix
git pull origin main
git checkout v2.1.5  # Known patched version

# Rebuild with current toolchain
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build

For third-party binaries:

# Download updated version from vendor
# Verify checksum/signature before deployment
sha256sum vendor-binary-2.1.5.zip
gpg --verify vendor-binary-2.1.5.zip.sig

4. Verify the Vulnerability is Resolved¶

# Re-scan the patched binary
grype patched-binary

# Confirm version update
strings patched-binary | grep -i version

CI/CD Integration¶

Block vulnerable binaries from reaching production:

# GitHub Actions example
name: Security Gate
on: [push, pull_request]

jobs:
  vulnerability-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
        with:
          persist-credentials: false

      - name: Build
        run: cmake --build build/

      - name: Scan for vulnerabilities
        run: |
          # Fail on critical or high severity CVEs
          grype ./build/output/ --fail-on high

      - name: Run BinSkim analysis
        run: |
          aldur analyze ./build/output/ --format sarif --output results.sarif

      - name: Upload security results
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: results.sarif

Azure DevOps Integration¶

- task: CmdLine@2
  displayName: 'Vulnerability Scan'
  inputs:
    script: |
      grype $(Build.ArtifactStagingDirectory) --fail-on critical
  continueOnError: false

Vulnerability Monitoring¶

Set up continuous monitoring for new CVEs:

Response Timeframes¶