Reducing supply chain risk requires visibility, provenance and security. This piece explains how a software bill of materials (SBOM), segmenting and restricting access, can help secure the supply chain.
Supply Chain Risk for Enterprises
Every organization, large or small and regardless of vertical, is susceptible to supply chain risk—aka the idea that malicious code or objects can be introduced to your software upstream in the software procurement workflow. These can come from
developers introducing open source or closed source libraries into their code, an outsourced subprocess that uses compromised code or even a third-party update server with credentials hard-coded into the GitHub repository.
Modern software comprises many components, including libraries and modules, which can be open source or proprietary. Any one of these can become compromised and give an attacker access to your environment. Sometimes, as in the case of Log4j, components are widely used, and a single vulnerability can have far-reaching implications as teams scramble to determine what software is running the affected components. To properly secure the supply chain, organizations need visibility into all the components and dependencies within each and every application they build and run.
If your software relies on a library that turns out to have a vulnerability, and your incident response process isn’t fast enough in the opinion of an outside party, there is a potential you may be liable and your cyber insurance may not cover
it. Depending on what that software manages, you may have very large liabilities, ranging from loss of business revenue to health and safety (loss of life and/or health).
Using SBOMs to Reduce Supply Chain Risk
To reduce supply chain risk, you need visibility, provenance and security.
An SBOM provides the visibility you need to understand what is in your application. An SBOM is a comprehensive inventory of all the software components, dependencies and metadata associated with an application.
Some organizations are starting to use external providers that specifically focus on providing visibility via SBOMs. Once integrated with the software provider, the external provider accepts their SBOMs and tracks all libraries, modules and “chunks” of code to ensure everything is up to date and all vulnerabilities arising from supplied code are handled or known—hopefully both.
Organizations should require SBOMs from all code suppliers—and they should use them. When a flaw or vulnerability is discovered in a component, refer to your SBOMs to identify software with the vulnerable component, assess its usage and understand
the risk associated with the vulnerability. You can then act quicker to deploy patches where they’re needed or apply a custom fix.
The one exception to the rule is your SaaS providers. Because you are not responsible for updating and patching the software, there is no need to request an SBOM. However, you must add those applications to your threat intelligence feeds to stay abreast of any issues with those platforms.
For any IaaS, PaaS, commercial-off-the-shelf or open source libraries used by your in-house developers, you must require SBOMs from the software provider and use them to keep a defensible, usable, liability-reducing provable provenance.
- An asset inventory of all hardware and software: This includes all software modules and libraries. If you don’t know what you have, how can you request SBOMs on all of it?
- An information inventory of all mission-critical information, at a minimum: While not mandatory for this purpose, it helps to understand what your mission-critical applications are and which applications to prioritize getting SBOMs for.
- Linking your threat intelligence feeds to your SBOMs: This ensures a threat to a specific library is immediately picked up and alerted upon.
- Segmenting off all modules/functional areas of software and networks: Every functional area/microservice should communicate with other microservices via a secure, encrypted channel, typically an API. All internal and external connections must be secure
and encrypted. This ensures if an application is compromised—whether from an internal, external, supply chain or other source—it is restricted in what it can harm or harvest.
Locking everything down via endpoint detection and response and host firewalls: Ensure all traffic is authenticated properly. Implement step-up authentication for traffic to mission-critical/restricted information. Again, even if an application
is compromised, this will restrict information access and potential information leakage.
SBOMs in Supply Chain Security
Managing supply chain risk can lead to measurable improvements in security and compliance maturity. Show your metrics on how much you’re ramping up visibility into your suppliers, third parties and vendors. It’s an amazingly powerful set
of metrics to show a board not only how well you’re doing, but the “bang for the buck” by reducing cyber insurance costs and reducing ransomware/malware risks. After all, the NIST Cybersecurity Framework (CSF),
Executive Order 14028 and many other standards are starting to list supply chain risk management as a measurable indicator of
security maturity.
To help make the most of SBOMs in your supply chain security, consider the following guidance:
- Measure your progress: Use the NIST CSF to measure risk management and use the Cybersecurity Maturity Model Certification or Capability Maturity Model Integration to measure security maturity.
- Don’t stop the business from operating: Try listening to them. If an SBOM is a detriment or causes friction, try working with the business to alleviate it. Sometimes this can happen if a supplier just doesn’t want to do the work or the
business is afraid it will add too much time to validate a vendor.
- Above all, plan what you’re doing and work with your supply chain partners. Offer to help them implement the creation of SBOMs for themselves and gain some significant goodwill and better security on that entire supply chain, as well.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.