Places for People

The more software you use, the more important security becomes. That is why examining your software supply chain security should not 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 organisations 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 inevitable, but it opens the door to 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 just a matter of time.

Types of Software Supply Chain Risks

When it comes to software supply chain risk management, there are a few of the main types of risk that a CISO should be aware of - security vulnerabilities, third-party software risks, and policy/process risks.

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.

“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.”

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 passwords, keys and tokens.
• Injection of malicious software to your product such as adding backdoors to your product.
• Gaining control of your internal network and services, including the injection of persistent trojans running within your organisation.
• 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.

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 are not always able to effectively and efficiently identify vulnerabilities in both inactive and active libraries though. So when you are 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 the latest or generally mutably tagged versions of packages means that their content might be changed without you realising it. 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 software. This is crucial to more accurately estimate the security posture of the software in your supply chain, even if you are not the developer.

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 artefact 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 regularly.