Open source software components may contain vulnerabilities. How do I improve code security?

During the study, Gartner experts came to the following conclusions.

• Open components source code carry many risks, including well-known problems such as vulnerabilities and disadvantage conditions, licensing while simultaneously increasing the need to assess operational risk and identify malicious code and other attacks on the supply chain. ON
• Customers have to navigate an increasingly complex market that includes solutions with different origins (open source solutions, independent solutions, AST packages and development platforms), which complicates assessment and selection.
• The application development teams and DevOps, along with the security team, are interested in purchasing application security testing tools, including software composition analysis.
• Software supply chain issues encourage the addition of new features to software composition analysis tools, including operational risk assessment and malware testing. However, most suggestions are immature when it comes to this functionality.

What does Gartner advise security executives?

To minimize the risks associated with using open source, Gartner experts recommend following the following rules:

• Implement Software Composition Analysis (SCA) tools to better identify threats and enforce open source policies
• Consider instruments with different origins and use strong market competition to get the best prices
• Involve all stakeholders (security, development, risk management, procurement, etc.) in the purchase of products, regardless of the final source of the budget, to ensure that the functional requirements are fully met;
• Use vendor services that offer an operational risk assessment and can conduct tests and assessments to identify malware or other malicious code in open or commercial dependencies.

Thus, Gartner experts note the formation of the SCA solution class, the market of which begins to acquire a clearer silhouette.

What is SCA

Composition Analysis Solutions software (SCAs) analyze enterprise applications, usually already in the development process, so that to identify embedded open source components and, sometimes, commercial products within projects the customer. In addition, SCA tools identify known vulnerabilities in these packages, which increases development efficiency, i.e. reduces the cost of fixing defective code. They can also define the license under which a particular component is distributed, making legal risk assessment easier. Given the challenges of supply chains, buyers are also starting to look for SCA tools that provide indicators of operational risk, such as slow or substandard maintenance, questionable project viability and a host of other factors. Individual tools can generate or use standardized material specification artifacts (ON SBOMs), giving them added value.

Why it matters

Gartner notes that almost all organizations use open source components during the development process to improve developer performance, reduce development costs and time. However, as noted above, this carries obvious risks.

Photo source: gartner.com/en/documents/4005759

Today, SCA tools are mainly aimed at identifying known vulnerabilities in open source packages and warning about licenses that can impose conditions that are unacceptable to the organization, so-called virus licenses - requiring the disclosure of the source code of the entire project or payment when it is distributed. Open source components can include other components, which, in turn, add more and more new libraries to the project - transitive dependencies. It is difficult for developers to track such chains of dependency calls. Most mature compositional analysis products generate reports of both direct dependencies (those explicitly specified by the developer) and transitive ones. In some cases, a single direct dependency can result in multiple levels of transitive being included in the code. Thus, a huge uncontrolled blind spot of borrowed code appears. In addition to detecting problematic components, SCA solutions provide recommendations to developers in the form of component version updates or tips for mitigating a problem.

SCA tools and related vendor services can help streamline the use of open source, which establishes and controls the rules for using open source components in applications (or in a broader operating environment). Tools can make independent assessments and scan packages, but the most common use case is direct integration of tools into the development pipeline - into an integrated development environment, into code version control systems or artifact repositories, and on build and integration servers.

Operational risk assessments take into account factors such as the number of developers supporting the project and their reputation, the frequency of updates, the response to reports of vulnerabilities and other defects, and changes in project management. In support of this feature, some tools include the ability to test packages for unexpected changes or malicious code. This functionality is not common, since most SCA tools do not test open source libraries, but rather identify packages associated with known problems. During validation, you can look for changes in the content of the package (for example, embedding an executable file into a package in a scripting programming language), changing the behavior of the application (for example, opening a network connection), including open source fragments in proprietary code or other anomalies.

Gartner believes that these types of operational risk assessments will quickly become fundamental requirements for SCA tools. ON The open source developer community has already taken steps to provide one information for some projects. The Open Source Security Foundation (OpenSSF) has released the automatic security tool Open Source Security Scorecard, which currently time provides 16 different checks for software in different open source ecosystems.

Market trends

