kras99 - stock.adobe.com
4 software supply chain security best practices
The increasing complexity of software supply chains makes it difficult for companies to understand all its components. Learn how to find vulnerabilities before attackers.
It's hard to explain weaknesses in software supply chains. Discussing the "nested" nature of dependencies and how those play out within the supply chain, for example, is a complicated problem. It is a problem that is perhaps much more insidious and difficult than one in a physical or logistical supply chain.
Look at the Log4j vulnerability, which was disclosed in late November 2021 and is one that companies continue to battle. Consider how it played out in most environments. There's the first-order analysis: evaluating your own software -- e.g., in-house software developed either for internal use or to provide to customers -- to determine if you are using the library. Then, there's second-order usage: places you're using an application, middleware or supporting library that uses Log4j. From there, you have third-order use and beyond: determining whether any software deployed connects to software that uses the library.
A vulnerability or risk introduced anywhere along this dependency chain may have unexpected ramifications far downstream that are difficult to predict because of the complexity of the dependency chain.
It's important security teams understand and evaluate their organization's software supply chain. The ground is set for standardization, and that work is underway as per May 2021's Executive Order 14028. Subsequent work by NIST, including an updated revision of Special Publication 800-161, is one such effort. ISO's recent adoption of the software bill of materials (SBOM) standard Software Package Data Exchange as ISO/IEC 5962:2021 is another.
While these standards are being developed and as guidance emerges, there are useful informal best practices that can help organizations in the meantime. The following four practices aren't the only ones that help with software supply chain security; there are many ways organizations use software so organizational needs will dictate specific practices. These stand out for the following reasons:
- applicable to most organizations;
- can be done with relatively little expense -- other than payment in elbow grease -- and
- are good practice beyond the value they provide for software supply chains.
1. Understand software creation processes
It's important to understand the processes for how your company creates software, as well as the processes used in the software you employ.
Techniques can include the following:
- application threat modeling;
- secure software development lifecycle processes;
- secure coding techniques;
- application penetration testing;
- static and dynamic application security testing; and
- developer security training.
If you're developing software, it's important to ensure it is as secure as possible. If you're consuming software from others, the following practices can assure it has been developed using secure engineering principles.
2. Expand awareness with an SBOM
How easy it is to understand development processes depends upon your ability to understand the components in your software and applications.
This is where SBOMs come into play. An SBOM is a dependency map that enumerates all the supporting software contained within a given application, including dependent libraries; shared objects, for example, dynamic link libraries; middleware; resources; and other artifacts. Each dependency has supporting dependencies that may have dependencies and so on.
SBOMs should contain information about the entire dependency tree -- or at least the subset of it that is known at the time of preparation. If you're a consumer of software, this gives added information about the supporting components in the software acquired and used. It's increasingly common for customers to expect vendors to produce SBOMs, so asking for one from software suppliers is a more accepted request. Even if vendors can't produce one, asking helps add pressure for them to increase transparency.
3. Understand software where, how and who
Knowing what is in each piece of software and the processes used in getting it there are great first steps, but it's also important to understand where it goes and how it's used once it's in your organization. Using the Log4j example, it's one thing for a vendor to be able to tell you it is impacted. It's another thing for you to know where and how that vendor's software is used to be able to take remedial action.
There are several approaches to create an account of where individual software packages are used and for what. One way is to incorporate it into the business impact analysis (BIA) performed as part of business continuity planning.
A BIA is a process for canvassing business teams and finding out which applications and systems they use to ensure they can keep working in the event of a disaster or outage. BIA data collected can be used for other things, such as knowing where in the organization given software is used, by whom and for what purpose.
4. Make data actionable and fuel for improvement
After collecting data from the first three best practices, it's time to put it to use. Make the data actionable by implementing it within a framework and mechanism. For some organizations, this ties directly into risk management processes. Here, ensure data collected about the software supply chain is incorporated into your risk management picture by impact on risk tolerances.
From there, use the risk profile to measure potential impact and tie it to existing mechanisms for how you track and report risk internally. Arguably most importantly, these means also tie in mechanisms for applying countermeasures, mitigations or other risk control activities based on the information coming in about what software is used, how it's created, what it contains and who uses it.
