Written by: Karol Sobieraj, Founder & CEO, Digital Colliers
CISA's advisory this month landed with a thud, but the shape of it isn't new. A federal contractor's private GitHub repo leaked cloud access keys. The industry response was predictable: turn on secret scanning, rotate the exposed keys, move on. That misses the real problem. Most mid-market banks I talk to can't answer a simpler question. Where do our credentials live, who owns them, and how fast can we kill one.
That's not a scanning problem. That's an inventory problem. And in financial services, the cost of not solving it now is going up fast.
How the leaks actually happen
The GitHub story is one channel. The pattern underneath is boring and universal. A developer needs to test something against a staging bucket. They paste a key into a config file. The config file ends up in a repo, or a Slack thread, or a Jira ticket, or a laptop that gets reimaged six months later. The key is valid for a year. Nobody remembers it exists.
Multiply that across every engineer, every contractor, every CI job, every third-party SaaS integration your bank has stood up since 2019. You don't have a credential problem. You have a credential archaeology problem.
A few of the channels operators keep finding leaks in:
- Public and private Git repos, including forks and old branches
- CI/CD variable stores that outlived the pipeline
- Postman collections and internal wikis
- Vendor onboarding docs shared over email
- Serverless environment variables from projects nobody owns anymore
- Container images with baked-in tokens
Scanning helps with the first two. It does almost nothing for the rest.
Why scanning alone fails
Secret scanners are pattern matchers. They find things that look like keys inside places you told them to look. They can't tell you if the key is still active. They can't tell you who owns it. They can't tell you which production system will break when you rotate it. And they definitely can't tell you whether the key found in a public repo is the same key sitting inside your production Lambda.
That last part is where remediation stalls. A scanner tells you a key leaked. Nobody knows what depends on it. The security team files a ticket. The ticket sits for weeks while engineering figures out the blast radius. Meanwhile the clock on your regulatory exposure is running.
This is the same dynamic Verizon has documented on the CVE side. Only about 3 to 5% of publicly disclosed vulnerabilities get patched within 30 days. The gating factor isn't detection. It's the org's ability to act on what it already knows.
The cost of not fixing this in 2026
DORA has been in force since 17 January 2025. It's not a future problem. It requires financial entities in the EU to identify, classify and document all ICT assets, including the third-party ones. A credential is an ICT asset. If you can't produce the inventory on demand, you're already out of compliance, whether or not you've been asked yet.
GDPR sits on top of that. Fines reach up to €20M or 4% of global turnover. A leaked cloud key that gives an attacker read access to a customer data store isn't a security incident anymore. It's a notifiable breach, and the regulator's first question is going to be how long the key was live and why nobody rotated it. "We didn't know we had it" is not an answer that reduces the fine.
The cost of inaction here isn't hypothetical. It's the delta between rotating in hours and rotating in weeks, priced in regulatory exposure and customer trust.
The minimum data model to rotate in hours
You don't need a platform. You need a table. The banks that are getting this right are building something close to this, and querying it from a single place:
- Credential ID and type (API key, OAuth token, service account, cert)
- Issuing system and issue date
- Expiry, if any
- Owning team and named human backup
- Systems that consume it, with confidence level
- Last-used timestamp, pulled from the issuing system
- Rotation runbook link
That's it. Seven fields. The hard part isn't the schema. It's the discipline to populate it, keep it current, and treat any credential that isn't in the table as an incident.
Operators who can query that table in one shot rotate in hours. Everyone else negotiates with their own git history while the regulator waits.