Application development thrives on the use of open source components. Why? Quite simply, there are many benefits to using open source components, including the ability to leverage skill sets and expertise of the open source community, take advantage of the efforts of larger development teams, and reduce costs. To use open source components safely and responsibly, organizations need visibility into which open source components they’re using, where those components originate, and understand the associated security risk of each component.
In 2017 alone, an average of over 30 new vulnerabilities were added to the National Vulnerability Database each day. That’s exactly why organizations need insight into their open source usage to find a vulnerability quickly — before it gets exploited by a savvy hacker. Most organizations use open source without vendor support, leaving DevOps teams responsible for monitoring open source components in use for new updates and patches. Without a vendor “pushing” fixes and notices of security issues, organizations must track each component in their applications, locate and install those fixes from the correct source location. Few organizations have up to date internal documentation about what version of any given open source component is in use in their applications.
If you continuously review both custom and open source code in your development and deployment environments, your organization is off to a great start building a solid application security program. I recommend that DevOps teams start with automated software composition analysis (SCA) for open source and third-party libraries, integrated into automated builds and the code check-in process.
DevOps is really a philosophy, and it’s still evolving. Starting with the core principles of W. Edwards Deming’s points on Quality Management, DevOps binds the development of services and their delivery to IT Operations. When we apply Deming’s principles to software development and IT organizations, the goal is to improve the overall quality of software systems as a whole. How? In part by segmenting the system into manageable components, owned by teams that can quickly resolve issues that prevent the system from operating properly.
Most DevOps adherents consider Continuous Integration (CI) and Continuous Delivery (CD) defining attributes of DevOps. If you need a quick refresher, continuous delivery allows components of a system to be updated on an “as needed” basis, rather than waiting for the next full release. Continuous integration allows a developer to integrate changes into the source code mainline as they are completed. To throw another acronym into the mix, continuous deployment (also CD) allows applications to be continuously deployed to a subset of the user base. If that deployment is successful, the deployment expands to the entire user base.
“Software composition analysis” is, admittedly, possibly not as familiar a term to developers and engineers as DevOps or CI/CD. SCA tools analyze the source code, modules, frameworks and libraries that a developer is using. This allows developers to identify and inventory open source components, identify known security vulnerabilities, and surface licensing issues before releasing the application into production. For operations teams, SCA allows them to identify issues in deployment environments.
If we blend the definitions for DevOps and SCA, we can build security in to create a solution “that integrates with teams and 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.”
When selecting a complete SCA solution, make sure it include these key features:
To leverage the benefits of open source in application development safely, you need to build AppSec into your DevOps process. The information provided by software composition analysis tools is a valued part of the CI/CD process — one that helps development and operations teams find and proactively fix open source security vulnerabilities and licensing issues.
My session on quantifying container risks is at 1:50 pm at Container World on Tuesday, February 27. Hope to see you there.