What to Do on Day 2 – InApps Technology 2022

With the worst of the Log4j emergency behind us and remediation underway, it’s time to think about what’s next. How you respond in the weeks, months and even years following the remediation of an exploit like Log4j can turn out to be more important than what you do during the early days.

In the world of DevSecOps, we break development into phases, or “days.” Day 0 is when we architect and build a solution. Day 1 is the day we deploy the solution. Day 2 is how we will run the solution and monitor and maintain system security every single day after Day 1. Because most of the focus is typically on Day 0 and Day 1, Day 2 often does not get proper planning.

We can think about Log4Shell, the vulnerability discovered in Log4j, in a similar way. Day 0 was the day when the discovery of the vulnerability was announced. Day 1 was when we deployed fixes to remediate Log4j. We are now in the Day 2 stage where we need to address such concerns as “How are we going to maintain our software to make sure we don’t accidentally ingest and deploy vulnerable versions of Log4j?” and “How can we make sure we can quickly answer questions about what we are running in our software if there is another vulnerability of this magnitude?”

Day 2 concerns speak squarely to the importance of software supply chain security. The ability to track the contents of software in use is not only now possible but also extremely effective to help us discover if we are vulnerable to future zero-day exploits like Log4j.

After Log4j Remediation, Now What?

Any time we experience a zero-day exploit like Log4j, there is never an abrupt ending. The sudden crisis tends to slowly wind down until it is a distant memory. But the average lifespan of a zero-day vulnerability is roughly seven years — seven years for it to lie dormant in our systems, seven years for it to linger in unpatched open source software, seven years for it to still be a potential threat to our organizations.

So now that we’re starting Day 2 of the Log4j exploit, what’s next? We first need to acknowledge that vulnerable versions of Log4j and many other software components still exist in our software supply chains. New zero-day vulnerabilities will continue to arise. We must understand what software components we are using, where they came from and what the risk looks like all day, every day — not just when a zero-day exploit arises. Now, with the recent pain of Log4j front and center, it’s time to establish and improve Day 2 processes that embed software supply chain security into the way we build and use software applications.

The tools used will play a pivotal role in the future of securing the software supply chain. Log4j resulted in the development of multiple ad hoc tools designed specifically for discovering that exploit. And although such ad hoc tooling is useful during an emergency, it is not comprehensive enough to maintain a strong security posture throughout the entire software supply chain. We need sustainable tools and processes that can be used across all of our software components and applications on an ongoing basis.

Why the SBOM Is Key to Day 2 Security

As Log4j showed us, knowing exactly what’s running in our infrastructure is crucial. The first step to remediation was understanding exactly which applications included Log4j. We already have a powerful tool at our disposal for cataloging the entire contents of a software application: the software bill of materials, or SBOM.

On Day 2, we need to implement best practices to generate and store an SBOM for each software application we deploy. We can then use automated tools to scan SBOMs at any time post-deployment to identify new vulnerabilities. In the case of a zero-day exploit like Log4j, this eliminates the manual process of manually searching code repositories, which is extremely time consuming and causes significant delays in remediation.

Having an SBOM is just one step in securing the software supply chain. For Day 2, we need to be able to continually create, ingest, track and search SBOMs, which is where SBOM management comes in. And we need to use SBOM standards to provide a common format for describing the composition of software among participants in the software supply chain.

SBOMs as a Foundation for Software Supply Chain Management

Day 0, 1, and 2 have proven, at least conceptually, to be a valuable framework for continuously improving software development processes. Applying that framework to securing the software supply chain can be helpful in determining which tools you’ll need and when to apply them.

As Day 2 begins and we absorb the lessons of Log4j, we need to re-evaluate the status quo and rededicate ourselves to establishing secure software supply chain management with SBOMs as a foundation.

SBOMs are already on the way to becoming a norm. Forward-thinking government institutions and large organizations are now requiring SBOMs, essentially helping to define standard formats for SBOMs in the process. They recognize that having a list of everything in a product at the time of purchase will eliminate the problem of tracking down every vendor when a vulnerability like Log4j occurs.

For Day 2, we must employ SBOMs as part of an end-to-end software supply chain management process so that we can minimize the disruption of the next zero-day exploit. By generating SBOMs at each step in the development process and for each build, we can then use automation to identify security risks, enforce policies, and get alerted to new issues. In this way, we can ensure a more effective and secure software supply chain.

 
Feature image via Pexels