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 later.
Shifting the quality left and putting accurate, and actionable intelligence in the hands of developers and their tools has yielded tremendous benefit to our customers. However, 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 Sonatype Platform.
This is important to understand, because even if you are 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 integral parts of your software factory, from Sonatype Repository Firewall to continuous monitoring of production environments. Let's say the vulnerability is announced on a Monday, and it's another nasty one. The first question leadership will ask is, are we impacted? ...and if so, what is impacted?
Let's start with Sonatype Repository Firewall. If you already used 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 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 send 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 a new vulnerability, and you can click on the component to see all the affected apps.
That same day, developers will open their IDE's and see if anything in their project has now been flagged red, indicating a policy violation, and give them the chance to fix it before their next code commits 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 flag the builds as unstable, and send notifications for at least the most critical policy violations, 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, let's say moving out of QA and into a UAT or some sort of staging environment could have their deployments automatically blocked as part of the deployment process, raising awareness among the folks responsible for managing the testing environments and apps getting ready to go into production.
With all 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 its way towards production. That same developer might go back and cut a break-fix branch from the production release, and apply the patched version 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 know exactly what the root case is and what steps are needed to mitigate the threat. This could allow 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 type 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 exactly what the impact is to your company and in which applications. Furthermore, any attempt to introduce new known vulnerable versions will be blocked by Sonaype Repository Firewall, and the software factory will catch any regression errors that will prevent them from being deployed. That's the kind of answer your leadership and board want to hear. If you were 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.
Curtis Yanko is a Sr Principal Architect at Sonatype and a DevOps coach/evangelist. Prior to coming to Sonatype Curtis started the DevOps Center of Enablement at a Fortune 100 insurance company and chaired a Open Source Governance Committee. When he isn’t working with customers and partners on how ...
Explore All Posts by Curtis YankoTags
Try Nexus Repository Free Today
Sonatype Nexus Repository is the world’s most trusted artifact repository manager. Experience the difference and download Community Edition for free.