Why You Need a Software Bill of Materials More Than Ever

Why You Need a Software Bill of Materials More Than Ever


Imagine that a new vulnerability in lodash was just announced. Applications using the npm package are being exploited through large scale automated DoS attacks. You need to act quickly to understand if your organization’s systems are at risk. You need to figure out if any of your 6,000 applications are using the vulnerable versions of lodash before adversaries discover an exploit path through one or more of your applications.
The clock is ticking. Your customer’s data is potentially at risk. Can you do it?
This isn’t just a hypothetical. It’s a very real situation that is happening more and more often – just think back to eventstream vulnerabilities. In some cases, exploits can come down to life or death; look at how commons-collection was manipulated at Hollywood Presbyterian Hospital or how pacemakers were recalled by Abbot Laboratories after they found a remote hacking vulnerability. 
It is vital, anytime a vulnerability in OSS software components are announced, that two questions are answered as soon as possible:
Did we ever use the vulnerable version(s) of the open source component?
If yes, in what applications do they reside?
Answer immediately: advantage goes to you. Prolong your answer: advantage goes to the adversary. Your answer could be found through automation requiring seconds of analysis or it might resemble scavenger hunts takes weeks to months. The best organizations have automated faster than the evil.
Organizations that create a software bill of materials (SBOM, or sometimes called a CBOM for “cybers ..

Support the originator by clicking the read the rest link below.