SAP just closed a decade-old hardcoded SQL password. A 10 out of 10 severity. Ten years. Hardcoded credentials. In SAP.
If SAP had this sitting in their code for ten years, what do you think is hiding in everything else you run?
After 20 years as a CISO, CIO, and CTO, this keeps me up at night more than any other threat. And almost nobody is preparing for it.
What this means for the CIO, CTO, and CISO
Software supply chain is one of the largest cybersecurity risks going into 2026, right up there with identity. If you're not treating it that way, you're exposed.
Your SOC 2 certifications provide zero software supply chain protection. SOC 2 certifies infrastructure processes, not code security. Stop conflating them.
This is a buying process problem, not just a development problem. Every software purchase, including SaaS, carries transitive supply chain risk. Your procurement process needs to reflect that.
The inside perspective
When I was responsible for security, I knew exactly how many applications we ran. I had a complete inventory. I could tell you the vendor, the version, the support status, and the business owner for every piece of software in our environment.
What I couldn't tell you, what nobody could tell you, was how many pieces of software were actually inside those applications.
That enterprise application with 50 users? Built on 400 open-source libraries. Each library maintained by someone I'd never heard of, with funding I couldn't verify, and security practices I couldn't assess. Each library with its own dependencies. Dependencies all the way down.
I signed off on security assessments that evaluated the vendor. We never evaluated the vendor's vendors. We never evaluated the code they didn't write but shipped anyway. We never assessed the risk hiding inside the applications we thought we understood.
Every CISO I know has this same blind spot. We secure the perimeter. We monitor the endpoints. We control the identities. And we completely ignore the hundreds of components embedded in every application we run.
I knew exactly how many applications we ran. What I couldn't tell you, what nobody could tell you, was how many pieces of software were actually inside those applications.
The outside observation
Now I watch from the analyst seat as the industry obsesses over endpoint security, network segmentation, and identity management, while almost completely ignoring software supply chain.
The security vendor landscape is crowded with EDR solutions, SIEM platforms, and identity governance tools. The supply chain security space? A handful of players and minimal enterprise adoption.
The disconnect is staggering. We're locking the front door, installing cameras, and hiring guards, while the back wall of the building is missing entirely.
The attackers have noticed. Supply chain attacks are growing because they work. Compromise one library, reach thousands of organizations. Compromise one vendor, reach their entire customer base. The ROI for attackers is extraordinary.
And enterprises keep investing in perimeter defense while leaving the supply chain unguarded.
We're locking the front door, installing cameras, and hiring guards, while the back wall of the building is missing entirely. The attackers have noticed.
The uncomfortable truth
No one produces 100% homogenous software that matters.
Let me explain what I mean. Yes, there are small utilities written entirely by one developer with no external dependencies. Those aren't the applications running your business.
The applications that matter, the ones processing your transactions, managing your customers, running your operations, are built from hundreds of components. Libraries for encryption, frameworks for web serving, modules for database access, utilities for logging, packages for everything.
We can't homogenize every application down to the kernel. It's ridiculous to think we could. Modern software development depends on shared components. That's not going to change.
But here's the problem: every component you include is a component you trust. Every dependency is a dependency on someone else's security practices. Every library is an attack surface you didn't create but now own.
The software supply chain isn't just your code. It's everyone's code that's in your code.
Why attackers love supply chain
Attackers are just companies whose business is making money from attacks. They have P&Ls. They calculate ROI. They invest where returns are highest.
Supply chain attacks have extraordinary ROI.
Direct attacks on enterprises require effort for each target. High investment, limited reach.
Phishing and social engineering scale better but still require per-target effort. Medium investment, medium reach.
Supply chain attacks are force multipliers. Compromise one library used by thousands of applications. Compromise one vendor used by thousands of organizations. Medium investment, massive reach.
The math is simple. If you're an attacker optimizing for ROI, supply chain is where you focus.
That's exactly what we're seeing. SolarWinds. Log4j. Codecov. 3CX. The list grows every quarter. These aren't anomalies. They're the new normal.
The transitive risk problem
Here's what most organizations don't understand: supply chain risk is transitive.
When you adopt software, you don't just accept the vendor's risk. You accept the risk of everyone in their supply chain. Their dependencies. Their dependencies' dependencies. All the way down.
If one of your vendor's dependencies has a vulnerability, that's your vulnerability. If one of their dependencies' maintainers gets compromised, that's your compromise. If someone three levels deep in the chain makes a mistake, you inherit the consequences.
You didn't choose these dependencies. You may not know they exist. But you own the risk.
This is what makes supply chain security so difficult. You can evaluate your direct vendors rigorously. You probably do. But do you evaluate their dependencies? Their dependencies' dependencies? The solo maintainer who wrote a logging library ten years ago and hasn't updated it since?
Of course not. No one does. That's why this risk is so pervasive.
The SOC 2 delusion
I need to address a dangerous misconception: SOC 2 certification is not software supply chain risk reduction.
Zero percent overlap. None.
SOC 2 certifies infrastructure processes. Data center security. Access controls. Operational procedures. It tells you the vendor can run code securely in a secure environment.
It tells you absolutely nothing about whether the code itself is secure.
A vendor can have perfect SOC 2 compliance and ship software riddled with vulnerable dependencies. Their data center is locked down. Their operational processes are audited. And the code they're running contains a hardcoded password that's been there for ten years.
Every time I see an enterprise use SOC 2 as evidence of supply chain security, I cringe. It's not. It never was. Stop pretending it is.
The SaaS exception that isn't
"But we use SaaS. We don't run the code. Supply chain isn't our problem."
Wrong.
SaaS means you don't manage the infrastructure. You don't patch the servers. You don't maintain the code.
But your data still runs through that code. A supply chain compromise of your SaaS vendor is a compromise of your data. A vulnerable dependency in their application can be exploited to access your information.
SaaS transfers the management burden. It doesn't transfer the risk. You retain the consequence of supply chain failures even when you don't touch the code.
This is why software supply chain security applies to your procurement process for purchased and SaaS software, not just your development process for code you write. Every software decision carries supply chain risk, whether you run it or not.
The evidence it's real
This isn't theoretical. The evidence is mounting.
- SAP. Decade-old hardcoded SQL password. 10/10 severity. In one of the most widely deployed enterprise applications on earth.
- SolarWinds (2020). Build system compromised, malicious code distributed to 18,000 customers including government agencies.
- Log4j (2021). Vulnerability in a ubiquitous logging library affecting hundreds of millions of systems worldwide.
- Codecov (2021). CI/CD tool compromised, credentials stolen from thousands of development environments.
- 3CX (2023). Desktop application compromised via supply chain attack, distributed to 600,000 customers.
These aren't anomalies. They're the observable pattern of where attacker investment is going. Each successful attack demonstrates the ROI, which attracts more attackers, which creates more attacks.
The tech debt we're dragging is enormous. If SAP, with its massive security team and resources, had a decade-old hardcoded password, what's hiding in smaller vendors with fewer resources? In open-source libraries maintained by volunteers? In legacy applications no one has audited in years?
We have to assume the answer is: a lot.
Signs you're unprepared
Use this diagnostic to assess your supply chain security posture. If four or more apply, you have a critical gap.
- You evaluate vendors but not their dependencies. Your due diligence covers maybe 10% of the actual software that enters your environment.
- Your RFP process doesn't include supply chain security questions. You're buying risk without pricing it.
- You conflate SOC 2 with software security. They're completely different things. This confusion is dangerous.
- Your SBOM (Software Bill of Materials) coverage is incomplete or nonexistent. You can't secure what you can't see.
- You treat SaaS as eliminating supply chain risk. It doesn't. Your data is still processed by code you don't control.
- Your security team focuses on perimeter defense, not component analysis. You're guarding the wrong boundary.
- You can't answer "How quickly could we respond to another Log4j?" If you don't know, the answer is "not quickly enough."
- Your board has never discussed supply chain risk. If leadership isn't aware, it's not prioritized.
What I'd tell my former self
If I had known then what I know now:
I would have added supply chain questions to every RFP from day one. "How do you manage your dependencies?" should be as standard as "Where is your data center?"
I would have stopped accepting SOC 2 as evidence of software security. It's evidence of operational security. Different thing entirely.
I would have demanded SBOMs from critical vendors. If they can't tell you what's in their software, they don't know either.
I would have run tabletop exercises for supply chain incidents. "What do we do if a critical library is compromised?" should be a planned scenario, not a surprise.
I would have treated procurement as a security function. Every software purchase is a security decision. Procurement needs to understand that.
The procurement imperative
This is not just a security team problem. This is a buying process problem.
Every software purchase carries supply chain risk. Every SaaS subscription. Every enterprise application. Every library your developers import.
If your procurement process doesn't evaluate supply chain risk, you're accumulating risk with every purchase. You're making security decisions without security input. You're accepting transitive liability without knowing what you're accepting.
How vendors manage their software supply chain is as important as, or more important than, how you manage yours.
You can have perfect internal practices. You can run the best development security program in your industry. None of it matters if you're deploying vendor software full of vulnerabilities you never evaluated.
Procurement needs to understand this. Contracts need to reflect this. Vendor relationships need to include ongoing supply chain assessment, not just initial evaluation.
The questions to ask
Every RFP, every vendor evaluation, every software purchase should include these questions.
Visibility:
- Can you provide a complete SBOM for your product?
- How do you track dependencies and their dependencies?
- What's your process for identifying vulnerable components?
Process:
- How do you evaluate the security of libraries you include?
- What's your policy for updating dependencies with known vulnerabilities?
- How quickly do you respond to critical dependency vulnerabilities?
Governance:
- Do you have a security team responsible for supply chain?
- What training do your developers receive on secure dependency management?
- How do you evaluate the trustworthiness of open-source maintainers?
Verification:
- Can you provide evidence of recent dependency audits?
- Will you agree to supply chain security requirements in our contract?
- How do you notify customers of supply chain incidents?
If vendors can't answer these questions well, that tells you something important. Either they don't know what's in their software, or they don't want to tell you. Neither is acceptable.
The 2026 prediction
Software supply chain will emerge as a top-tier cybersecurity crisis in 2026.
Major breaches will trace back to supply chain compromises. The incidents will be high-profile and damaging. Organizations that ignored supply chain security will face material consequences.
The enterprises that prepared, that made supply chain non-negotiable in procurement, that built SBOM capabilities, that asked the hard questions of vendors, will be positioned to respond. The enterprises that didn't will scramble.
This isn't fear-mongering. It's pattern recognition. The attack surface is growing. The attacker ROI is established. The enterprise preparation is minimal.
The math says 2026 will be the year supply chain stops being a theoretical risk and becomes a realized crisis for major organizations.
The playbook for supply chain security
Five steps to implement supply chain security before the crisis hits.
- Make supply chain non-negotiable in RFPs. Standard questions for every vendor. Standard requirements in every contract. No exceptions because a vendor is "strategic" or "trusted." The strategic vendors are exactly where supply chain risk is highest.
- Build SBOM capability for critical systems. Know what's in your software. Start with the highest-risk applications, the ones processing sensitive data, running critical operations, touching customer information. Expand from there.
- Separate SOC 2 from software security evaluation. Different assessments for different risks. SOC 2 for operational security. Separate evaluation for software supply chain. Stop letting vendors use one as evidence of the other.
- Create a supply chain incident response plan. What do you do when the next Log4j drops? Who's responsible? How do you identify affected systems? How do you prioritize remediation? Plan this before it happens.
- Include ongoing supply chain monitoring in vendor relationships. Initial assessment isn't enough. Vendors add dependencies over time. New vulnerabilities emerge. Continuous monitoring is required, either you do it or you require vendors to report.
KPIs to measure supply chain security
- SBOM coverage. Target: 100% of critical applications. Measures visibility into what's actually running.
- RFP supply chain question compliance. Target: 100% of software purchases. Measures procurement integration.
- Vulnerability response time. Target: under 48 hours for critical dependency vulnerabilities. Measures response capability.
- Vendor supply chain assessment rate. Target: 100% of critical vendors assessed. Measures third-party evaluation.
- Board reporting frequency. Target: quarterly supply chain risk updates. Measures leadership visibility.
If you're not measuring supply chain security, you're not managing it.
Internal conversations
What to tell your CFO when they question supply chain investment:
Supply chain incidents have quantifiable costs. SolarWinds remediation cost affected organizations billions in aggregate. One major incident could cost us a comparable figure based on our exposure. Our current exposure is unmeasured risk. We don't know what's in most of our software. We can't assess risk we can't see. Investment in supply chain security has clear ROI. The cost of preparation is a fraction of the cost of incident response.
What to tell your board when they haven't discussed supply chain:
Supply chain is now a top-tier cyber risk, alongside identity and ransomware. It deserves board-level attention. We currently lack visibility into what's actually in our software. That's a gap we need to close. I recommend elevating supply chain security to a regular board reporting topic, with quarterly updates on our posture.
What to tell your procurement team when they push back on new requirements:
Every software purchase is a security decision. We need to evaluate security as part of vendor selection, not after. SOC 2 certification doesn't mean software is secure. We need separate evaluation of supply chain practices. These requirements aren't optional. They start immediately for all new vendor evaluations.
What to tell your vendors when they resist supply chain questions:
We require SBOMs for continued partnership. If you can't tell us what's in your software, that's a red flag. Supply chain security questions are now standard in our evaluation process. Every vendor answers them. Your security practices are our security risk. We need to evaluate them accordingly.
To security leaders
Make software supply chain non-negotiable in every RFP.
You've spent years building perimeter defense, identity management, and endpoint security. That investment is necessary but not sufficient. Supply chain is the gap attackers are exploiting.
Add supply chain to your risk framework. Add it to your vendor evaluation process. Add it to your board reporting. Treat it like the tier-one risk it is.
To procurement
This is a buying process problem, not just a security problem.
You're on the front line of supply chain risk. Every vendor you evaluate, every contract you sign, every subscription you approve, each one carries transitive risk that propagates to the entire organization.
Partner with security. Include supply chain questions in every evaluation. Make security assessment part of vendor selection, not an afterthought.
To vendors
Your supply chain management is now a competitive differentiator.
Enterprises are waking up to supply chain risk. The ones who understand it will start asking questions you may not be prepared to answer.
Get prepared. Build SBOM capability. Document your dependency management practices. Be ready to answer supply chain questions in every sales process.
The sharp version: if your platform has supply chain practices you can't explain or defend, you will be excluded from enterprise RFPs by 2026. The window to prepare is closing.
A note on analyst culture
Most analyst coverage of cybersecurity focuses on the vendor landscape for endpoint, identity, and network security.
Supply chain security gets minimal attention. It's not a large market yet. There aren't many vendors to cover. The analyst incentive is to cover the markets that generate the most vendor briefings and inquiry.
But analyst coverage should follow risk, not market size. Supply chain is one of the largest risks enterprises face going into 2026. The fact that the vendor landscape is immature doesn't make the risk smaller. It makes the gap more dangerous.
Coverage should be prioritized based on enterprise risk, not vendor activity. Supply chain security matters. It's worth saying until the industry catches up.
The bottom line
SAP had a decade-old hardcoded SQL password. 10/10 severity. If SAP had this in their code for ten years, what's hiding in everything else you run?