Unless you have been living under a rock, you should know by now that there is a severe vulnerability in versions of the open-source library Log4j.
Yes, we need to respond to this security threat, and yes, we should react quicker in the future, and yes, we need to get better at sharing intel. But all those things combined are not going to solve the fundamental problem. The Software Bill of Materials (SBoM) and incident response are NOT solutions to the underlying issue. The real source of the problem is not the software supply chain or open-source libraries.
We are the problem!
We are introducing mistakes in the software we develop all the time, just like the one in Log4j – because we make things too complex, because we are in a rush, because we are human and basically because …
We underestimate security.
This lapse is evident because there have already been two security patches on the original patch of said Log4j vulnerability. Go figure.
By putting quality second, we have figuratively painted ourselves into a digital corner and we need to accept there is no easy way out. We are not going to create better software by simply running a tool, or by getting a certificate, or by giving developers a book, or by making one person or a handful of people responsible.
We have to change our ways.
It is time to accept our duty of care and realize that a substantial change is needed to attain sufficient security and quality software in general. Let’s embrace quality design principles (including keeping it simple) and build in quality (security, privacy, maintainability, performance, reliability, etc.) from the start. It is time to get serious and really shift left. It will save us from severe incidents hurting us and our clients. It will prevent expensive unscheduled rework. It will draw great developers and great clients, as responsible software development is the new differentiator.
Here are some pointers to get started:
- Open-source teams: look at Open Source Security Foundation (OpenSSF)
- Everyone: look at OWASP and navigate using the Application Security Wayfinder for great resources such as Application Security Verification Standard (ASVS), Software Assurance Maturity Model (SAMM), and the Security Knowledge Framework
One more thing…
I’ve heard people say that the Log4J vulnerability was introduced by ‘amateurs’ since it’s open source. As if enterprises do not create any vulnerabilities of their own. Just look at the crazy amount of security patches for commercial software that we use every day. Maybe the best way to look at it is that we are all amateurs.
It is time to go Pro!
It is encouraging that many of us are starting to see the light. Progress is slow, too slow, but it is in the air. The number of organizations requesting help to build quality in is growing fast. Still, budgets are lagging, and people pursue quick and easy solutions, while there is no silver bullet, despite what some vendors would have us believe. The cool thing is that it is fun and interesting, on the bleeding edge. Isn’t it, security brothers and sisters? Together we can make it happen.
About Rob van der Veer
Rob van der Veer established and leads the Security and Privacy capability at Software Improvement Group. He brings more than 25 years of software industry experience to his role, including nine years in CEO positions, primarily in the Artificial Intelligence industry.
Rob frequently writes and speaks about Security & Privacy issues. He also serves as an advisor to the European Commission as well as software quality standardization bodies.