Open Source Security & DevSecOps: Keys to Success

The recent Equifax data breach disclosure has brought open source software security issues to the forefront, highlighting the difficulty organizations are having adapting application security practices to meet current threats.

The record-breaking breach has been blamed on an unpatched vulnerability in the Apache Software Foundation’s Struts version 2, an open source framework for building Java web applications. A number of Struts vulnerabilities have been announced over the past few months, with the most recent advisory issued by the Center for Internet Security (CIS) on September 15. According to the CIS, “depending on the privileges associated with the application, an attacker could install programs, view, change, or delete data, or create new accounts with full user rights.”

Open Source Predominance

Open source software is a foundational element in the applications we interact with every day—including Google, Amazon, Netflix and Uber—because it is time and cost-efficient, and facilitates productivity and innovation. According to Forrester, developers are using open source components as their foundation, creating applications with only 10 to 20 percent custom code. Unfortunately, many open source components come with liabilities in their license agreements, and one out of every 16 open source download requests is for a component with a known vulnerability.

Open source is not inherently bad; however, many organizations are not effectively tracking and managing it and as a result, are not fully aware of the risks that accompany its use. When the majority of an application is comprised of open source content, it means that the majority of the code can be freely analyzed by attackers—and software applications are a preferred target.

Managing Open Source Security Threats

Applications typically contain more than 40 components; understanding which ones you are using is critical, so that vulnerabilities can be addressed as they are announced. A recent Black Duck Software open source security report found that 67 percent of analyzed applications using open source had vulnerabilities in the components used. Organizations need to increase visibility into, and control over the open source content they use to ensure effective application risk management processes. Many companies currently deploy static application security testing (SAST) and dynamic application security testing (DAST) tools as part of their application security program. While these are very useful at identifying common coding errors that can result in security issues, they are not effective at identifying vulnerabilities introduced through open source components.

Gartner predicts that by 2019, 80 percent of application security testing vendors will include software composition analysis in their offerings, up from 40 percent today.

SCA is among the key tools organizations can leverage to adapt to increased application complexity, along with DAST, SAST, integrated application security testing (IAST) and mediated application programming interfaces (APIs).

In addition to the right tools, integrating security into development processes is also essential, so that it can become synonymous with quality in the minds of developers.

Addressing the Mindset Gap

As Facebook CSO Alex Stamos pointed out during the opening keynote at Black Hat USA 2017, the security community celebrates breaking much more than defense, and needs to work harder to build architectures that are resilient to failure, and relationships between the security side and developers. The gap in the mindsets of software builders and security teams needs to be addressed.

If you put a developer, a penetration tester, and a security analyst in a room to discuss vulnerabilities it will likely end in raised voices, and someone storming off.

“We don't speak the same language. We don't share the same goals”, said April Wright, Senior Security and Compliance Manager for Verizon Wireline during Black Hat. Security’s objectives, she pointed out, involve secure software development lifecycle (SDLC), post-launch/post-release operational security, compliance and sunsetting at end-of-life (EOL). Conversely, the top goals for builders are metrics and market-based with a focus on speed, cost and quality.

It's no wonder, she said, that the builders (Yellow Teams) don't like the breakers (Red Teams) or the defenders (Blue Teams). Security’s interaction with developers is fairly infrequent, and usually only after an audit, or after a vulnerability is found in code. “We scold them after a Red test, tell them what they did wrong. We essentially point out the errors in their art. Imagine that feeling every time they interact with security teams”, she said.

In order for all of us to realize we’re actually on the same team and work effectively together, we need to work to incorporate security into developers’ overall mindset and idea of quality, so that security tools and tests can be integrated into the development pipeline, and security can become a key component of the entire application development process.

Integrating Security into DevOps

New approaches to managing application development have been rapidly evolving. The use of automation, and the alignment of development and operations teams is enabling customized software and business functions to be built more quickly. However, security teams are often still seen as roadblocks, and are therefore left out of the DevOps conversation. Having personnel from development, security and operations collaborate on projects is vital. Security teams need to evolve and move faster in order to keep up and make an impact, so that DevOps and security can be aligned within a new approach—DevSecOps.

What is DevSecOps?

DevSecOps can be thought of as a continuous application delivery model that brings together development, security and IT operations into a unified group to ensure security checks and controls are applied automatically and transparently throughout the software development lifecycle.

DevSecOps is about sustained collaboration, with an eye towards bridging the gap between speed and security.

Planning for DevSecOps

DevSecOps is not unlike a secure application development environment; the difference is the increased frequency of testing and feedback loops, and the components that are tested for—such as open source vulnerabilities, and additional programming languages that support automation and orchestration—on top of what’s already being evaluated. And perhaps most importantly, DevSecOps works toward creating a culture and environment in which development, operations, and security teams work together alongside other stakeholders in the organization towards a shared goal. There are several key elements that organizations need to consider when planning for DevSecOps.

Threat AssessmentWhen planning for DevSecOps, security teams first need to perform threat assessments, so that they have better visibility into the types and sensitivity levels of the assets they are protecting, and the most likely threat vectors for those assets.

Getting Buy-InDeveloping a DevSecOps program requires a commitment on the part of the security team to work side by side with the development and operations teams, and getting buy-in from all of the stakeholders to embed security controls and processes into the entire DevOps workflow.

Putting the “Sec” Into DevOpsSecurity teams need to demonstrate that they can provide a series of tests and quality conditions on production code pushes, without slowing down the process. If security parameters and metrics are incorporated into development and test qualifications, then the likelihood of security being incorporated into DevOps processes is much higher. Additionally, security teams should look to integrate automated dynamic and static code testing throughout the development and production lifecycle to help detect and fix code flaws.

Helpful ToolsThere are numerous application security standards and methods to choose from, such as the Open Web Application Security Project (OWASP) Top 10, ISO/IEC 27034 and NIST 800-53/64. OWASP is particularly useful; since 2001, it has provided a place for developers and security professionals alike to contribute to deep repositories of knowledge around the best ways to detect, remediate, and defend web applications.

OWASP publishes the “OWASP Top 10” list of most common web application security issues, and maintains projects focused on specific web application languages, such as Python, Ruby, and PHP. Two of the projects have been organized into large stores of information focused on two of the most popular languages in the Web Application space, .NET and JAVA. OWASP states that the “Project is a clearinghouse for all information related to building secure web application and services. The goal of the project is to provide deep content for all roles related to (.NET/JAVA) web applications and services.”

In addition to resources such as OWASP, infrastructure as code (IaC) automation tools can help your organization automate and accelerate DevOps processes. Two of the most popular are Chef, and Puppet.

Optimizing Application Security

The DevSecOps movement has just begun; companies have a significant window of opportunity to help change the underlying DevOps culture to embrace security, and make security and compliance controls an integral part of managing the code being developed all the way through to production. By putting security layers in place to address open source components, quickly acting on patch releases and software updates, and better aligning with development teams and IT operations groups to ensure that security principles and communication come into play every step of the way, your organization can accelerate the rollout of innovative new applications while defending against the exploitation of increased attack surfaces, and better managing application risk.