Editor’s note: The following is a guest post from Tim Mackey, principal security strategist at Synopsys and co-chair of the Supply Chain Risk Management Task Force.
Over the past 18 months, we’ve seen two fundamental cyber events that will change how cybersecurity activities are performed. The first was President Biden’s Executive Order on Cybersecurity and the second was the Log4j vulnerability in December 2021.
Both events have the potential to significantly reshape how cybersecurity programs operate – not only within government but also within industry.
Importantly, as we move closer to the Office of Management and Budget (OMB) providing language for future contracts, corporate leadership teams should be paying close attention to what’s happening in government.
Even if you indirectly do business with the U.S. government, there is a high probability that you’re going to be expected to comply with some level of federal cybersecurity requirements or guidance.
SBOMs – a key enabler of security and innovation
Here is a simple test to see the impact of the Executive Order and Log4Shell, and how intertwined they are with business operations: How often over the past year have you heard the term SBOM?
If you never knew what it was, and have heard it often this year, then you are far from alone. The topic of a software bill of materials (SBOM) isn’t new in the cybersecurity industry. However, it is featured prominently in the Executive Order so much so that we’re looking at the emergence of a new enabling security technology.
At its core, an SBOM is nothing more than a document produced by a software supplier to document which third-party components they ship with their software. Component-level information serves several critical cybersecurity roles within business.
For example, when an IT or security team is armed with a list of potential libraries in an application, not only can more detailed threat models be created, but incident response teams can also better detail where attackers are attempting to compromise systems.
SBOM information is also equally valuable when addressing patch management priorities. It stands true that you can’t possibly patch something you didn’t know you had. And, with the Log4Shell vulnerability in Log4j disclosed in December, many organizations now know precisely what the impact of a lack of awareness of the software powering their business might be.
Outside of the impact of the Log4Shell vulnerability, the fact that most users of Log4j hadn’t explicitly approved Log4j for use in their business was a surprise. The situation was made worse when it was discovered that many systems were also running a version of Log4j that had reached its end-of-life ten years ago.
The interesting thing about SBOMs is that as an enabling technology, an SBOM is quite adept at identifying latent risks within software supply chains. The challenge is that they’re rather new to the party, and unfortunately there is considerable variability in how well a given SBOM generation tool conforms to both the spirit of the specification and the details of the file format.
The good news is that there is an entire industry that has been providing SBOM-style information for over a decade.
Software composition analysis (SCA) is a cornerstone of open source governance programs and is traditionally used within AppSec programs to determine if the open source usage by development teams meets compliance targets.
Managing your software supply chain with SCA tooling
For most teams, the idea of running SCA tooling against IT assets or as part of a procurement workflow may seem odd due to the expectation that SCA tooling typically works with source code that a vendor wouldn’t provide. However, modern SCA tooling is often much more flexible.
The use of binary SCA tooling allows procurement and InfoSec teams to perform a “trust but verify” security analysis against what suppliers are providing. Such a process enables a streamlined risk assessment that undercovers how well suppliers are managing their software supply chains.
When using these tools, teams should look out for the use of obsolete or end-of-life components and components that have unpatched vulnerabilities, such as an older version of Log4j. Of course, the vendor might indicate that they have mitigations that might limit any exposure to compromise, and such statements are typically part of a Vulnerability Disclosure Report (VDR).
What’s particularly interesting about the use of SCA tooling to scan binaries is that the processes created to work with binary SCA information are precisely the same processes required to work with SBOM information.
The only difference is that the SBOM is provided by the supplier, and there is no requirement to scan deliverables from suppliers.
This means that for many businesses, the easy starting point for SBOM management is to implement a “trust but verify” workflow within their vendor risk management or procurement processes using proven binary SCA techniques.
The CSRB and its educational recommendations
The SBOM management scenario is just one of many possible outcomes from the Executive Order, but one of the more concrete examples of progress can be found with the establishment of the Cyber Safety Review Board (CSRB) within CISA.
The CSRB is an entity like the NTSB, but with a focus on cybersecurity events. Its first report detailed the timeline and lessons learned from the Log4Shell experience.
Key in its recommendations are that businesses were not able to quickly identify their use of a vulnerable open source component, and that educational institutions should require cybersecurity training for all computer science degrees and certifications.
The educational recommendation is particularly interesting when you recognize that software developers don’t only work on commercial software, but they also often participate in open source projects by contributing code.
By providing ongoing security training for developers, not only are businesses able to produce more secure software, but those same developers are able to better identify and remediate security issues in the open source projects they support.
This second order benefit can be substantial when you consider that well over 70% of the code in an average commercial application is open source.
