Building Open Source Security into DevOps

Source – infosecurity-magazine.com

DevOps is a philosophy of IT operations that binds the development of services and their delivery to the core principles of W. Edwards Deming’s points on Quality Management. When applied to software development and IT organizations, Deming’s principles seek to improve the overall quality of software systems as a whole.

This is done in part by decomposing the system into manageable components, which can be owned by teams. These teams have the freedom to quickly resolve any issues that might prevent the system from operating properly.

By creating a sense of pride and ownership in the delivered system, any issues discovered can be quickly resolved. This method increases the overall health of the system, which has led to the rise of Continuous Integration (CI) and Continuous Delivery (CD) as defining attributes of DevOps.

Continuous delivery is a model where components of a system are updated on an as needed basis, rather than waiting for a traditional “release vehicle.” Continuous integration is a development model where changes made by a developer are integrated into the source code mainline as they are completed. From a testing perspective, a feedback model is used, leading to a concept of a CI/CD “loop.”

Related to continuous delivery is the concept of continuous deployment. Under continuous deployment, applications delivered into the system are continuous deployed to a subset of the user base. Organizations following the continuous deployment model streamline the delivery and deployment steps in an automated fashion.

Depending upon the maturity of an organization on its DevOps journey, engineering teams may practice “DevOps” where product delivery to a traditional operations team occurs. That operations team then practices “DevOps” by incorporating the deliverable into their deployment paradigms by integrating the deliverable. In both cases a CI/CD model us used.

Is software composition analysis compatible with agile DevOps?
Before taking on the question above, let’s look at a term that those who deal most directly with software composition—that is, developers and DevOps engineers—may not be altogether familiar with.

Coined by Forrester Research, Software composition analysis (SCA) “…provides valuable data to security pros, legal pros, and app developers by identifying software vulnerabilities and exposing licenses for open source components.” DevOps teams tend to grasp the concepts and value of SCA faster when described in the more-familiar terms of open source security and license management.

In modern agile software development, code is rarely written from scratch. Forrester Research indicates that custom code often comprises only 10 to 20% of the bulk of applications, with the remainder being previously developed code, third-party code, and increasingly, open source code as the core foundation for applications. In fact, Black Duck by Synopsys code audits indicate that 95% of code bases contain open source.

Unfortunately, many open source components come with liabilities in their license agreements, and, according to the Forrester Wave on Software Composition Analysis, “one out of every sixteen open source download requests is for a component with a known vulnerability.”

While open source is not less secure than commercial code (nor more secure, for that matter), there are characteristics of open source that make vulnerabilities in open source components particularly attractive to a hacker.

For example, most open source is used without support from a vendor, meaning that organizations must monitor the open source components they use for new updates and patches. Instead of a vendor “pushing” fixes and notices of security issues, organizations must track each component in their applications, and “pull” those fixes when available.

While open source software is often heavily vetted (following the Linus Law of “many eyeballs”), there is often little internal documentation about what version of any given open source component has been adopted by any given organization. Add to this the problem of “software decay” where older, previously secure, open source components have new security issues, and the task of open source security becomes even more difficult.

Let’s combine our definitions to define a DevOps-compatible SCA solution, as “a solution that integrates with teams and a wide variety of other tools to automate the process of identifying, communicating, and acting on open source vulnerability and license risks as part of the development and deployment workflow.”

Unless developers are logging the open source code they use in an automated fashion, identifying that information later will be a best-guess scenario, leaving the origins of the software unclear and/or unknown. This means security vulnerabilities can leave business-critical software vulnerable to attack.

Defending against open source security threats and compliance risks
To defend against open source security threats and compliance risks, DevOps teams must adopt open source management practices that:

Fully inventory open source software: A full and accurate inventory (bill of materials) of the open source used in applications is essential.

Map open source to known security vulnerabilities: DevOps teams need to reference public sources to identify which of the open source components they use are vulnerable.

Identify license and quality risks: Failure to comply with open source licenses can put organizations at significant risk of litigation and compromise of IP.

Enforce open source risk policies: As software development becomes more automated, so too must management of open source policies.

Alert on new security threats: With more than 3,600 new open source vulnerabilities discovered every year, organizations need to continuously monitor for new threats as long as their applications remain in service.

We’ll end by returning to the question: Is SCA compatible with DevOps? The answer is: Absolutely, yes, but only if they provide the ability to integrate open source management throughout your DevOps environment from IDE through to runtime platform.

Having this flexibility is critical as it allows you to tailor your DevOps environment to your needs rather than to a rigid vendor-centric framework.