The Persistent Failure of Third-Party Security in ’25: An Engineering Perspective

The ongoing saga of third-party data breaches should be a solved problem. The fact that we’re still seeing significant incidents where a compromise of a vendor’s infrastructure leads to the exfiltration of our data is a failure of fundamental security engineering and risk management principles. We’re not talking about novel attack vectors here; we’re talking about basic hygiene in an interconnected ecosystem.

The attack surface isn’t just our perimeter anymore. It’s the entire web of dependencies we’ve built. Every third-party integration, every SaaS provider, every outsourced service represents a potential pivot point for malicious actors. To treat these relationships as somehow separate from our core security posture is a critical architectural flaw.

The Hertz breach via Cleo is a prime, and frankly, infuriating example. You can bet Hertz had their own security stack, their own SOC, their own compliance frameworks. But a vulnerability in Cleo’s environment became the conduit for attackers to access Hertz’s customer data. This isn’t some theoretical risk; it’s a real-world demonstration of how a weak link in the supply chain can bring down the entire operation.

From an engineering standpoint, the excuses for these breaches are wearing thin. We have the tools, the frameworks, and frankly, the hard-learned lessons to do better. Here’s the breakdown of where the failures consistently lie:

• Insufficient Vendor Vetting: The initial due diligence often stops at a checklist. We need deeper, more technical assessments of a vendor’s security controls. Penetration testing reports, security architecture reviews, and demonstrable adherence to recognized security standards (like SOC 2 Type II, ISO 27001) need to be the baseline, not a nice-to-have.
• Lack of Continuous Security Validation: Security isn’t a static state. A vendor might pass an initial audit, but their security posture can degrade over time due to misconfigurations, unpatched vulnerabilities, or internal process failures. Continuous monitoring – leveraging security ratings services, regular vulnerability scans, and even automated security assessments where possible – is non-negotiable.
• Weak Contractual Security Requirements and Enforcement: Security clauses in vendor contracts need teeth. They should clearly define security responsibilities, incident response procedures, audit rights, the right to pen test and the consequences of security failures. More importantly, these clauses need to be actively enforced through regular audits and performance monitoring.
• Immature Security Architecture Integration: We can’t just bolt on third-party integrations without considering the security implications. Secure architecture requires thinking about data flows, access controls, and the principle of least privilege across all interconnected systems. Segmenting third-party access and minimizing their footprint within our environment is crucial.
• Poor Incident Response Planning for Third-Party Breaches: Our incident response plans need to explicitly address scenarios where a third-party compromise impacts our data. This includes clear communication channels, defined roles and responsibilities, and pre-agreed-upon remediation steps.

Relying on hope that our vendors are secure isn’t a security strategy – it’s negligence. We need to adopt a zero-trust mentality when it comes to third parties. Verify everything, continuously monitor, and architect our systems with the assumption that any external entity could be compromised. The Hertz-Cleo incident should be a wake-up call for every security team out there. We have the technical capabilities; what’s lacking is often the organizational will and the rigorous implementation of fundamental security engineering practices. It’s time we treated third-party security with the same level of scrutiny and investment as our own internal infrastructure – because, in reality, it is our infrastructure.