Your software supply chain comprises everything that touches an application or plays a role in its assembly, development, and deployment. It also includes proprietary code and components created by your development team, as well as the infrastructure used to build and deliver that software to your end user.

Here are five areas of consideration that should drive your security activities. Answering these five questions will yield important information into areas of success and weakness in securing your supply chain.

1.) Is the open source you use secure?

Open source comes from an uncontrolled source: developers outside your organization. Securing your supply chain means maintaining visibility into everything your applications are composed of, especially when it comes from external sources.

It’s important to note that developers include open source in their work both intentionally and inadvertently. The same is true for your vendors; their developers may unknowingly incorporate open source into their projects. While this is not inherently a bad thing, it does introduce an avenue for upstream risks to find their way into your applications. It is your responsibility to track open source components, licenses, and vulnerabilities, and their associated risk, in your supply chain.

2.) Are you required to provide a Software Bill of Materials?

There are many avenues through which software can enter an application. Intentional and unintentional (i.e., transitive dependencies) additions can enter via:

• Package managers
• Copy/paste and AI-generated snippets
• Languages such as C/C++ that lack package managers
• Container images, dynamic link libraries, and other third-party binaries or libraries

All of which creates a broad risk surface and obscured visibility. Without a complete, dynamic view of what’s in your applications, neither you, your vendors, nor your consumers can confidently determine what risk you’re exposed to. Maintaining a Software Bill of Materials (SBOM) is a best practice and the cornerstone of a successful supply chain security program.

3.) Is the code you write secure?

Security defects and weaknesses that are inadvertently coded into applications open the door to attacks such as buffer overflows, SQL injection, and cross-site scripting. Should a system breach occur, these security defects leave sensitive data vulnerable to exposure.

Efforts to avoid these issues usually include code reviews in hopes that more sets of eyes on source code will help identify issues. However, most software developers are not trained in secure coding, and many security flaws are too complex to spot and trace during manual code review.

Static analysis solutions that can automatically review code execution and data paths as well as identify security weaknesses are essential tools in ensuring you can trust that you’re not introducing any downstream risk.

4.) Is your development and delivery infrastructure secure?

Containers make it easy to rapidly deploy, patch, and scale an application or microservice, but they also introduce additional avenues for threats to enter the supply chain. The most common approach developers take when containerizing applications is to start with a base image, often open source, and build on top of it. Layers of additional third-party and custom code are added on top of this base image, and then combined into a single filesystem, represented as a binary file, when the final image is being executed.

Only a true binary analysis of the container image can inspect component signatures to identify all open source components regardless of their origin, as well as any sensitive data present inside a container image.

To support virtualization and container orchestration, servers now operate in an ephemeral manner, built up by spec, on an as-needed basis. Previously built and assembled by IT operations engineers, server configurations are now created by development teams, which use infrastructure-as-code (IaC) to easily specify configurations for the applications they’re building.

Just as a static analysis tool should be used to analyze application source code for security weaknesses, it should also be used to scan IaC files to uncover costly configuration mistakes that developers typically aren’t trained or experienced enough to look out for.

5.) Do you create or consume software within a regulated industry?

The U.S. Food and Drug Administration (FDA) is mandating that all medical devices running software must create and maintain an SBOM. If you’re building on Linux, your software likely incorporates other open source components such as middleware and front-end frameworks, all of which must be regularly reported to the FDA through an SBOM.

The National Institute of Standards and Technology (NIST) developed the Secure Software Development Framework (SSDF) to improve cybersecurity within the federal government. Eventually, all software obtained by the federal government, excluding free software or internally developed software, will be required to comply with the SSDF.

What’s next

Examining your existing security activities in conjunction with the questions posed here will help you identify areas of your supply chain security that are weak and need attention.

Learn how Synopsys can help you achieve end-to-end software supply chain security.