You Are What You Eat.
When it comes to food, we all know what's considered "good" and what's "bad."
For fried, battered, buttery or creamy: the category of cupcakes and such... just say no. When fresh, grilled, steamed or baked: of course, you should eat your veggies and other fine foods... bon appetite.
We can all understand this simple rule when eating. But for many, simple rules and advice from nutritional labels aren't always there for us. Simple rules like, use "good" open source components, not "bad" ones (i.e., vulnerable, outdated, risky licenses) when building and deploying your next app.
Evidence of Gluttony.
To meet the need for speed, virtually all modern development organizations use open source and third party components to assemble applications, rather than build every function from scratch. According to the 2016 State of the Software Supply Chain report, the average development organization feasts on over 229,000 open source Java components each year, but we're seeing similar consumption practices in the JavaScript, Python, Ruby, and .NET development realms. While the upside of this gluttony is improved productivity, there is a downside to consuming components without proper insight into their quality.
Beyond the consumption of open source and third-party software components in development, the same guidance applies to containers used by DevOps teams. Today, over 100,000 free apps are available on Docker Hub, and consumption of those applications into DevOps tool chains and infrastructure often goes unchecked.
The Downside of Efficiency.
While sourcing components and containers can accelerate development efforts, many organizations do not apply sufficient scrutiny to assess their quality or security. The 2016 Software Supply Chain report also indicates that 1 in 15 components used in applications contain at least one known security vulnerability. What this means is that not all components and containers are created equal. It also means that blind consumption practices can have both immediate and long-term consequences for the organization consuming open source software components or containerized applications.
According to the 2017 DevSecOps Community survey, 57% of organizations looking to improve the quality of components used in their development practices have implemented an open source governance practice. This is up only slightly from the 2014 survey, which showed 57% of organizations with open source policies in place. For those without a policy, there are no rules in place when it comes to "good" vs. "bad" consumption practices. Having policies in place can help improve the quality of applications being produced, reduce vulnerabilities to attack, and eliminate use of components with risky license types.
Breaking Bad.
To further emphasize the need for evaluating component quality and security, let's look at one of the findings from our 2014 survey. At the time, over 2,700 survey participants indicated that more than 1 in 10 organizations (14%) had experienced or suspected a breach in their applications related to an open source software component. Because that survey took place in the same month that the notorious OpenSSL software component (a.k.a. "Heartbleed") vulnerability was announced, I felt like it might have inflated the number of breach related responses. To my surprise, the 2017 survey shows that 20% of organizations (1 in 5) had or suspected a breach related to open source software components in their applications. In the past three years, as the rate of confirmed or suspected breaches related to vulnerable open source components increased by 50%, the number of organizations with rules to govern the use of secure components remained the same.

Across the DevOps community, we are seeing much more attention to security concerns, and more organizations are finding new ways to automate practices early in the SDLC. Automating the evaluation of open source and third-party components against rules designated in open source governance policies is one of the approaches being adopted. While not the only answer to DevSecOps requirements, having an automated policy to enforce governance and guide remediation can pay off handsomely if it also helps prevent a breach.
When it comes to carrots and cupcakes, the right choices can offer great short- and long-term benefits. In the realm of components and containers, making "good" choices will also benefit your DevSecOps practice.
Derek serves as vice president and DevOps advocate at Sonatype and is the co-founder of All Day DevOps -- an online community of 65,000 IT professionals.
Explore All Posts by Derek WeeksTags
Code 3x Faster with Less False Positives
Build, test, and launch secure applications without rework. Explore how the Sonatype platform can enhance productivity and security.