close search bar

Sorry, not available in this language yet

close language selection

Why you need to build AppSec into your DevOps process

To leverage open source in application development safely, you need to build AppSec into your DevOps process, including use of open source components.

Building AppSec into Your DevOps Process

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 and where those components originate, and they should 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 and 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.

So, is software composition analysis compatible with agile DevOps?

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.

Building software composition analysis in for DevSecOps

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:

  1. Provides a complete inventory of open source software. A full and accurate inventory (bill of materials) of the open source used in applications is essential.
  2. Maps open source components to known security vulnerabilities. DevOps teams need to be able to quickly identify when any open source components they use are vulnerable.
  3. Identify license and quality risks. Organizations that fail to comply with open source licenses are at significant risk of litigation and compromise of IP.
  4. Enforce open source risk policies. Software development is becoming more automated every day; management of open source policies must keep pace through automation as well.
  5. Alert on new security. Thousands of new open source vulnerabilities are discovered every year, which is why responsible organizations must continuously monitor for new threats as long as their applications remain in service.

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.

For more information, check out our on-demand webinar Breaking Down DevSecOps: Build AppSec Into Your CI/CD Pipeline with SAST and SCA.

Watch now

Tim Mackey

Posted by

Tim Mackey

Tim Mackey

Tim Mackey is the Head of Software Supply Chain Risk Strategy within the Synopsys Software Integrity Group. He joined Synopsys as part of the Black Duck Software acquisition where he worked to bring integrated security scanning technology to Red Hat OpenShift and the Kubernetes container orchestration platforms. In this role, Tim applies his skills in distributed systems engineering, mission critical engineering, performance monitoring, large-scale data center operations, and global data privacy regulations to customer problems. He takes the lessons learned from those activities and delivers talks globally at well-known events such as RSA, Black Hat, Open Source Summit, KubeCon, OSCON, DevSecCon, DevOpsCon, Red Hat Summit, and Interop. Tim is also an O'Reilly Media published author and has been covered in publications around the globe including USA Today, Fortune, NBC News, CNN, Forbes, Dark Reading, TEISS, InfoSecurity Magazine, and The Straits Times Follow Tim at @TimInTech on Twitter and at mackeytim on LinkedIn.

More from Managing security risks