Quick take
Stop buying scanners. Start building the muscle to answer “are we affected?” in hours, not days. SBOMs, CI scanning, and vendor accountability are table stakes now.
When Log4Shell dropped in December, every Slack channel I was in – across different companies, different industries – had the same question: “Do we use Log4j?” The number of teams that couldn’t answer that question within the first day was staggering. And these weren’t small shops. These were companies with security teams, compliance programs, and six-figure tool budgets.
Log4j wasn’t a novel exploit category. Remote code execution via deserialization has been around forever. What made it devastating was the combination of ubiquity (Log4j is everywhere in the Java ecosystem, including transitive dependencies three levels deep) and the total lack of dependency visibility in most organizations.
The real failure was operational, not technical
The vulnerability itself got patched quickly. The Apache team shipped fixes. The problem was everything that came after: figuring out which services were affected, which vendors used Log4j under the hood, who owned what, and how fast you could actually deploy a fix.
I watched teams burn an entire week just inventorying their own systems. Not patching. Inventorying. That’s the gap Log4j exposed. Not a missing firewall rule. A missing operational capability.
The teams that handled it well had three things in common:
- They knew what was running in production and who owned it.
- They could ship a patch to any service within hours, not days.
- They had relationships with vendors that included actual security SLAs.
Everything else was just damage control.
Dependency visibility isn’t optional anymore
A Software Bill of Materials (SBOM) should be a build artifact. Not a PDF someone generates for an audit. Not a spreadsheet in Confluence. A machine-readable file that ships with every release and can be queried programmatically.
If you can’t run a query like “which of our production services include log4j-core < 2.17?” and get an answer in minutes, you aren’t ready for the next one. It’s that simple.
The practical version:
- Generate an SBOM on every build. CycloneDX and SPDX are both fine formats.
- Store it alongside your build artifacts. Version it. Make it searchable.
- Include transitive dependencies. That’s where the surprises live.
- Treat it as operational data, not compliance paperwork.
Scan continuously or don’t bother
Annual dependency audits are security theater when your lockfile changes weekly. Scanning needs to be part of CI, running on every pull request, and it needs to block merges when critical vulnerabilities are found.
But here is the part most teams skip: someone has to own the findings. I’ve seen plenty of organizations that light up Snyk or Dependabot, get hundreds of alerts, and then ignore them because nobody is responsible for triage. A scanner with no owner is just a noise generator.
What actually works:
- Scan on every PR and on a daily schedule for new CVEs.
- Define a policy: critical gets fixed this week, high within two weeks, or you document why not.
- Automate the safe stuff (minor version bumps, known-good patches) and review the rest.
- Assign a rotating owner for dependency alert triage. Name goes on the schedule.
Hold your vendors accountable
During Log4j, the slowest responses came from third-party software and SaaS vendors. Some took weeks to confirm whether their products were affected. A few never responded at all.
This should change how you evaluate vendors. At the fintech startup, we learned early that your security posture is only as strong as your weakest vendor. These days, I ask pointed questions during procurement:
- Can you provide an SBOM for your product?
- What’s your SLA for disclosing critical vulnerabilities to customers?
- How do you monitor your own dependency tree?
- When was the last time you shipped an emergency patch, and how long did it take?
If they can’t answer these, factor that into your risk assessment. “We take security seriously” on a marketing page isn’t the same as having a process.
Patching speed is a capability, not a reaction
The teams that patched Log4j fast didn’t get lucky. They had fast, reliable deployment pipelines and the confidence to use them under pressure. That confidence comes from practice.
If your average time from “merge to main” to “running in production” is measured in days, you have a patching problem. Not just for security – for everything. But security makes it urgent.
Build the muscle:
- Ship small releases frequently. Teams that deploy daily can patch in hours. Teams that deploy monthly can’t.
- Keep your test suite fast and trustworthy. If you can’t run tests and deploy within an hour, figure out why.
- Maintain rollback paths. Every deployment should be reversible.
- Write the incident communication plan before the incident. During Log4j, half the chaos was people figuring out who to notify and how.
What to do this week
You don’t need a six-month security transformation. You need a few concrete improvements:
- Inventory your services and their owners. If you can’t list every production service and who’s responsible for it, start there.
- Add SBOM generation to your build pipeline. Pick one service, add the tooling, and make it searchable.
- Turn on dependency scanning in CI. Block critical vulnerabilities from merging. Assign an owner for triage.
- Review your top three vendor contracts. Do they include security disclosure SLAs? If not, start that conversation.
- Measure your patch speed. Time from “critical CVE announced” to “fix deployed in production.” If you don’t know this number, that’s your answer.
The next Log4j won’t be Log4j. It will be something in a different ecosystem, a different layer of the stack, maybe in a container base image or a transitive dependency nobody remembers adding. The teams that survive it cleanly will be the ones who built the operational muscle now – not the ones who bought the fanciest scanner.