What You Can Do to Stop Software Supply Chain Attacks
In my previous blog post, I looked at how software supply chain attacks work and what you can do to assess and analyze your security posture. Now, let’s figure out how to use the resultant information to harden your software supply chain against threats.
Use SBOMs
The Software Bill of Materials (SBOM) is an increasingly important tool for managing supply chain security. An SBOM is a detailed breakdown of the different software components that are used in applications. SBOMs include metadata, like software origin or licensing terms, version number or release date, code packages, libraries, and other package dependencies. It may also include underlying systems and perhaps the programming language in which the application was coded.
An accurate SBOM gives you better visibility, transparency, accountability, and management of the software supply chain. With the use of an SBOM, you can see which components meet regulations, industry standards, and best practices. You can track and manage applications’ components, and you can better identify and address any potential security vulnerabilities, malicious packages, other security risks, and compliance issues. When any application undergoes a major update, ensure that the SBOM is updated, using a dedicated SBOM generation tool.
SBOMs are becoming an increasingly critical tool now that more regulation from governments and industry groups is being introduced to strengthen software supply chain security. The U.S., the U.K., the E.U., Australia, and New Zealand have already introduced cybersecurity strategies, which will obligate software and application providers to be transparent about the provenance of their products, be accountable for them, and follow best practices to secure their software supply chains.
Apply software supply chain security best practices
So, what are the best practices that organizations should implement? In short, they break down as follows:
- Develop a comprehensive supply chain risk management process. Identify potential risks, assess their impact, and establish security requirements to manage those risks.
- Develop and practice your incident response plan. Respond to issues quicker and more efficiently, minimizing damage caused by attacks.
- Review and improve your processes regularly. Ensure all requirements and controls are up to date with the latest versions and regulations.
- Educate and train employees and stakeholders to follow best practices.
- Don’t disrupt business. Make your processes easy to learn, adopt, and implement. Make them a seamless part of your teams’ regular workflow. Use tools like code signing, digital certificates, multifactor authentication, and secure software distribution, to minimize risks.
Know your components
To build strong supply chain security, you need to answer the following fundamental questions about every component of your software:
SBOMs answer the first two, providing a machine-readable, easily communicated inventory of all of the items inside your product. Finding the answers to questions 3 through 5 is more complex. These questions revolve around safety. To answer them, you need to know:
- Who your suppliers are, and how secure their systems are
- What every component does–and confirm that this is actually what that component does
- All versions are up to date
- When, if, and how do components become unsafe
- Where issues appear
As up to 90% of code is open source, you must know who the suppliers are. Remember that attacks can leverage a supplier you think you know, or trust. You’re always vulnerable to attacks that are currently happening, such as typosquatting, dependency confusion, and dependency hijacking.
The threat of malicious packages
We see a lot of attacks using new packages that display undesired and unclear behavior, especially spam packages, which spread like wildfire.
New libraries also don’t get flagged as bad behavior because they may not necessarily be damaging. In the case of something like obfuscated code, there’s often no actual malicious behavior. So, people begin to develop trust that can then be exploited.
Then there’s malware — bad behavior, or dormant things waiting to behave badly. The key to staying a step ahead is to stay up to date.
Stay up to date with known vulnerabilities
It’s shocking how many people focus on the unknown when they have huge attack surfaces of known vulnerabilities. Attackers often leverage known vulnerabilities that haven’t been fixed, so it’s important to remember that out-of-date code equals risk, especially with open source.
While good access control, risk management, and design will limit the impact of a known vulnerability, it’s better to just ensure you have few known vulnerabilities and mitigate them as needed. Therefore, my top recommendation is to automate dependency updates. Many tools will tell you what dependencies need updating. The good, advanced ones will create a pull request so that you can automatically merge the update. Your infrastructure, your containers, and your application code should also auto-update.
Constantly monitor and prioritize
Automated scanning is vital, but it can’t cover everything. You need tooling that constantly monitors and prioritizes vulnerabilities. When something goes out of date or has a new vulnerability, it gets flagged and you can address it. That means you need software composition analysis (SCA).
Prioritization is important because not all vulnerabilities need your attention. You need a central inventory or SBOM. If you’re a big enough company, you need one that covers all your products and is searchable, because when a serious issue like Log4j emerges, you need the capability to search for it throughout your code base and get answers almost immediately.
If you don’t . . .
If you don’t take these steps, your threat surface expands. You become vulnerable to new issues, which create plenty of noise that developers hate. This complicates workflows, and fixes and updates get missed.
