Page 62 - Security Today, September/October 2024

Trust But Verify
It is time to start holding your software and hardware vendors accountable
By Tom Pace
Today’s world is built on soft- ware—whether it is third- party applications, open- source libraries, in-house developed tools, operating systems, containers or firmware. Organi- zations worldwide depend on these diverse software components to power their oper- ations, connect with customers, and drive innovation. However, this reliance on soft- ware comes with hidden dangers: the blind trust placed in these software products. Many companies assume that the software they purchase, and use is secure and free from vulnerabilities, but recent high-pro- file software supply chain breaches have proven otherwise. The reality is that every piece of software, no matter how reputa- ble the source, increases the organization’s attack surface and poses new risks.
This is where the principle of “trust but verify” becomes essential. Blind trust in software can lead to devastating con- sequences, ranging from data breaches to operational disruptions. Comprehensive visibility into all software components and dependencies is not just a precaution—it is a necessity. And it is high time that orga- nizations start holding their software and hardware vendors accountable for the se- curity of the products they deliver.
THE RISKS OF BLIND TRUST IN SOFTWARE
Allan Friedman, widely recognized as the father of the SBOM (Software Bill of Materials), humorously compared an SBOM to the ingredient list on a package of food. He quipped, “Think of what’s in those non-biodegradable Twinkies. Did you know that a key ingredient is cow fat? That’s something people with sensitive di- ets should know, just like we should know what’s in our software.”1
Taking this analogy a step further— would you eat food without transparency into the ingredients, without knowing the expiration date, without understanding the nutritional information, or without be- ing aware of any recalls due to contamina- tion? Of course not. Yet, when it comes to
software, many organizations are content to consume these digital products without similar scrutiny. Why don’t we apply the same logic to our software and the ven- dors that produce it?
Software supply chain security is no longer a nice to have – it is one of the most foundational programs in cybersecurity we can untake. Failure to do so unneces- sarily exposes companies to notable soft- ware supply chain attacks— like Codecov and Log4j:
Codecov. Attackers gained access to Codecov’s Bash Uploader script, modify- ing it to export sensitive information such as credentials and tokens from the users’ environments. This breach affected thou- sands of companies that relied on Code- cov for code coverage analysis, exposing them to serious risks.
Log4j. We all know the story. The vul- nerability discovered in Log4j, a widely used Java library, became one of the most signifi- cant security threats in recent memory. The flaw allowed attackers to execute arbitrary code on affected systems, putting countless organizations at risk. The widespread use of
weedezign/stock.adobe.com
Log4j meant that even organizations with strong cybersecurity measures in place were vulnerable.
These examples highlight the critical need for transparency and accountabil- ity in the software supply chain. It’s not enough to trust that software is secure; organizations must verify the security of the software they use and hold vendors ac- countable for any vulnerabilities.
Why Now?
The urgency to implement software supply chain detection and response capa- bilities has never been greater.
The 2024 Verizon Data Breach Inves- tigations Report (DBIR) revealed that breaches stemming from third-party soft- ware development organizations played a role in 15% of the more than 10,000 data breaches documented— that is 1,500 sup- ply chain breaches in one year, a staggering 68% increase from the previous year.2
Verizon’s report emphasized that orga- nizations should “start looking at ways of making better choices” about which third- party software providers they work with, “so as to not reward the weakest links in
62
SEPTEMBER/OCTOBER 2024 | SECURITY TODAY
SOFTWARE SECURITY