Log4J is a wake-up call for development.
By now, most people have at least seen the headlines about the Log4J vulnerability. While much has been written about this vulnerability, one area not to overlook is the role of software development in the magnitude of this situation.
For many years development has been using tools and libraries. There are many benefits to doing this, such as:
- Projects have better functionality, better testing, and improved security since more people are working on them and using them in different ways.
- Accelerating the speed of coding
- Not reinventing the wheel
Nothing is wrong with that at all; however, through the Log4J incident, we see a step that often gets overlooked. Many organizations did not even know if they were using or had Log4J operational in their code. A classic miss of NIST Cyber Security Framework function of “Identify“. How can you protect what you don’t know you have?
What can be done? All development teams and software vendors should have a Software Bill of Materials (SBOM). “A software bill of materials (SBOM) is a list of components in a piece of software. Software vendors often create products by assembling open source and commercial software components. The SBOM describes the components in a product.” With this, you can inform the organization and your customers of what libraries are operational in your code. This will speed time to patching and or mitigation of vulnerabilities instead of taking the first step of ‘do we have anything vulnerable’?
We can only begin to imagine what the next Log4J will be, but if we have a good inventory and have identified all our assets right down to the SBOM level, we will at least be able to respond more quickly to minimize the damage.
