The conventional wisdom
Compliance frameworks often emphasize that thorough third-party risk assessments will shield you from vendor-related breaches. Complete the questionnaire, review the SOC 2, and verify penetration test results. Check the box.
When Manchester Airports Group (MAG) revealed that 8.8 million email addresses and phone numbers leaked from a third-party database, the immediate reaction was predictable: "They needed better vendor oversight." Security consultants quickly recommended more comprehensive due diligence and stricter contract language.
This response misses the actual attack vector entirely.
The real issue
The breach didn't occur because MAG's vendor had an insecure database. It happened because MAG's developers embedded admin keys directly in the frontend JavaScript of three airport websites. FulcrumSec didn't exploit a vendor's weakness; they accessed MAG's public source code.
Your vendor assessment program can't evaluate your own integration errors. No amount of third-party scrutiny would have caught this because the vulnerability was in MAG's code, not the vendor's infrastructure.
The industry's focus on vendor risk management has created a dangerous blind spot. You're auditing your suppliers' security while your development teams are committing secrets to public repositories, hardcoding API keys in mobile apps, and leaving admin credentials in client-side JavaScript.
The third-party database wasn't the problem; it was the target. The problem was the keys MAG handed over to anyone with a browser's developer console.
The evidence
FulcrumSec accessed the stolen data using credentials visible in the root domain's JavaScript for Manchester, London Stansted, and East Midlands airports. Not hidden in a misconfigured S3 bucket or extracted through a sophisticated supply chain attack, just sitting there in the page source.
This isn't a vendor management failure. It's a secure development lifecycle failure that no vendor questionnaire would uncover. Your supplier's ISO/IEC 27001 certificate and clean penetration test report are irrelevant when you're publishing the keys to their system on your public website.
The breach exposed 2,482,763 bookings, 461,433 SMS messages, and 108,077 vehicle registration plates, along with names, browser details, and residential IP addresses. The scale of exposure reflects years of data accumulation, meaning these keys had been in production JavaScript for an extended period.
No vendor assessment template includes the question: "Will your client expose our admin credentials in their frontend code?"
What to do instead
Start with the integration surface. When you connect to a third-party service, document every credential, API key, and access token your application uses. Then audit where those secrets live in your codebase.
Your secure coding standards should mandate:
- Secrets management tools like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault for all credentials, with automated rotation.
- Pre-commit hooks that scan for exposed keys before code reaches version control.
- Client-side code reviews that specifically check for embedded credentials or configuration data that should live server-side.
- Automated scanning of production JavaScript bundles for common secret patterns.
These controls are implemented with existing tools that integrate into your CI/CD pipeline. The technical barrier is low. The organizational barrier is that secure development practices often get treated as optional while vendor assessments are mandatory compliance exercises.
Reframe your third-party risk program to include "integration risk." When you onboard a vendor, the assessment should cover:
- What credentials will your application need?
- Where will those credentials be stored in your environment?
- How will they be accessed at runtime?
- What monitoring will detect credential misuse?
Your development teams need to understand that a secret in client-side code is a published secret. It doesn't matter if it's obfuscated, minified, or split across multiple files. If it ships to the browser, it's public.
For existing integrations, conduct a secrets audit. Pull your production JavaScript bundles. Search for API keys, database connection strings, and authentication tokens. You'll be surprised what you find. Then fix it before someone else finds it first.
When vendor risk management still matters
This doesn't mean vendor risk management is worthless. When your supplier suffers a breach of their own infrastructure, proper due diligence matters. The vendor assessment catches misconfigurations, missing patches, and inadequate access controls on the supplier's side.
If MAG's third-party database provider had been breached through a SQL injection flaw or an unpatched server, then yes, the vendor assessment should have surfaced those risks. Contract terms that require timely patching, security testing, and incident notification are valuable when the breach originates with the vendor.
Third-party risk assessments also establish accountability. When you've documented the vendor's security commitments and verified their controls, you have a basis for contractual remedies if they fail to meet those standards.
The limitation is scope. Vendor assessments evaluate the supplier's security. They don't evaluate your use of the supplier's services. That's your job, and it requires different controls: secure development practices, secrets management, integration testing, and runtime monitoring of how your applications interact with third-party systems.
The Manchester Airports breach should prompt you to ask: what credentials are we exposing in our own code? That's a question your vendor assessment program will never answer because it's looking in the wrong direction. You can't outsource responsibility for your own development practices, no matter how thoroughly you audit your suppliers.
