Employees use open source applications in organizations of all sizes and across all industries, and this trend shows no signs of slowing down. It is both cost effective and efficient to incorporate source code into software during the development stage. With all those extra resources, developers can focus more on the organization’s proprietary code.

According to a GitHub survey, 94 percent of respondents reported using open source applications at least occasionally, while 81 percent used them frequently. In fact, 82 percent of developers said their employers accepted the use of open source software, and 84 percent were encouraged to use open source code in their applications.

Sign up for a Free Trial of IBM Application Security on Cloud

Striving for Continuous Delivery and Security

Despite the cost- and time-saving benefits, open source components come with liabilities in their licensing agreements. Additionally, about 1 in 16 open source download requests is for a component that contains a known vulnerability.

With waterfall-based development cycles, the pain of vulnerable open source components was evident, but not as crucial as it is today. Agile development cycles are fast and assume that with each sprint, a usable and safe product can be released to the market. How can this need for a continuous and agile development process be synced with the necessity to keep one’s solution perpetually safe from open source vulnerabilities?

Figure 1: Comparing the traditional, uncoordinated service delivery life cycle with the modern method of continuous application security testing (Source: Forrester, May 3, 2016. Amy DeMartine — “Gear Up for Modern Service Delivery.”)

Detecting Vulnerabilities During Development

But what about open source code, which is now more common in organizations’ product code than proprietary code? In the February 2017 Gartner Magic Quadrant for Application Security Testing report, analyst firm Gartner stated, “By 2019, 80% of application security testing vendors will include software composition analysis in their offerings, up from 40% today.” (This report is licensed by IBM and available here.)

That represents 40 percent growth in just two years. What does it mean for you, the client, to have software composition analysis (SCA) offered as part of the regular application security offering, alongside static analysis security testing (SAST), dynamic analysis security testing (DAST) and interactive application security testing (IAST) solutions? Mainly, Gartner’s prediction suggests that you will probably be able to leverage one vendor’s portfolio of solutions to test your application, whether legacy, modern, mobile or composite.

Figure 2: Types of Application Security Testing Tools (Source: Forrester, Aug. 7, 2017. Amy DeMartine — “Vendor Landscape: Application Security Testing.”)

Three Steps to Prevent Vulnerabilities From Getting Into Your Code

Nowadays, application security tools will intervene in the software development life cycle (SDLC) as soon as they can. At best, they will be tied to the organization’s build tool and will fail the build if they contain vulnerable components or at least notify the release manager of all vulnerable components.

For development managers and chief security officers (CSOs), such day-to-day practices can achieve five out of six DevOps security imperatives: automation, speed, coverage, detection and remediation.

But what about the sixth imperative, prevention? This is where future best practices would come into play, empowering your developers to prevent vulnerable open source components from getting into your code. To accomplish this, security leaders should take the following steps:

1. Define open source policies to be enforced automatically. At best, your SCA tool will empower you to set policies on pretty much anything. Examples of items that you might want to enforce include severity of security vulnerabilities, licensing groups, bug ratings and library ages.
2. Empower your developers to download only secure components. Use a browser extension to alert developers on vulnerable open source components before they download them.
3. Leverage the crowd’s wisdom to implement policies that similar organizations have already implemented. It could be the policies of development groups from similar verticals, such as health care and financial services. It could also leverage the implemented policies of similar-sized organizations. Learn from the experience of others to proactively keep security vulnerabilities out of your code.

Bringing it All Together

Continuous delivery and security of composite applications will soon become your day-to-day practices. Be sure to claim the next step’s best practices — the ultimate shift-left capabilities that empower your developers and prevent security vulnerabilities from getting into your code.

To learn more about the value of open source application security testing for your organization, consult our infographic. You can also take advantage of our complimentary trial of IBM Application Security on Cloud, featuring IBM Open Source Analyzer.

Sign up for a Free Trial of IBM Application Security on Cloud Today