Deming, the patron saint of DevOps once advised, “It is not necessary to change. Survival is not mandatory.”
To survive, application development teams are constantly pressured to deliver software even faster. But fast is not enough. The best organizations realize that security, quality and integrity at velocity are mandatory for survival. Hence, DevOpsSec
My aim here is to leave you uncomfortably amazed. While the pace of development has changed significantly, our processes to secure our applications has not changed enough. It is as if a wildfire has raged uncontained for years now but we have failed to take notice.
Maybe that sounds a bit crazy, but once I share a little background on what is happening, you’ll understand why innovation in this arena is critical for survival (when it comes to your applications). If you are aiming to ramp up your own Rugged DevOps or DevOpsSec practices, this is critical reading material.
Skyrocketing Usage, Plummeting Visibility
Open source component use in development is skyrocketing, and for good reason. Over 17 billion open source and third-party components — across the major development languages — were downloaded last year helping development teams accelerate release timelines and deliver more innovative solutions to market. To better imagine the impact of this download volume, you need to understand that there are an estimated 11 million developers responsible for the billions of downloads.
While the magnitude of usage is amazing it has obscured a vast majority of the risks. Of the billions of downloads recorded last year, 1 in 16 components downloaded had known security vulnerabilities.
While we have seen 30x growth of download requests over the past seven years, we have also witnessed huge growth in the number of organizations improving the speed of consumption and efficiency of their downloads using repository managers.
In the past 18 months since I joined Sonatype, we have seen active instances of repository managers like Nexus, Artifactory, and Archiva grow from 40,000 to over 70,000 installations, with users in the millions — also for good reason. Development teams want to ensure faster, more reliable builds. They also need a private and safe place to house and share their own proprietary components as well as assembled applications, images and other binary outputs. The repository manager has established itself as a parts warehouse for software development.
All is Not Moonlight and Roses
1 in 16 may not sound like a lot until you recognize that many organizations are downloading over 250,000 components every year…some of the largest organizations consume millions of them. If you have not calculated this in your head yet: 250,000 / 16 = 15,625.
Couple this fact with the remarks in the 2015 Verizon Data Breach and Investigations Report stating that applications were the most often exploited attack vector by hackers. As a developer community we are electively sourcing known vulnerable components for use in our applications and those applications are now more vulnerable to attack.
Your Repository Manager Should Serve and Protect
If bad components are getting in, why not just stop them at the front door?
Easier said than done. Current approaches to preventing such behavior are ineffective. For some, “golden repositories” are used to house approved components — but components approved once are rarely vetted again for newly discovered vulnerabilities. For other organizations, OSS Review Boards mandate reviews and approval for all new components — but these organizations are poorly staffed to match the volume and velocity of consumption leading to workarounds by development teams. And while developers themselves would much prefer to use the best quality, highest integrity components when designing an applications, they are never allocated sufficient time to investigate the vulnerability status of every component required for their latest build.
Sparking Innovation
When current approaches fail, inspiration often sparks innovation.
Enter, a new invention: a repository firewall. Think of it as a repository manager with a guard at the front door. Every component that gets downloaded by a proxy repository is automatically evaluated against the parameters development, governance and security teams establish. Does it have an AGPL license, include a known security vulnerability, or is it incredibly outdated? The repository firewall allows organizations to download “good” components while it blocks and quarantines “bad” component downloads. Using a repository firewall can keep your repository manager and development lifecycle safe and secure – in an instant, automatically.
The first repository firewall of its kind is called Nexus Firewall. It couples software supply chain intelligence about component quality, security, and risks with automatic evaluations against personalized policies for approving or rejecting new downloads. Evaluations can also be applied later in the development lifecycle where staging repositories are in use.
Imagine the result: 16 out of 16 downloads, or 250,000 out of 250,000 downloads are now of the best quality. Everything flowing into your application development lifecycle contains the highest quality components. You are instantly compliant with established policies. Your applications are less vulnerable to attacks. You are automatically reducing risk.
Next up in this series, I will share insights about Repository Health Check reports (free to use). Used by over 15,000 organizations, they can offer organizations the first clue as to whether or not your team could benefit from a repository firewall.
NOTE: While this story covers only one aspect of Rugged DevOps, there is much more to be learned about the subject. One of the best papers I have read recently comes from Amy DeMartine and Kurt Bittner at Forrester Research, entitled “The Seven Habits Of Rugged DevOps: Strengthen Cybersecurity Using DevOps Culture, Organization, Process, And Automation” (registration is required to download, but it’s worth it).
