With the public release by CISA of the Vulnerability notice related to the Apache Log4j vulnerability, we as senior Cybersecurity professionals and executive-level leaders, should all begin to take more seriously the use of open-source frameworks as the basis for an enterprise-level application, or as a framework supporting a weapon system and its operations.

While the discussion around the use of open-source software has been raging within the DoD community for years, this may be a watershed moment where we must begin to seriously consider the cost-to-risk ratio that we often apply to software development. While the use of available open-source libraries such as the Log4j framework significantly reduces development time, we have to ask the question, “Is it really worth it?”

Let us take the Apache Struts vulnerability that led to the Equifax data breach a few years ago. While this specific data breach was based around an unpatched version of the Apache Struts framework, at its core, this was a piece of open-source software that came with no claim or legal obligation for security, support, or notifications.  With the use of an open-source framework such as this, we must accept the risk that its vulnerabilities are more well-known and are in the public eye. These open-source projects may be subject to lax development practices and methods, and we have limited availability to determine the source of the code itself, as it is often impossible to track and control where it comes from or who originally developed it.

When a framework, library or any other source code is developed by an organization that is contractually or legally bound to provide a warranty, support and updates for software, there is a greater probability that this software will be maintained, secured and properly developed in a manner consistent with DevSecOps practices that we have finally started to embrace in the DoD community. We also have a certain amount of “security through obscurity” by utilizing only our own source code which will automatically begin to reduce the potential attack vectors available to the low-level adversaries, or “script kiddies” which only seek to take the easy path to an exploit.

Should we move software development to an “in-house only” model? That is probably not realistic as too many developers today have come up through the ranks with the ease of re-use of open-source libraries and code. There is also the issue of cost and speed to deployment. Without code re-use, we simply may not be able to meet the requirements of our customers.

However, with all of that being said, we should begin to seriously consider a return to a more in-depth knowledge of what software is in use on our systems, where it comes from, and what it contains. The Executive Order on Improving the Nations Cybersecurity, released in May of 2021, is a step in the right direction. By something as simple as a Software Bill of Materials (SBOM), we begin to have a greater insight into the tools, code and applications in use within our infrastructures.

It is then incumbent upon us, as Cybersecurity professionals, to ensure that we properly evaluate these SBOMs, and the software listed therein. Through thorough evaluation of each open-source tool in use, to include their dependencies, maintenance requirements and security implications, we can begin to increase the Cyber hygiene of our various enterprise applications, weapons systems and infrastructures.

At the end of the day, we must realize that there is certainly no quick fix for this. Legacy applications will require years to change, and for every mitigation we put in place, the adversary will find a way around it. Thus, the cat and mouse game of Cybersecurity continues.

We must not rest on our laurels and move on to the next crisis without realizing that our application development processes must be improved as one of the bases of our security infrastructure.