Supply Chain Security Risks & Best Practice

Rather than creating apps entirely from first-party code, modern development teams use a mix of proprietary code (that company's "secret sauce") with a lot of third-party components. These third-party resources — many of which are open source — are invaluable to developers, saving time and leading to better innovations. But a new level of risk comes alongside the endless possibilities of open source software, in the form of software supply chain security. 

What are the security risks in the supply chain?

But why do today’s organizations need to keep such a close eye on their software supply chain? The software development world is constantly in flux. Your organization’s developers leverage numerous components in their applications daily in order to avoid reinventing the wheel. Each of these components has dependencies, and those dependencies have dependencies. Your business is at risk if anything within that chain contains known critical vulnerabilities.

We can take SolarWinds Orion Security Breach as an example of supply chain cyber risk causing lasting repercussions.

Here are a few common supply chain threats:

• Vulnerable open source packages/containers. For example, the average npm package brings 79 third-party packages and 39 maintainers into your software supply chain. By downloading this single component, you’re introducing an entire attack surface. 

• Typosquatting/brandjacking. This is an attack technique in which bad actors push malicious packages to a registry, using names similar to a legitimate package. Users who don’t check the security of their open source packages are at risk of downloading one of these malicious resources by accident. 

• Data management. Many organizations just don’t know what’s inside their software supply chains. Their Software Bill of Materials (SBOMs) quickly become outdated because they don’t update it whenever a developer adds a new or updated open source package or container. 

• Access rights. Organizations grant too much access to third-party vendors or components, meaning this third party could become the weakest link of their supply chain if compromised. 

• Human error or negligence. Mistakes happen when teams don’t keep software supply chain security best practices in mind. A developer could download a malicious package or allow a third-party vendor to access sensitive information. There are a lot of ways that human error can put the entire SDLC at risk. 

You can learn more about supply chain security with our recent supply chain whitepaper.

Why just writing an SBOM isn’t enough

While many organizations understand the risk of using third-party components, they often use an incomplete approach to security in their supply chains, which can lead to attacks. It’s common to assume that creating an SBOM is enough to secure a software supply chain. It's understandable why this is the case: SBOMs are front-and-center in many security conversations nowadays (and were highlighted in a recent executive order as well).

But it turns out that an SBOM is really just a “list of ingredients.” And similarly to packaged food, they often contain entries as confusing and unknown as something like "polysorbate 80.” You might recognize the ingredient, but is it good or bad?

To take the analogy further, an ingredient viewed as harmless in the past could become something to avoid later (for example, red dye #5). SBOMs are the same. Just because your SBOM is good today doesn't mean it will be good tomorrow. Your organization must implement a few other ongoing supply chain security best practices to prevent risk successfully.

Supply chain security best practices for your organization

There are five supply chain security best practices that development teams should follow. They include scanning open source packages/containers, using the correct packages (and avoiding malicious ones), maintaining an accurate SBOM, implementing RBAC policies, and prioritizing team education/training. 

Let’s break down these best practices:

1. Scan your open source packages/containers for vulnerabilities, then establish policies

Manually tracking all open source packages/containers and checking them for vulnerabilities is unrealistic. Instead, invest in a tool that consistently checks your software supply chain for vulnerabilities. Proactively prevent vulnerable components from traveling downstream by setting up policies that guide developers to swap this risky open source software for better alternatives early in the SDLC.

2. Ensure you’re using the correct packages

Because typosquatting/brandjacking is such a prevalent supply chain threat, it’s important to double-check every package. Establish checkpoints for open source packages as early as possible in the software development lifecycle using an SCA tool like Snyk Open Source. To make it realistic for your development team to follow the guidance from these checkpoints, plug security scans into their workflows, such as the CLI of their CI/CD pipeline tools.

3. Keep records of what is in your applications (SBOM)

SBOMs are vital to any business’s software supply chain best practices. Because the modern SDLC changes so rapidly, consider using SBOM automation tools. 

In addition, teams must keep tabs on who has access to their SBOMs. Let’s say your SBOM is readily available to a broad audience, and a newly-announced critical vulnerability is inside your software. Now the SBOM itself is a supply chain security threat!

4. Implement comprehensive RBAC policies

Role-based access control is about the principle of least privilege: defaulting to the minimum amount of access each user needs to do their job. To establish RBAC policies, your team needs to know who has access to what and which level of access they have. Policy as code (PaC) enables security teams to define these RBAC policies in code using a high-level declarative language. It centralizes policy efforts, applying them universally across the whole organization. 

5. Prioritize team education and training

To prevent issues caused by human error or negligence, educate and train your staff on potential supply chain threats. Gamification is a great way to encourage developers to learn about supply chain security best practices. Celebrating team members when they contribute positively to your organization’s security efforts is also essential. Snyk offers free security lessons for developers, check them out here.

Using Snyk to secure your software supply chain

Snyk’s supply chain security solutions enable development and security teams to come together and secure their software supply chain. We work with organizations to protect their open source libraries, developer tools, container images, and cloud infrastructure. By interfacing directly with existing development tools and workflows, our developer-first security platform makes it quick and easy for teams to follow supply chain security best practices. 

Want to find out more about security in the supply chain? Check out our cheatsheet, “8 Best Practices for Securing Your Software Supply Chain.”