Software Supply Chain Risks to Be Aware of

Today most business leaders realize that no matter what industry they operate in, their organizations are truly technology companies that serve products and services to their customers. For these technology companies, software is at the very heart of business, enabling important functions such as product development, product delivery and customer service, to name just a few. 

As software technology evolves, it’s being continuously integrated into nearly every aspect of business processes. And while this has given many businesses new tools to make their daily lives and business processes much easier and more efficient, it has also highlighted how important security is and that no company is immune to the impact of a software supply chain security event.

Why Every CISO Should Create a Secure Software Supply Chain

The more software you use, the more important security becomes. That’s why examining your software supply chain security shouldn’t be an afterthought.

Instead, security should be a top priority throughout any phase of software development or software acquisition (i.e. third-party software). The shift-left paradigm focuses security efforts on earlier stages of the development life-cycle. It is becoming more and more popular as organizations understand that many threats must be detected and stopped much sooner – before they reach the end of their software supply chain.

Software supply chain attacks are on the rise and unlike traditional cyber attacks, where hackers exploit a vulnerability to steal information from a single system or company, attacking the supply chain creates a much bigger impact. By compromising a single source or package, attackers can affect a huge number and variety of systems.

Leveraging open source for enterprise software development is basically inevitable, but it opens the door for open-source risks. Unless you take meaningful steps to secure your supply chain and monitor the status of your dependencies, being struck by a compromised dependency is only a matter of time.

The Four Types of Software Supply Chain Risks

When it comes to software supply chain risk management, there are four main types of risk to be aware of: security vulnerabilities, third party software risks, policy/process risks, and licensing risks.

1. Security Vulnerabilities

There are many different types of security vulnerabilities that your software supply chain might be exposed to. Supply chain vulnerabilities in your development pipeline can be used to compromise your production systems, your customers, or your internal networks. As a result, you should consider security vulnerabilities in your software supply chain as critical as vulnerabilities in your final product.

Take a look at the Kaseya hack, for example. Multiple organizations and companies relied on its software to outsource IT departments. The security vulnerabilities found in Kaseya’s software were exploited not only to attack Kaseya, but to also initiate a wide-scale ransomware attack on Kaseya’s users.

The impact of vulnerabilities and missing protection in your software supply chain might include:

• Theft of IP, such as your source code.

• Exfiltration of sensitive data such as password, keys and tokens.

• Injection of malicious software to your product such as adding backdoors to your product.

• Gaining control on your internal network and services, including the injection of persistent trojans running within your organization.

• Affecting the security configuration of your assets, such as databases and cloud services.

To protect yourself against these kinds of supply chain security problems, you should establish security policies that protect your SDLC assets, such as your SCM (source code management) and CI/CD (continuous integration / continuous deployment) systems. Treat your software supply chain as a production system because workloads are now continuously being released to production.

2. Third-Party Software Risks

When your product relies on third-party software for its functionality, it also relies on its security. As incidents like the infamous SolarWinds attack showed, attacks on third-party software might have a huge impact on their users, and they can be really hard to detect, which creates material third-party software security risks for a business.

Dealing with this kind of threat must start with awareness of your third parties. Set SCA (software composition analysis) tools in place to detect/monitor your dependencies and changes. SCA tools aren’t always able to effectively and efficiently identify vulnerabilities in both inactive and active libraries though. So, when you’re trying to root out vulnerabilities in 3rd party software, this can be a major security threat.

In addition, you should always use pinned versions for your dependencies. Relying on lastest or generally mutably tagged versions of packages means that their content might changed without you realizing. Be strict about your requirements: prefer fixed versions of software based on their content (i.e. digest) rather than modifiable versions.

Finally, run your SAST (static application security testing) and DAST (dynamic application security testing) tools on your third-party dependencies, not only on your own software. This is crucial to more accurately estimate the security posture of the software in your supply chain - even if you’re not the developer.

3. Policy/Process Risks

When dealing with supply chain security attacks, it is important to set proper policies and processes in place to be aware of your state of software supply chain security and to mitigate software vulnerabilities.

Internal processes must be established before security issues arise. Preparing escalation & crisis response plans can help cross-functional teams attack and root out security vulnerabilities before a breach can happen.

Internal policies can also help keep your software supply chain secure. Guide your internal development teams by establishing protocols & best practices:

• Prevent the development of risky libraries by filtering out libraries from unreliable sources.

• Sign your code to make sure that all the code that goes into production comes from your trusted developers.

• Use artifact signing tools to ensure the integrity of your packages and prevent malicious registry access from impacting your production systems.

• Require your developers to use multi-factor authentication for their SDLC users.

• Protect your code’s main branches from direct pushes and require multiple-person approval for code changes before they merge to the main branch.

• Use SCA tools and SBOM (software bill of materials) analysis to gain awareness of your software components, track vulnerabilities, and inspect affected components after security relevant incidents (e.g., Log4J).

• Use holistic platforms to get observability on the security controls you use throughout your pipeline and improve your security posture iteratively on a regular basis.

4. Licensing Threats

Software might come with different types of licenses. The Free Software Foundation defines 4 software freedoms:

• Freedom 0 - run the program as you wish, for any purpose.

• Freedom 1 - Access to the source code: study how the program works, and change it so it does your computing as you wish.

• Freedom 2 - Redistribute copies so you can help your neighbor.

• Freedom 3 - Distribute copies of your modified versions to others.

Some other common licenses that are worth being familiar with are:

• MIT / Apache: Users can copy, modify, license, and sub-license the code without limitations.

• GPL: Requires any changes or derivative works to be licensed as open-source as well.

• BSD: Users can copy, modify, license, and sub-license the code, but are obligated to include the copyright and license texts in the copy of the software.

Understanding the different freedoms defined by the license of open source software is essential and if misunderstood, it could have big consequences for your organization. You should note:

• Some licenses might force your organization to open source other parts of the system that were not meant to be publicized.

• Some licenses force you to publish any customizations you made to that software. If these customizations include unique IP for your organization, you might find yourself in a situation where you lose your “secret ingredient”.

• Misusing copyrighted software might result in charges being filed against your organization, which often arrive way after your product is already heavily relying on that software due to lack of awareness at the time.

Let the Experts Help You Secure Your Software Supply Chain

There’s never been a better time than now to start implementing best practices in cyber supply chain risk management. That’s because software continues to be seamlessly integrated into nearly every aspect of business.

To deal with these threats, start by mapping your organization’s attack surface. You can then define and enforce policies for secure development. If you’re interested in learning more about ways to improve your organization’s software supply chain security, check this How To Get Started guide.

Don’t leave your software supply chain vulnerable to the four primary software supply chain risks - Secure Your Software Supply Chain Today.