Requests to Gartner for the SCA study have increased by nearly 20% in the past year. This reflects the growing recognition of the risks associated with the use of open source in development, and is also associated with attacks on supply chains and proposed government measures. cyber security Gartner estimates that less than half of the companies have implemented SCA tools, but their adoption will grow steadily due to the following factors.

• Increased focus on application security: Many organizations are looking to implement or improve application security programs. SCA is often seen as an "easy win," given the wide distribution of open source, the relative simplicity of detection efforts, and (usually) the relative ease of problem solving. In addition, there is growing recognition of the risks of the open source supply chain, which further stimulates implementation.
• Operational risks: Supply chain attacks on both commercial and open source software have been a problem for decades. These concerns, combined with safety measures taken by the U.S. federal government and other organizations, have sparked interest in assessing operational risks, essentially analyzing the "health and well-being" of open-source projects. Some SCA tools provide such assessments, and this opportunity will become a necessary functionality.
• List of components used: the opacity of the contents of this software package (including direct and transitive dependencies of both open source and commercial software) has been a concern for many years. This is especially true for commercial software, as well as for physical devices (healthcare, manufacturing, etc.), which are highly dependent on software, but the content of which is opaque to the user. These problems led to efforts to create a list of components used - SBOM - or a software material specification describing the elements that were used to create this software package. In the US, the requirement for software providers to provide SBOMs (at least for those who sell software to the US federal government) was established in 2021 by a May US presidential cybersecurity decree.
• Advanced open source management: Gartner experts have long recommended that companies develop an official open source management program that should help identify and manage risks associated with using open source. Such programs are preventive measures to identify, study and approve specific packages of components allowed for use in development projects. Despite its advantages, such programs are difficult to create, given the need for various tools (for example, SCA testing tools, repositories), program support processes, and qualified personnel to maintain the system. Given the market factors already identified, the need for formal management programs will grow, prompting more suppliers to provide support for such measures in SCA solutions.

Application development teams and DevOps are increasingly buying application security testing tools, including SCA. This trend has led to an increased focus on developer-focused tools that are better integrated into development tool chains and offer better developer opportunities.

Bid Analysis

Current SCA products and services offer customers the following options:

• Open source component recognition and identification. Various technologies are used for this, but they are all focused on identifying certain packages using standard programming methods used to add open source components (and other software) to a software product. These can be "include" directives, other instructions, or manifest files, depending on the specific programming language. In addition, scanning of the code itself and/or libraries to identify specific component elements may be used for these purposes. Less commonly, tools examine code for "snippets" - parts of code that have been extracted from a larger component. In addition to detecting specific components (direct dependencies), tools must also identify indirect or transitive dependencies that result from one component including another component, often recursively.
• Open source license identification and risk assessment. Like commercial software, open source is almost always distributed in accordance with the terms of the license agreement, which determines how it is used. There are many dozens of licenses, the terms of which vary significantly. Some are considered permissive, have few restrictions on how the software is used, and have little or no obligation imposed on the user. Restrictive licenses can pose significant legal risk and loss of intellectual property as a result of compliance with the terms of the license. Although the tools will try to specify problem licenses, the decision to use the component on the terms of a specific license must be made in agreement with the legal service.
• Software vulnerabilities. Like any software, open source components contain vulnerabilities that could be exploited by attackers. The most important function of SCA solutions is to identify packages that contain vulnerabilities. This feature has become a hallmark of tools, with vendors relying on a wide range of open and private databases, in some cases replenished by internal research teams, to provide greater accuracy and confidence in conclusions. As noted earlier, as part of this process, tools provide guidance on the most appropriate upgrade path to fix an unsafe package.
• Management and control. Organizations for which all risks are important to minimize often want a greater degree of control over the use of open source components in applications. In such cases, the usual approach is to create a repository of "approved" open source packages. Developers are free to use any software contained in the repository, but other packages must go through the review and approval process. This approach requires resources to review the proposed revisions and keep the "approved" packages up to date in the repository. Regardless of the existence of such "approved" repositories, organizations must scan software during the build process to ensure that unapproved software has not passed through the barrier.
• Operational risk. As noted, assessing various aspects of operational risk is a new possibility. While most buyers remain focused on more traditional requirements (vulnerability detection, licensing), this aspect of SCA will quickly become a critical and expected feature of the tools.
• Reporting and analysis. Creating and sharing software specifications is increasingly important to prevent risks in the software supply chain. The ability to create a formal software specification using any of the published specifications remains rare. Vendors indicate that they support the construction of the specification, but exclusively in the context of their own tools and their own reporting functionality. The ability to create a specification for sharing and integration into other systems (for example, software asset management, configuration management database) will develop simultaneously with regulations requiring their provision.

