Holistic Product Security Part 1: Open Source Software Risk

Continuing the series on Product Security, in this article we will explore some resources and steps you can take to address the biggest risk in your product’s software by implementing a secure software development framework, which is foundational to creating a holistic product security approach.

As a Product Security professional, it can be easy to get overwhelmed by the number of security frameworks and standards that apply to your organization. The frameworks are designed to benchmark the maturity of your security practices, and can provide you with milestones for creating a holistic security framework. In addition to risk, you will have to consider factors such as cost, feasibility, and applicability when considering which practices to use, and how much time and resources to devote to each practice.

Frameworks that we find useful include the Secure Software Development Framework (SSDF), Supply Chain Levels for Software Artifacts (SLSA), and OWASP Top 10. Depending on your business, you might be required to comply with standards such as IEC 62443, NERC CIP-013, or Executive Orders such as 14028. 

We will discuss these in future articles, and focus for now on secure software development.

NIST SSDF: Secure Software Development Framework

Developing and maintaining secure connected products starts with secure software development practices. Most security vulnerabilities in connected devices originate from software, and may come from third-party open source or proprietary software, first-party code written by your teams, or insecure ecosystems the device communicates with.

The SSDF (defined in NIST SP 800-218) describes a “set of fundamental, sound practices for secure software development,” and specifies four major practices:

• Prepare the organization, so that people, processes, and technology are prepared to perform secure software development
• Protect all components of their software from tampering and unauthorized access
• Produce well-secured software with minimal security vulnerabilities in its release
• Identify residual vulnerabilities in software releases and respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future

In this article, we are going to focus on the last two bullet points.

Open Source, the Biggest Security Concern

According to Synopsys’s 2022 Open Source Security and Risk Analysis Report, 97% of Manufacturing and Robotics products contained open source - a number that increases to 100% for Energy systems and Internet of Things. 78% of code in codebases was open source, 81% contained at least one vulnerability, and 88% contained components that had no new development in two years. It is clear that modern products rely on open source software, many open source projects have vulnerabilities, and much of that software is no longer maintained.

So what are we to do? Know the risks so we can mitigate them.

Executive Order 14028 on Improving the Nation’s Cybersecurity lays the groundwork and requirements for improving cybersecurity by enhancing the security and integrity of the software supply chain. One of the core requirements is that government agencies will require a Software Bill of Materials (SBOM) during procurement for all software and products they purchase.

Having an SBOM is a great first step for transparency, but you should be going a step further. The SBOM should be used for continuous vulnerability assessment.

SBOM management tools correlate the detected software with known vulnerability databases, exploit intelligence, and threat actor intelligence, and can notify you when there is an emerging risk, such as a new vulnerability against a software library in your product, or a new botnet leveraging an exploit against that software. 

Generating SBOMs, and continuous vulnerability assessment of your SBOMs is a key to achieving bullet points three and four in the SSDF. There are multiple “types” of SBOM, including “Source,” “Build,” and “Deployed.” These SBOMs are generated during the different phases of the software development lifecycle, and are likely to differ in their contents. For example, a Source SBOM may contain testing libraries, a Build SBOM may not contain software components that are present in the source code after compiling, and a Deployed SBOM may contain the Operating System and related services that are not part of the business logic code.

Integrate SBOM Generation into your SDLC

The first step to gaining visibility into the software included in your product is to actually generate an SBOM. You will then want to use SBOM management tools that enable continuous vulnerability monitoring. Your SBOM management tools should support integrating with your developer’s IDE via plugins, and uploading SBOMs via API to support your CI/CD pipeline. Ideally, you can set up notifications so that you know immediately if a new critical vulnerability affects software in your product, and you can investigate and remediate, if necessary. 

There are multiple Software Composition Analysis (SCA) tools that integrate into IDEs so that your development team can create an accurate “Source SBOM” while they are building the code that runs the business logic of the product. Analyzing the source SBOM can give real-time insight into the risk posture of the product before it even ships, and enables the development team to be aware of security risks, and select the most secure software libraries. 

Integrate “Build SBOM” generation into your CI/CD process. The final software build may include software projects from multiple teams, and can introduce additional dependencies in the process of building a releasable artifact. Analyzing the SBOM with SCA and Binary SCA tools at this stage can give you additional security insight before your teams move ahead to final system image generation. Shift-left with SBOMs as much as possible to save your incident response team valuable time later.

Many modern connected devices are actually entire computers in a smaller form factor - they have a full Linux or other operating system, a file system with attached storage, and at least one network interface. The last step in getting the product to run the code may include configuring the operating system, and getting the software artifacts to run on it. The operating system may include many additional software libraries and drivers, and the OS itself may have known vulnerabilities, or be targeted after you ship your product. Analyze the final system image with Binary SCA tools to generate a “Deployed SBOM” and get a full picture of the software risk for your connected product. 

Conclusion

The first step to developing secure software is visibility into the software you are putting into your product, beyond your first party code. In future articles, we will go into more detail about other tools your developers can use to develop more secure first-party code, and discuss additional frameworks that are useful for creating a holistic product security program.

About the Author

Nicholas Vidovich is Principal Product Manager with Finite State, the company building the Product Security Platform with market-leading Product Security and Risk Management. He works directly with Product Security teams at global device manufacturing companies and Asset Owners at critical infrastructure utilities, and is committed to Finite State’s mission to protect our connected world.