Log4Shell — Lessons from the Worst Vulnerability of the Decade

December 9, 2021, Friday afternoon. CVE-2021-44228 — Log4Shell. A critical RCE vulnerability in Apache Log4j, a library present in virtually every Java application. CVSS 10.0. A weekend nobody will forget.

72 Hours of Crisis Mode¶

Friday evening: identifying all systems with Log4j. The problem? We didn’t know exactly where Log4j was — a transitive dependency that you don’t use directly, but it’s there through other libraries.

Saturday: scanning all repositories, Docker images, production deployments. Sunday: patching critical systems. Monday: completing the rest of the patching.

What We Didn’t Have: SBOM¶

Software Bill of Materials — a list of all components and dependencies. If we’d had an SBOM for every product, the answer to “where do we have Log4j?” would have taken minutes instead of hours.

What We Implemented After Log4Shell¶

• SBOM generation — Syft for container images, CycloneDX for Java projects
• Dependency scanning — Trivy in the CI/CD pipeline, blocking builds with critical CVEs
• Runtime protection — Falco for detecting suspicious activity in containers
• Incident response playbook — a documented procedure for supply chain vulnerabilities

Supply Chain Security Is a Necessity¶

Log4Shell showed that you don’t know what’s running in your systems. SBOM, dependency scanning, and proactive dependency monitoring are no longer nice-to-have — they’re must-have.