The Key You Deleted From GitHub Isn't Gone

On June 15, the PIPC released an advisory urging stronger credential management when using cloud services and dev collaboration tools. It doesn't create any new obligation — it's a recommendation. But the domestic breach cases attached to the material are more specific than I expected, so it's worth a closer look.

One Access Key, 10 Million Records

The material lists four cases.

Company C had roughly 10 million personal records leaked after an AWS access key exposed on GitHub was harvested. Company B lost 420,000 records because DB connection details were stored in plaintext on GitHub. Company A was hit first by a spearphishing attack that took over a GitHub account, and the AWS access key obtained from there was used to read 2.4 million personal records in an internal database. Company D was a case of a secret key hardcoded into source code.

None of the four broke through a system vulnerability. The attacker simply logged in with valid credentials. That's the part that's hardest to deal with in practice. Looking only at the access logs, it reads like normal access. The WAF doesn't catch it. Neither does the IPS. The breaches that only get discovered months later mostly have this shape.

Deleting It Doesn't Remove It

The line I personally found most important in the material isn't one of the breach cases — it's the Secretary-General's comment at the end. When you accidentally push a credential to a code repository, deleting it from your working copy leaves it sitting in the version-control history.

Sounds obvious, but fewer dev teams understand this precisely than you'd think. Delete the file with the key and commit, and it disappears from the latest code. But it's still there in the earlier commits. Even if you rewrite the history, it's useless if someone has already cloned it, a fork exists, or a diff remains in a PR. If it was a public repo, assume a bot has already scraped it.

Plenty of incident-response procedure documents don't have this order written into them. If it says something like "delete the leaked file, then report," then in a real situation the developer is most likely going to start by deleting the commit. And in the meantime, the key is still alive.

Issuance Structure Over Detection

Among the recommendations, the one worth noting is temporary credentials — using something like an AWS IAM Role that auto-expires after a set time. The rest (IP/network restrictions, MFA on key systems, least privilege, immediate revocation of unused permissions) is honestly nothing new.

Automated detection tools like GitHub Secret Scanning and Push Protection are also given as examples in the material, but those are, at best, an after-the-fact safety net. As long as long-lived keys with no expiration keep getting issued, detection will eventually be bypassed.

That said, dropping "ban long-lived credentials entirely" straight into a consulting report isn't realistic. Legacy batch scripts, vendor integration interfaces, leftovers carried over from on-prem — long-lived keys are embedded in most of them. For places like this, I propose the order in reverse. First, build a complete inventory of issued keys, and for each one confirm its purpose, owner, and last-used date. Just revoking the keys nobody uses cuts the attack surface noticeably. Switching to temporary credentials comes after that. If you push to bolt on IAM Roles when there isn't even an inventory, nothing happens.

What the Audit Will Ask

From a consulting standpoint, this material reads like a preview of an audit questionnaire. If your organization has moved, or is moving, to the cloud, it's worth having the following ready.

From the source program management (2.8.5) angle: is there a procedure to check for hardcoded credentials in code? And if so, is it spelled out in the code-review checklist, or checked automatically by a tool? From the access rights review (2.5.6) angle: is there a register for issuing and revoking cloud access keys, and is the review cycle actually running? From the database access (2.6.4) angle: where and in what form is DB connection information stored? Is MFA enforced on the management console and the DB?

It's also worth remembering that the department that put out this material is the Advance Inspection Division. Reading it as a signal of where the PIPC is looking wouldn't be far off.

It's not that the companies that got breached didn't know better. Even a junior developer knows not to put keys in source code. The problem is that a key dropped in for a quick moment under pressure is still alive three years later — and that nobody is counting them.

---

Source: PIPC urges stronger credential management when using cloud and dev collaboration tools (2026.6.15)