Repository managers like Nexus and Artifactory have been serving software components for development teams and their tooling for years now. This November, we are introducing an innovative way to improve speed and reduce risk through the quarantine of components with known vulnerabilities. With the integration of Nexus Firewall, you can shield your application development from waste and risk by automatically blocking unacceptable software components inbound and preventing applications containing such components outbound.
The firewall also goes beyond blocking, providing organizations with the visibility and data needed to make ideal decisions for open source component selection early, significantly reducing waste related to rework. The quantitative research summarized below, covering over 7,000 repositories across nearly 100 countries, highlights these challenges as well as the significant opportunity.
What is Nexus Firewall?
Nexus Firewall is a perimeter quality control for software development. Similar to a network firewall, it leverages a set of configurable rules that automatically shields an organization from unacceptable things entering and another set for stopping those things from exiting your application development.
The basic concept looks like this:
Why the Repository?
The repository manager has become a critical piece of the DevOps toolchain and is commonly used across the entire application lifecycle. It is effectively a binary parts warehouse for your applications. Given how integral this warehouse has become, automation can be used to significantly reduce rework and eliminate avoidable risk.
To understand this opportunity, we can take a quantitative look at the world’s software development ecosystem.
Not long ago Sonatype introduced Nexus RHC (Repository Health Check) – a simple way to get basic visibility into what OSS is flowing into development via your repository manager. Usage of this service is now significant, with over 60 million components across over 20,000 Nexus instances being analyzed every day across the globe.
There are also around a million developers using those repositories. With the law of big numbers working for us, we can gain a statistically valid view into the behaviors of the modern software development ecosystem. The findings are quite telling.
We analyzed over 7,000 repositories containing 500 or more software components using the RHC service during the past 90 days. These repositories are representative of those used by development teams in medium to large organizations. The question was straightforward: To what extent are bad things flowing in, causing downstream rework and creating avoidable risk scenarios?
In three months, the average number of new vulnerabilities that flowed into the repositories analyzed was 69. That is an average of 23 vulnerabilities per month, which is a little more than one every weekday. If you only include higher risk vulnerabilities – those with a CVSS score of 5 or greater – the average number was 48, or about 16 per month. That is a little less than one every weekday. For a sense of the kind of vulnerabilities in this higher risk category, the Heartbleed bug had a score of 5, the lowest risk in this grouping.
These are not isolated instances or outliers. In the set of repositories analyzed, 98.3% consumed at least 1 vulnerable component and 97.7% consumed at least 1 higher risk (CVSS >= 5) component. In a period of just three months, nearly every repository consumed something the organization running it would rather not have, and that is only with respect to known vulnerabilities. There a plenty of other attributes that are worthy of consideration given availability of the corresponding data.
Whether or not security is a particular concern, the real point is that a lack of visibility and control has led to inferior quality parts routinely being used by the world’s development organizations, adding avoidable risk and slowing us down.
Enter Nexus Firewall
The consumption of these unacceptable or, at a minimum, inferior components is now unnecessary. Avoiding this is one of the primary benefits provided by Nexus Firewall. For the vast majority of these vulnerable components, there are non-vulnerable alternatives ready to be used in their place. The challenge has been how difficult it is for developers to understand these risks and even harder to avoid them.
Avoiding risk can now be done through automation, and when combined with the remediation capabilities provided by the firewall, drive the right choices early in the development process. An example of the kind of information made available is shown below.
Going (Way) Beyond Security
The consumption of vulnerable components is a quantifiable problem that we used to illustrate the current challenges that every organization has with open source component selection. However, security vulnerabilities are only one of the many dimensions supported by Nexus Firewall.
Others include architectural aspects such as rules covering component age and popularity, intellectual property coverage with rules related to open source licensing and technical debt controls associated with technology stack selection. A comprehensive ruleset will yield significant overall quality benefits for an organization.
Quality at Velocity – Just Flip the Switch
Simply by enabling Nexus Firewall, organizations can immediately improve quality and reduce waste and exposure to risk. None of this comes at the expense of development speed.
Firewall automatically quarantines components that do not pass your rules preventing quality issues from entering the software being developed, immediately reducing risk and avoiding wasteful rework at some later point. Quality is improved, efficiencies are gained and risk is reduced, all through automation and all at the speed of modern development.
Latest posts by Mike Hansen (see all)
- Nexus Firewall – Quality at Velocity - February 1, 2017
- The Reports of Agile’s Death have been Greatly Exaggerated - June 22, 2016
- The Low Cost of High Caliber Developers - March 7, 2016
- The Nexus Firewall – Perimeter Defense for Software Development - November 18, 2015
- Software Supply Chain Automation - May 13, 2015