Making SCA part of your AST Strategy

Open source software is now used in nearly every organization, which makes it critical to know your code. Learn how an SCA tool can help you.

Integrating SCA Tool in AST Strategy | Synopsys

There’s an ongoing sea change in how developers ensure a more secure software development life cycle (SDLC).  “Shift left” is the notion that creating high-quality software begins with planning and continues through the development and testing stages to actual deployment.

Many organizations have realized that waiting until the testing or deployment stages to begin looking for security flaws impacts productivity, disrupts schedules, and increases costs significantly, as has been reported in several studies. For example, a paper presented to the IEEE in 2018 reported that security flaws found early in development are generally easier to solve and cost significantly less compared to finding them later in SDLC stages.

Successful application security testing (AST) strategies require a full security portfolio to locate and address code quality and security flaws. Software composition analysis (SCA) tools—often integrated directly into the IDE—are increasingly being used at the development stage to provide early warning of potential issues in open source components as they are introduced into the code.

What is an SCA tool?

SCA products analyze applications during the development process to detect open source software and other third-party components (in broad terms, anything other than proprietary code). SCA tools typically produce an inventory, or bill of materials (BOM), of all open source in the codebase, the versions of that open source, the download locations for each project and all dependencies, the libraries the code calls to, and the libraries those dependencies themselves link to.

SCA tool creates bill of materials | Synopsys

The concept of a software BOM derives from manufacturing, where the classic bill of materials is an inventory detailing all the items included in a product. When a defective part is discovered, the auto manufacturer, for example, knows precisely which vehicles are affected and can begin the process of repair or replacement. Similarly, maintaining an accurate, up-to-date software BOM that includes an inventory of third-party and open source components is necessary for organizations to ensure that their code is high-quality, compliant, and secure. As in manufacturing, a BOM of open source components allows you to pinpoint vulnerable components.

Beyond inventorying, SCA tools advise of known open source vulnerabilities found in the code and available security patches, as well as the license(s) used to distribute the respective open source packages. Comprehensive SCA solutions also provide customers with early notification of vulnerabilities and even deliver upgrade/patch guidance.

Looking at Gartner’s Market Guide for SCA

Gartner’s 2020 report, Market Guide for Software Composition Analysis, relates that interest in SCA tools is growing rapidly, with inquiries to Gartner on the topic increasing nearly 40% from 2019 to 2020—a result and acknowledgement of the prevalence of open source components in today’s software.  As the 2020 Open Source Security and Risk Analysis (OSSRA) report from Synopsys details, 99% of the 1,200+ codebases audited contained open source components or libraries, with open source making up 70% of the audited codebases.

benefits vs risk of open source | Synopsys

Without SCA, the Gartner report notes, “the benefits of OSS (open source software) in application development can easily be overwhelmed by the risks.” Interestingly, while security and license compliance risks rank among the most significant challenges with open source according to the Gartner report, concerns related to the long-term viability of open source projects was found to the #1 concern of their respondents.

The problem of project sustainability

Project sustainability is a growing problem in the open source community. There’s no guarantee that the people behind any given open source project will continue maintaining the code indefinitely. In fact, of the 1,200+ codebases examined for the OSSRA report, 88% contained open source components that had had no development activity in the last two years.

As software ages, it loses support. With open source, the number of developers working to ensure updates—including feature improvements, as well as security and stability updates—decreases over time. The component becomes more likely to break—or open a codebase to exploit—without the support needed to provide fixes.  Without SCA tools in place to identify the risks that legacy open source can create, organizations open themselves up to the possibility of issues in their software.

“SCA will continue to grow in importance as an element in organizations’ AST toolsets,” the Gartner report concludes. “This will include evaluations of the viability, stability, and provenance of packages. Tools will begin to provide warnings of packages that are maintained by a small group, where updates or responses to reported vulnerabilities lag, or when control of a package changes from one group to another.”

Gartner 2002 Market Guide for SCA | Synopsys

*** This is a Security Bloggers Network syndicated blog from Software Integrity Blog authored by Fred Bals. Read the original post at: