Is A Data Breach Lurking In Your Software Supply Chain?

Chief Product Officer at GrammaTech, where he leads product strategy for the company’s application security testing product portfolio.

Just as the manufacturing sector has adopted the use of third-party providers to build their products, software development has created an extensive supply chain to address cost and time to market pressures for faster delivery of new applications and services. Virtually every modern custom-developed software application contains third-party components. These can be open source (OSS), custom ordered or commercial off the shelf (COTS) components. Lack of visibility into these building blocks poses a significant, and often underestimated, security risk. 

Consider the supply chain analogy in aerospace manufacturing. Today, virtually every part of an airplane is provided by third-party suppliers to the manufacturer for final assembly. Unlike software, each airplane has a detailed bill of materials that contains an audit trail for each component, including the supplier, where it was produced, technical specifications, part revision, size and more.

On the other hand, custom-developed software applications used in transportation, critical infrastructure, government, health care and all other industries lack this basic bill of materials. The underlying components present in third-party software are typically unknown to the organization using it, including any open-source code that may be delivered as part of the application. Without a detailed inventory of what’s in the code, namely a software bill of materials (SBOM), organizations are flying blind and unable to assess and resolve underlying security vulnerabilities.

Meanwhile, OSS security vulnerabilities provide easy access for hackers to carry out a data breach, since all the information they need to exploit a software bug is publicly available. To complicate matters, the widespread use of OSS in the software supply chain creates a huge pool of potential victims when a vulnerability is disclosed in a popular component. This creates an even greater incentive for hackers to exploit it.

As soon as a security vulnerability and its mitigation are posted online, hackers are likely developing exploits to take advantage of it. This creates a race against time with attackers. Without the SBOM discussed above, quickly identifying at-risk open source components in both under development and in-production applications is virtually impossible.

The Apache Struts vulnerability used in the Equifax breach is the most famous example of OSS security risks. The breach compromised the data of more than 148 million U.S. customers. The vulnerability was announced, and a patch was released in March 2017. Less than six months later news of the Equifax breach broke, which was made possible by an unpatched version of Struts. 

Creating a SBOM is essential to detecting and remediating known vulnerabilities in both open-source and purchased software — and establish traceability poses unique challenges.   

For example, second-party software, which is developed for a particular application or set of applications by contracted vendors working from a specification, may not disclose the presence of open source components.    

Meanwhile, third-party software, also known as COTS, which is purchased from a vendor, may also contain OSS that is unknown to the licensee.

Achieving an SBOM to know whether software vulnerabilities exist in an application’s supply chain of components requires analytical capabilities known as software component analysis (SCA). This approach analyzes the actual code that will run, not the build environment, which refers to how the application is assembled for deployment. Trying to identify OSS in build environments generates false positives due to superfluous code and components that are excluded due to build configurations.

Inventory and supply chain risk management is well understood and required in physical product development. With the digitalization of many physical products, including automobiles, critical infrastructure, medical devices and more, managing the security and safety of software supply chains is no longer optional. And achieving that starts with understanding the risk that’s lurking in your software supply chain. SCA technology was designed to address this blind spot.

To get started with SCA, consider these best practices:

Create an inventory of all applications in your environment that may contain third-party code, including internally developed software used by employees or customers, as well as applications from third-party vendors such as videoconferencing, etc.

Rank applications according to the amount of risk they pose to the organization if compromised. For example, customer-facing applications that could expose personally identifiable information pose a higher risk than internal applications with limited access to confidential information.

Begin with the highest risk applications first and use SCA to assess them for the presence of third-party components and documented security vulnerabilities — and develop a remediation plan. 

Maintain an SBOM (software bill of materials) for each application and develop an automated process for monitoring new vulnerability disclosures that affect the components present in your applications, so they can be patched or remediated in a timely fashion based on their risk severity to the business. 

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?

Source Article