Security News > 2022 > March > Log4j postmortem: Developers are taking a hard look at software supply-chain security gaps
With so many security and developer teams doing post mortems on the Log4j security vulnerability fiasco that unfolded in late 2021, just 10 days before Christmas, the main question is: how do we avoid this type of pain in the future? The answer is it's complicated.
On the upside the pain of that experience has triggered a major software supply-chain security rethink from developers and security teams.
"You don't just need to fix a security vulnerability, you need to know that you fixed the vulnerability without breaking your system. When you have a vulnerability with a super popular logging library like Log4j, you are talking about dependencies on legacy code that typically lacks any testing, and where sometimes the developers who wrote the code and understand how it works don't even work at the company anymore."
He sees developers who were stung by Log4j now creating integration tests between systems and external dependencies, so that the next time a security vulnerability arrives, developers can test that their fixes won't take down production systems when deployed.
The arrival of the Log4j security vulnerability and its terrible timing during peak holiday season created a perverse choice for developer teams-deploy fixes now and risk taking down systems during peak holiday e-commerce cycles, or punt the deployment of fixes to less commercially risky intervals?
Log4j illuminated the fact that so much of the modern software supply chain is propped up on open source projects with a handful of maintainers, or even a single maintainer, who often created the technology as a side project.