A software bill of materials (SBOM) is an important tool enterprise defenders can use to track the impact of software security bugs, manage sane patch management, and protect the integrity of the software supply chain as a whole. Scores of industry leaders say so. The Office of the President of the United States says so.
So why are they not widely used yet? What are software vendors worried about? Do they know something that we don’t?
In a recent CISO Forum in Whitehall, London, many CISOs felt that the challenges and speed of change in application security, particularly in a cloud-enabled environment, had left them a little nonplussed and challenged to change their architectural models and thinking to become fully cloud native. In particular, there was a reluctance to let go of legacy control methods such as IP-based access lists and endpoint-based security controls.
Hesitant to Set Off the SBOM
There are several interesting possibilities that may be driving the tendency to delay providing SBOMs.
The first is ignorance of their own supply chain. It’s possible that the vendors don’t actually know the origin of some of their software. It is common practice in large development teams and long, complex projects to effectively “black box” entire sections of code.
If that is the case, the fact that the organization may not fully know the origins of its software raises a myriad of concerns. It could indicate anything from bad version tracking to the existence of potentially indispensable employees that hold the fate of the entire company in their coding hands. It’s completely understandable that such a company would hesitate to release SBOMs for its products.
Another scenario that might make a company leery of SBOMs is if the product is almost entirely an assembly of other products. It’s the reality of modern software development that programs are the result of custom code cobbled together with third-party libraries and components. If the company has written a very low percentage of its own code, then the SBOM could essentially become a recipe card for someone else to clone the product.
But the likely scenario is that software firms may see no upside, only potential downside to releasing SBOMs. Currently there’s very little market pressure on releasing SBOMs for their product lines. They may have created one for internal use, but there is no real push to make them public. The main concern voiced by CISOs is that while an SBOM may improve visibility, it provides little impetus towards remediation and no liability for fixing software flaws — leaving the problem squarely in the lap of the end user, the CISO.
Getting Past the SBOM
It’s unlikely that the industry or the purchasing public will be able to generate the market pressure required to force every major player to release an SBOM for all their products. In May 2021, the US government issued an executive order to improve the nation’s cybersecurity that explicitly called for SBOMs as a control measure for the software supply chain. The EU government, for its part, has planned a Cyber Resilience proposal to echo and support the requirements of the US order.
If the main purpose of an SBOM is patch management and vulnerability attribution, there is a secondary layer of monitoring and protection that cybersecurity personnel should be looking at: attack surface management (ASM).
While it would be slightly easier for enterprise security teams to know that the software they use contain packages X, Y, and Z, that isn’t the only way to manage application security. By tracking the security advisory history of these software suites, we can estimate the most likely attack vectors that they can fall victim to.
The combination of these vulnerabilities compiled from every piece of software that a company uses makes up an organization’s attack surface. What ASM tries to do is intelligently categorize these weaknesses and automate the discovery, remediation, and continuous monitoring of new threats.
It’s like tying together a vulnerability advisory service with an enterprise software management solution. The way that the ASM does this varies from product to product, but generally some amount of machine learning is involved. That way predictive models can be built so that when certain zero-day exploits are discovered, you will know how likely they are to apply to your attack surface even if you don’t have a detailed SBOM from every vendor.
A good ASM has the additional benefit of treating ducks like ducks. You know: If it looks like a duck and quacks like a duck, it doesn’t really matter if someone else labeled it as a swan instead. The ASM only cares about results. If a company insists that it’s using the Open Dynamics Engine, but for some mysterious reason it falls victim to all the same vulnerabilities as the PhysX engine, ASM will completely ignore labels and suggest the fixes that actually fit the situation and not the ones that correspond to the names.
Even if the movement toward mainstream adoption of SBOM continues to be slow, security professionals have a strong alternative with ASM. It’s also worth noting that ASM will complement any SBOM-based software governance with a dynamic risk mitigation system.
Instead of adopting and deploying something locally to cover your vulnerability discovery and monitoring needs, another alternative is to embrace an agentless security model that can monitor extended asset attack surfaces. The device intelligence firm Armis, for example, does this with a fully cloud-native approach. Think of it as an ASM solution that covers IoT devices, cloud instances, and edge networking setups, as well as traditional on-premises.
Such a model presents a different, more global way of looking at asset intelligence that might be more attractive to large enterprise operations. Smaller operations, however, would likely want to save their money for a good ASM and rely on extra vigilance for their extended network devices.
Source: www.darkreading.com