Zero Day, Now What?

We at Sonatype spend a lot of time talking about shifting application security and OSS governance to the left and rightfully so. Like so many other 'quality' attributes the key to going faster is to get your feedback much earlier in the process and essentially build quality in instead of trying to test/inspect it in later.

Shifting the quality left and putting accurate, and actionable intelligence in the hands of developers and in their tools has yielded tremendous benefit to our customers but no matter how good you are you still have to deal with new vulnerability announcements. For this post I wanted to walk through what a new zero day announcement might look like in a mature DevSecOps shop using the Nexus platform.

This is really important to understand because even if you are doing a really great job of being proactive in selecting only the best open source components we will still, inevitably, find ourselves in this reactionary position, the real question is, how will we react?

First, I'll assume our products are an integral part of your software factory, from Firewall to continuous monitoring of production environments. Lets say the vulnerability is announced on a Monday and it's another really nasty one. The very first question leadership is going to be asking is, are we impacted? ...and if so, what is impacted?

Let's start with Firewall, if you were already using some of the affected versions they're already past the firewall and in your repository so it's too late for them but from now on, any other versions that are affected that you don't already have will be automatically blocked. So at least the front door is now closed to any net new additions to our repository.

Now let's look at the other end of the factory, apps running in production. Our continuous monitoring will identify any app using any affected version and should also be sending out notifications to Ops folks, security folks and product owners or whoever else you set up for notifications. Lots of emails in lots of inboxes identifying precisely which applications are impacted which allows us to answer those first two questions. Or, maybe no emails go out because no apps were affected. These will also all show up in our dashboard as net new vulnerability and you can click on the component to see all of the affected apps.

That same day, developers will be opening their IDE's and will have a chance to see if anything in their project that has now been flagged red, indicating a policy violation and giving them a chance to fix it before their next code commit to trigger a new build.

Speaking of builds, I'll assume virtually every app is being built at least once a day if not more so any project using an affected version will now be flagging the builds as unstable and also sending out notifications for at least the most critical policy violations thus ensuring the whole dev team has some awareness. So even if my developer didn't catch it in the IDE, the build will.

Any builds from previous days trying to progress through the SDLC, lets say moving out of QA and into a UAT or some kind of staging environment could have their deployments automatically blocked as part of the deployment process and therefore raising awareness among the folks responsible for managing the testing environments and apps getting ready to go into production.

With all of this awareness we can now go back to the developer who can update the build script to use the new patched version and commit their code to get a new, vulnerability free version of the app on it's way towards production. That same developer might go go back and cut a break-fix branch from the production release as well to apply the patched version in an effort to get an emergency patch into production as soon as possible.

The bottom line here is, you're covered. You can accurately answer that 'impact' question and be armed with the information you need to prioritize any remediation plans. Our human curated data feed is detailed and even shares our sources ensuring you'll know exactly what the root case is and what steps are needed to mitigate the threat possibly allowing WAF's and RASP tools to cover any gaps until a new build with the patch can be deployed. Going forward, any possible regression would be caught setting off the alarms again before it can become a real problem again.

Hopefully, this helps folks understand the value and benefit of having this kind of capability built into your SDLC from start to finish is essential. No matter what stage your application is in we can detect and alert the appropriate stake holders with actionable feedback so that the next time one of these headline grabbing security breaches puts you in a position to answer with confidence about exactly what the impact is to your company and in exactly which applications. Furthermore, any attempt to introduce new known vulnerable versions will be blocked by the Nexus Firewall and any regression errors will be caught by the software factory which will prevent them from being deployed. That's the kind of answer your leadership and board want to hear. If you found yourself unable to quickly and accurately answer that 'impact' question, you might want to try out our free Application Health Check and scan one of your apps to see how powerful rich component intelligence can be.