Customers can choose different solutions.

• Open source solutions. There are several open source tools that perform SCA tasks. Most are designed to support a specific programming language or application environment, although some, such as Open Web Application Security Project's (OWASP) Dependency-Check, provide support for multiple languages. Thus, they are often limited in their capabilities and can rely only on limited sources of vulnerability data when conducting assessments. Such tools usually do not verify the type of license or other attributes of the component useful for assessing operational risk. Still, their availability makes these tools attractive.
• Specialized products. These offerings provide a wider range of important functionality, including license validation, mitigation recommendations, open source management, and policy enforcement. An example is MergeBase, Revenera (formerly Flexera Software) and WhiteSource (now Mend). Vendors such as Tidelift provide customers with a subscription service for the supply of proven components and testing capabilities, which can make it easier to manage open source.
• SAST package component. Most application security test solution providers have added SCA capabilities to their portfolios. An example is Checkmarx, Contrast Security, Veracode, Snyk and Synopsys. In most cases, these tools are offered as an additional component that requires separate licensing.
• As part of the application development platform. Vendors of application development platforms, a rapidly evolving source of application security tools, have begun to incorporate SCA capabilities into their offerings as additional functionality. An example is GitHub, Gitlab, JFrog and Sonatype.

Each customer chooses what is better integrated into their development pipeline or requires less change in the pipeline. We consider it most efficient to use a specialized product.

Gartner advises

• Implement policies based on tolerable risks in areas such as security, legal liability and intellectual property rights, and the viability and integrity of the supply chain. The relevance of each of them will vary for different applications in the organization's portfolio, but even general policy will be useful. This policy can be used to describe the characteristics of an open source component that are acceptable or unacceptable to the organization, and will help determine the necessary product capabilities (vulnerability detection, licensing, operational risk, etc.).
• Security policies must specify the severity and/or types of vulnerabilities that constitute an acceptable risk. These policies should consider the risk profile of a particular application, as what may be acceptable for one application may pose a significant risk of regulatory or security noncompliance for another. Policies should include recommendations to fix vulnerabilities in cases where a fix is not available, or if the required fix should otherwise be delayed. For example, updating an open source component can solve a security problem, but due to changes in functions, it can disrupt the health of an application using such a component, which will require other changes in the application. In some cases, the fix may simply not be available.
• SCA tools generally need to match the pace and scale of evaluation required to support DevOps or other dynamic development approaches. Evaluation criteria should include factors such as:
  • technological coverage - languages, frameworks and open source ecosystems that will be evaluated;
  • depth and breadth of data provided by tools - vulnerabilities, quantity and quality of sources of this data, including determination of license types and relative risks;
  • information on the status and origin of individual components, as well as the possibility of prioritizing this data;
  • Operational "compliance" for the main end users of the product - for example, developers prefer completely different interfaces and sets of capabilities than legal or procurement teams;
  • ability to assist in identifying potential remedial or mitigation measures;
  • Integration into Software Development Lifecycle (SDLC) and other relevant systems.

• When evaluating options, buyers should carefully consider the overall costs. Gartner customers regularly raise concerns about costs associated with security tools, and SCA is no exception. But it seems to be becoming inevitable.

The situation on the Russian market

Access of Russian companies to solutions from the Gartner report is now limited due to the sanctions policy of individual countries. This would be a serious problem if there were no domestic solutions on our market that are not inferior, and often exceed foreign counterparts in their functionality. Domestic manufacturers of static code analysis tools announce individual SCA functions in their solutions.

But there are also specialized tools. The pioneer of SCA in the domestic market is CodeScoring from Profiscope, which fully covers the existing needs today and is actively developing. CodeScoring functionality allows you not only to manage operational and licensing risks, security vulnerabilities, generate a software specification (SBOM), but also analyze the quality of code from the point of view of operational risks. And not all SCA solutions from the Gartner report have such broad functionality.

Read also

• Code Analysis: Problems, Solutions, Perspectives
• Strategy for secure IT product development. Bercut approach