Written by: Luke Sobieraj, Founder & COO, Digital Colliers
CISA flagged a US contractor this month for pushing private cloud access keys to public GitHub. It's a familiar shape. A build script gets copied, an env file slips past .gitignore, a developer clones a repo to a personal machine and pushes it back to the wrong remote. The leak itself is not the interesting part. The interesting part is what happens in the next four hours at the bank on the other end of that key.
For most mid-market banks, the honest answer is: not much, quickly. Not because the security team is asleep, but because nobody can produce a live inventory of where that credential is used, what it can touch, and who owns rotating it. That's not a security problem in the classic sense. It's a data problem wearing a security hat.
How the leaks actually happen
The public-repo leak is one path. It's not the most common one. The patterns I keep seeing in financial services:
- Long-lived service accounts shared across three or four microservices, with the key pasted into a runbook in Confluence.
- Third-party vendors who need read access to a data warehouse and get a key that never expires.
- CI/CD pipelines that inject secrets at build time, with the secret also sitting in a Terraform state file in an S3 bucket that half the org can read.
- Ex-contractors whose GitHub access was revoked but whose personal laptop still has a working AWS profile.
Every one of these leaves the same footprint: a credential exists, and no single system of record knows all the places it's valid.
Scanning alone doesn't fix this
Secret scanners are table stakes. GitGuardian, TruffleHog, GitHub's native scanning, all of it. They tell you a secret exists in a place it shouldn't. They don't tell you what that secret unlocks, whose ownership it sits under, or what breaks when you rotate it.
That last part is why rotation stalls. An on-call engineer sees an alert, pulls the key, and then has to spend the next six hours figuring out which four services will fall over if they rotate it. So they don't rotate it. They open a ticket. The ticket ages. Verizon and Rapid7 data suggests only about 3 to 5 percent of publicly disclosed vulnerabilities get patched within 30 days, and internal credential hygiene follows a similar curve for the same reason: the fix is cheap, the coordination is expensive.
The minimum data model for rotation in hours
If you want to move from "we'll get to it" to "rotated by end of shift," you need a small, boring dataset that most banks don't actually maintain. At minimum:
- Every credential, keyed by a stable ID, with issuer, scope, and expiry.
- Every system that consumes it, with the config path or secret manager reference where it lives.
- An owner, a human being, not a team inbox.
- A dependency map showing what breaks on rotation and what the fallback is.
- A last-verified timestamp, because stale inventory is worse than no inventory.
This is not a security tool. It's a data pipeline. It reads from your secret manager, your IaC repos, your cloud IAM, your CI system, and your CMDB, and it reconciles them nightly. When a leak alert fires, you query the inventory, you get a rotation plan in under a minute, and you execute.
The teams doing this well treat the inventory the way a good AML team treats its transaction data. And note: AML teams already live with 85 to 95 percent false positive rates on their monitoring, which is what happens when your data model is bolted on after the fact rather than designed in. You do not want your credential response to inherit that same debt.
What inaction actually costs
DORA has been in force since January 2025, and its ICT risk requirements assume you can identify, classify, and respond to incidents on defined timelines. "We're still mapping our service accounts" is not a defense. GDPR exposure sits on top of that, with fines up to €20M or 4 percent of global turnover if a leaked credential led to a personal data breach you couldn't contain quickly.
The cost of inaction isn't the fine itself. It's the two-week incident, the regulator asking for evidence you can't produce, the auditor question that turns into a finding, the finding that turns into a remediation plan that pulls three engineers off roadmap for a quarter. The credential inventory is the small, unglamorous data asset that prevents all of that. Most banks do not have it. The ones who ship it in 2026 will be the ones who stopped treating it as a security project and started treating it as a data one.