Post-Log4j Security: What Changes Now

what_we_learned:
  most_organizations:
    - Didn't know Log4j was in their stack
    - Couldn't quickly inventory affected systems
    - Relied on manual searches
    - Discovered transitive dependencies painfully

  common_questions:
    - "Do we use Log4j?"
    - "Which version?"
    - "Which systems?"
    - Time to answer: Days or weeks

  impact:
    - Delayed patching
    - Incomplete remediation
    - Unknown exposure duration

supply_chain_facts:
  modern_apps:
    - Hundreds of dependencies
    - Multiple levels deep (transitive)
    - Mix of corporate and community maintained
    - Varying security practices

  log4j_specifics:
    - Direct dependency: Easy to find
    - Transitive: Buried in dep tree
    - Bundled in JARs: Invisible to manifest
    - Vendor software: Outside your control

sbom_value:
  definition: |
    A complete list of components, libraries, and
    modules in a software artifact

  enables:
    - Quick vulnerability assessment
    - Dependency tracking
    - License compliance
    - Supply chain visibility

  standards:
    - SPDX (ISO standard)
    - CycloneDX
    - SWID tags

# Generate SBOM with Syft
syft packages ./my-app -o spdx-json > sbom.spdx.json
syft packages ./my-app -o cyclonedx-json > sbom.cyclonedx.json

# For container images
syft packages registry.example.com/my-app:v1.0 -o cyclonedx-json

# Scan SBOM for vulnerabilities
grype sbom:sbom.cyclonedx.json

# CI/CD integration
name: Build and SBOM

jobs:
  build:
    steps:
      - name: Build artifact
        run: ./build.sh

      - name: Generate SBOM
        uses: anchore/sbom-action@v0
        with:
          artifact-name: sbom.cyclonedx.json

      - name: Scan for vulnerabilities
        uses: anchore/scan-action@v3
        with:
          sbom: sbom.cyclonedx.json
          fail-build: true
          severity-cutoff: high

sbom_practices:
  generation:
    - Generate at build time
    - Include in release artifacts
    - Versioned with releases

  storage:
    - Artifact repository
    - Dedicated SBOM registry
    - Attached to container images

  tracking:
    - Database of SBOMs by version
    - Query capability for components
    - Alerting on new vulnerabilities

# GitHub Advanced Security
name: Dependency Review

on: [pull_request]

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/dependency-review-action@v3
        with:
          fail-on-severity: high

# Snyk integration
name: Snyk Security

on: push

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=high

dependency_policies:
  allowed_licenses:
    - MIT
    - Apache-2.0
    - BSD-2-Clause
    - BSD-3-Clause

  blocked:
    - Known vulnerable versions
    - Deprecated packages
    - GPL in proprietary code (if applicable)

  requirements:
    - All dependencies scanned
    - No critical vulnerabilities
    - Regular update cadence

vendor_security_questions:
  dependency_management:
    - Do you maintain an SBOM?
    - How do you track vulnerabilities?
    - What's your patching cadence?

  incident_response:
    - How will you notify us of vulnerabilities?
    - What's your response time for critical issues?
    - Do you have a security contact?

  transparency:
    - Can you share your SBOM?
    - What open source do you use?
    - When was your last security audit?

vendor_monitoring:
  track:
    - Security advisories
    - Patch releases
    - CVE databases for vendor products

  automate:
    - Subscribe to security mailing lists
    - Monitor vendor status pages
    - Use vulnerability databases (NVD)

patching_capability:
  requirements:
    - Can deploy to production in hours, not days
    - Automated testing gates
    - Rollback capability
    - Multi-environment pipeline

  blockers:
    - Manual approval gates
    - Weekly deployment windows
    - Manual testing requirements
    - Fear of change

# Renovate configuration
extends:
  - config:base
  - :dependencyDashboard

packageRules:
  # Security updates: auto-merge if tests pass
  - matchUpdateTypes: [patch]
    matchCurrentVersion: "!/^0/"
    automerge: true

  # Group minor updates
  - matchUpdateTypes: [minor]
    groupName: minor-updates

  # Major updates: require review
  - matchUpdateTypes: [major]
    dependencyDashboardApproval: true

vulnerabilityAlerts:
  enabled: true
  labels: [security]

security_responsibilities:
  developers:
    - Update dependencies regularly
    - Review security alerts
    - Fix vulnerabilities in their code

  security_team:
    - Set policies and standards
    - Provide tools and training
    - Handle complex assessments

  platform_team:
    - Integrate security scanning
    - Maintain secure defaults
    - Enable rapid deployment

  leadership:
    - Prioritize security work
    - Fund tooling and training
    - Support rapid response

vulnerability_response_plan:
  preparation:
    - Asset inventory maintained
    - SBOM for all systems
    - Rapid deployment capability
    - Communication templates ready

  response:
    - Identify affected systems (SBOM query)
    - Assess exposure and risk
    - Patch or mitigate
    - Verify remediation

  communication:
    - Internal: Engineering, leadership
    - External: Customers if affected
    - Regulatory: If required