DevSecOps vs Log4Shell

On December 9th 2021, a critical vulnerability related to a very popular Java logging package, Log4j2, was disclosed (CVE-2021-44228). The vulnerability base score was critical (10.0 in CVSS version 3) due to the ease of exploitation and the RCE capabilities (hence the name Log4Shell). This package is widely used by many applications around the world, as it's the most popular logging tool for Java based software, so the impact has been huge for the entire IT industry.

After the disclosure has been published, attackers started to exploit the vulnerability in the wild and IT companies are struggling to defense against the attacks, looking for vulnerable servers in their environment and trying to patch them as soon as possible.

Could DevSecOps methodology help companies to better handle Log4Shell or similar security incidents?

What is DevSecOps

DevSecOps is the process to include Security within the entire development lifecycle, from the software design and throughout the implementation, testing and deploy phases. Using this approach we are able to reduce security risks within the application being developed because security requirements are addressed directly rather than delayed at the end of the development. The main principle is to be able to implement applications which are "Secure By Design".

How DevSecOps can help against Log4Shell and similar incidents

Almost every software needs to import third party libraries. I'm pretty sure that the majority of developers, are not going to perform a security review for the imported libraries (it would be impractical and it would take a lot of time!) so when we import and use the third party libraries, we are automatically trust their code and we rely on them.

DevSecOps methodology, requires numerous steps to build secure applications, among which there is an important task about dependencies check. Basically this process (often referred as SCA - Software Composition Analysis) scans all the dependencies required by the application being developed and it produces a report about publicly disclosed vulnerabilities found within the third party dependencies.

Furthermore, the development pipeline could include the process of dependencies scan. For example, during software development, we might need to import a new library but when trying to build the project we receive a warning (but we can also force the build to fail) because the imported library version includes a publicly known vulnerability.

These process can also be useful to track the dependencies used by our application: at any moment, we are aware about which third party libraries and dependencies are imported in our application. This can be helpful for example in cases such as Log4Shell disclosure: with a quick look at our dependency list produced by our dependency check tools, we can easily verify if our application is affected or not, just by checking if the vulnerable library has been imported in our project. Then we can immediately take the required actions: updating the library if patch has been released or mitigate the issue using some workaround provided. Having these information (often called SBOM - Software Bill of Materials) will drastically reduce the response time when incidents such as Log4Shell disclosure happen.

Another important task included in DevSecOps methodology, is threat modeling: this process aims to identify security threats and their mitigation during the application design phase for each application's component. Other then reducing the architectural design flaws of the application, it can be also useful to get a clear representation of the security risks related to each component: in case of such incidents, we already know where to look to mitigate the issue.

Also, applying DevSecOps methodology will ensure that security experts are constantly working with the developer teams and all the security issues that might happen during the software development of the project are quicky identified.