For many years, supply chain security was viewed purely as a technical concern. However, with high-profile vulnerabilities and regulations, it is now a board-level issue that requires organizations to rethink how to build resiliency and insulate their operations.
The changing regulatory landscape has been a key driver of the C-suite’s focus, as legislation such as the European Cyber Resilience Act (CRA) includes fines of up to 2.5% of global turnover for non-compliance. Additionally, the proliferation of open-source software, coupled with complex global supply chains, has created a perfect storm transforming how CSOs must approach supply chain security.
The pervasiveness of open-source software has upended the security landscape. According to Synopsys’ 2025 Open Source Security and Risk Analysis report, 97% of commercial applications contain open-source software, with 86% containing vulnerabilities, 81% of which are categorized as high- or critical-risk. Five years ago, statistics like this were foreign to corporate boards but now they’re the data behind imperatives.
The Log4Shell vulnerability in 2021 highlighted the problem. A critical flaw in the open-source Apache Log4j 2 Java library enabled attackers to execute code remotely, affecting millions of applications, cloud services and physical endpoints, including servers. Hackers exploited the vulnerability to steal data, install ransomware and capture devices for botnets with breathtaking speed. This dispelled the assumption that open source was secure, as the situation highlighted the interconnected nature of software ecosystems and the speed at which exploitation of a single vulnerability can spread. If, like me, you were responsible for any products when Log4Shell happened, you can feel my pain. It felt a lot like Y2K but without the advance warning. And who else suddenly wondered if they needed to shut off their corporate website?
Why supply chain security became a C-suite priority
Legislative changes have elevated security from a technical issue to a business issue. The CRA views software security as a product safety concern, and penalties reflect this reality. Federal legislation, including EO14028, requires agencies to maintain complete software and hardware inventories and develop assurance policies. Similar regulations are underway or have been finalized in countries including India and South Korea. One example of industry regulatory focus is the FDA requiring medical devices to have software bills of materials (SBOMs), recognizing that software security directly impacts patient safety. Before the FDA SBOM requirement, a vulnerability was discovered in an FDA-approved cardiac monitor. This device would never have made it to market without remediation if an SBOM had been provided and cross-referenced with vulnerability databases.
The challenge for CSOs is that managing supply chain security is fundamentally different from traditional security. If a supplier’s code causes a breach, indemnity clauses may mean they pay the fine, but you remain responsible for customer notification, reputational damage and the operational burden of response. You must manage these risks across all of your customers, who are now asking detailed questions about your supply chain security posture before they sign contracts.
The hidden complexity that drowns security teams
SBOMs are no longer used solely to track software licensing; they are key to managing supply chain security as they enable the identification and tracking of vulnerabilities across ecosystems.
Finding a problem is just the start — you need to determine if the vulnerability affects your implementation. For example, if an SSL library contains 100 functions and your application uses 60 of them, and the flaw is in one of the unused 40, there is no risk. However, traditional scanning tools may flag it as critical, and your team will waste time investigating a non-issue. To put this in perspective, Cornell found that code vulnerability tools have a 97.5% false-positive rate. Anyone who has spent any time in cybersecurity knows that false positives are the bane of our existence, whether you’re looking at firewall alerts or EDR or library vulnerability correlation. It’s important to note that even if there is no risk, you still need to publish that information so that your customers are aware that you have validated that you are not vulnerable.
This uses significant resources, with developers spending 3.5 hours per week manually reviewing security scan findings due to false positives. This delays new features and slows market entry. Security teams lose credibility, developers become desensitized and dismiss alerts as noise and real threats can get lost. Alert fatigue is a real thing.
Due to the complexity and different development environments involved, there is no panacea for strengthening your supply chain security posture. Source code analysis works well when you have access to code and build processes, but it can’t review third-party binaries or legacy firmware and often can’t identify which code branches will be compiled into the final binary. Build-time analysis identifies issues during compilation, but it doesn’t work on components added later and often stumbles with dynamically linked libraries. Binary and firmware analysis addresses these gaps but requires sophisticated tooling to reverse-engineer compiled code.
The right solution depends on your specific environment and must account for the types of products you build, how the development pipeline operates and whether you work more with source code or third-party components. There is never a one-size-fits-all solution; companies must evaluate various tools to find the right fit for their situation. Workflow integration, supply chain complexity and deployment platforms such as rich OS vs. bare metal all impact tool applicability.
What CSOs should demand from their tools and processes
Conducting a bake-off with at least three solutions is vital to finding the right option. It’s essential to test against your code to validate accuracy, rather than relying on samples from the vendor. The goal is to understand how each potential option performs in your environment. One aspect to consider is where the software or firmware will run — is it on Windows, Linux, Android or another rich OS? Or is it bare metal as is often seen in space-constrained or industrial environments? There aren’t many firmware analysis tools available for the latter, so those environments may lean toward source- or build-based tools even though binary analysis solutions are often better for rich OS firmware.
As you review, focus on the accuracy of identifying vulnerabilities and the false-positive rate. A tool may catch every vulnerability, but if it flags too many phantom issues, your team will waste countless hours on wild goose chases. Conversely, if it fails to identify critical vulnerabilities, your organization remains exposed.
Additionally, the product must integrate with existing ticketing systems, such as Jira. Automation is non-negotiable, as manual dashboard checks are not viable given the complexity and risk involved. Tasks should be prioritized so developers don’t have to hunt for information. When a vulnerability is found, it should automatically create tickets in your developers’ existing workflow outlining what’s at risk, where it’s used, whether it’s exploitable in your implementation and the required action. The goal is to make responding to supply chain vulnerabilities as seamless as fixing any other bug. If developers need to switch between different tools or manually correlate information, response times will slow, increasing risk.
Supply chain communication capabilities are another vital component to mitigate risk and meet regulatory requirements. The solution must be able to receive automated updates from upstream suppliers and rapidly notify downstream customers. In addition to alerting, the communication should include the required mitigation steps. You need to quickly confirm that a library has been patched or that the vulnerability has been determined to be unreachable or not exploitable.
Documentation is another important evaluation criterion. Contractual and regulatory obligations necessitate real-time information sharing. If a zero-day attack happens, documented best practices protect you from fines. Customers should be informed immediately, not days or weeks later, with the required mitigation steps they need to take. Having survived the ordeal of shipping a product with an encryption library that was discovered to be vulnerable, I can promise you that customer inquiries will come in faster than you can answer them and they will become more strident by the minute. Your supply chain security infrastructure must be able to identify which customers are impacted and what they need to do to protect themselves.
A thorough audit trail showing the steps taken to address flaws can help you avoid punitive fines. The CRA is more forgiving when you can prove you kept software current, followed deployment guidelines, evaluated tools, chose approaches appropriate to your environment and responded promptly. The goal is to demonstrate responsible software security stewardship, as even the most stringent regulatory bodies know that there will always be software bugs.
The path forward
Supply chain security will only intensify. The FDA couldn’t define what an SBOM was 18 months ago; now it’s mandatory for medical device approval. Similar regulations are emerging across industries and jurisdictions as software supply chains become recognized as critical to product security and safety.
CSOs must treat this as a strategic priority that impacts the bottom line, rather than a security checkbox. Executives who recognize the risks and act accordingly will position their organizations not just for compliance but for competitive advantage in an increasingly security-conscious market. Those who delay will find themselves managing crises, facing regulatory penalties and losing customer trust. The question is no longer whether to prioritize supply chain security, but how quickly you can build the capabilities to do it well.
No Responses