“The big problems are where people don't realize they have one in the first place.” - W. Edwards Deming, patron saint of DevOps.
Clarity on a Big Problem
I recently shared news that 1 in 16 open source and third-party components downloaded last year included a known vulnerability. That may not seem like too many until you realize the average company downloads well over 200,000 components annually. These components are electively downloaded by development teams, often unaware of the vulnerabilities that come with them.
Manually reviewing every component you desire to download and use is out of the question... nobody has the time or resources for that. To do it right, would require dedicating 2 - 4 hours of research per component -- and your organization consumes thousands of unique components each year.
There is an easier (and free) way to understand if your repository contains components with known security vulnerability or license risks. Every one of the 60,000 active Nexus repository manager installations out there comes with a feature called the Repository Health Check. If you have a big problem, the health check will let you know; if your repo is free of vulnerable and risky components, you will learn that too.
Guarding the Front Door, The House, and Back Door
Protecting the Front -- Let’s say you turn on the Repository Health Check feature for your Nexus repository managers and the report reveals presence of undesirable components. Your organization may want to explore the new Nexus Firewall offering that provides a “cyber guard” at the front door of your repository to prevent future downloads of known vulnerable, risky, or outdated components.
Protecting the Inside -- We often say that components age like milk and not wine. Yes, we all understand that a component that is good today, may go bad tomorrow. Therefore, you can continue to use the Repository Health Check reports to automatically audit your repositories for any changes over time.
Protecting the Back -- Additionally, for those of you utilizing staging repositories in your configurations, Nexus Firewall can help analyze your release candidates. The staging suite (available in the commercial version of Nexus Repository) allows an organization to create a temporary staging repository and to manage the promotion of components from a staging repository to a release repository. This ability to create an isolated, release candidate repository that can be discarded or promoted makes it possible to support the decisions that go into certifying a release. This enables you to better control the exact set of binaries that will ultimately be released.
When coupled with the Nexus Firewall solution, every component in the staging repository can be assessed for known security vulnerabilities, outdated/undesirable versions, or risky licenses. Used in this manner, Nexus Firewall not only protects your front door upon initial download of the components, it also guards your back door prior to releases going out.
Solving Big Problems
As Deming suggested, to solve a big problem, you first need to realize you have one. Hopefully the Repository Health Check feature mentioned early in this post can shed some light on what’s happening inside your SDLC and software supply chain.
We all have a software supply chain that feeds components into our repository managers and application development lifecycles. With better visibility to the components we are using, we can all deliver better software, even faster.
While this story covers only one aspect of DevSecOps, there is much more to be learned about the subject. One of the best papers I have read recently comes from Neil MacDonald and Ian Head at Gartner, entitled “How to Seamlessly Integrate Security into DevOps". It's worth a read.
