Skip to content
ZK
ZAIN KHALIL KHAN
PORTFOLIO
All projects

Interactive build

SecretSweep | Git History Exposure & Rotation

Repository secret scanner that reports exposure window and blast radius per finding, distinguishing values still in the working tree from values reachable only in pushed history, and drives a rotation-first remediation sequence rather than a history rewrite.

Live demo readySecret Scanning + Git
Secret ScanningGitCredential RotationDevSecOpsEntropy AnalysisIncident ResponseCase study / interactive demo

Case study

From problem to working system

Problem

Repository secret scanner that reports exposure window and blast radius per finding, distinguishing values still in the working tree from values reachable only in pushed history, and drives a rotation-first remediation sequence rather than a history rewrite.

My role

Full-stack software engineer

Solution

Repository secret scanner that reports exposure window and blast radius per finding, distinguishing values still in the working tree from values reachable only in pushed history, and drives a rotation-first remediation sequence rather than a history rewrite.

Architecture

The implementation combines the following technologies and system concerns.

Secret ScanningGitCredential RotationDevSecOpsEntropy AnalysisIncident Response

How it was built

  • Combined provider-specific key patterns with entropy analysis, so an unrecognised high-entropy string is triaged rather than silently ignored.
  • Reported exposure window from the commit age, since a credential in a pushed commit from a year ago must be treated as compromised regardless of whether it was later deleted.
  • Described blast radius per secret in terms of what it authenticates, which is what determines the rotation procedure.
  • Ordered remediation rotation-first: rewriting history before rotating accomplishes nothing because every existing clone still holds the value.

Security decisions

  • Described blast radius per secret in terms of what it authenticates, which is what determines the rotation procedure.

Major challenges

  • Combined provider-specific key patterns with entropy analysis, so an unrecognised high-entropy string is triaged rather than silently ignored.
  • Reported exposure window from the commit age, since a credential in a pushed commit from a year ago must be treated as compromised regardless of whether it was later deleted.
  • Described blast radius per secret in terms of what it authenticates, which is what determines the rotation procedure.

Verified evidence

Results and measurable impact

  • Described blast radius per secret in terms of what it authenticates, which is what determines the rotation procedure.
  • Ordered remediation rotation-first: rewriting history before rotating accomplishes nothing because every existing clone still holds the value.
  • Distinguished deactivation from deletion during rotation, so a rollback does not take production down mid-remediation.
  • Closed the loop with the pre-commit and CI gate that would have caught the finding, since remediation without prevention only resets the clock.

No separate numeric outcome is documented, so this section shows shipped technical evidence without inventing metrics.

Screenshots and access

Product view

Open live project

Interactive Demo

A scoped, fully functional recreation of this project's core feature runs below, live in your browser. Reset it, resize it, or expand it to full screen.

SecretSweep

Security platform

SecretSweepWorkspace2 updates
SecretSweep · History & Rotationshare of findings still present in the working tree
2 live · 5 found

Finding a secret in git history is the easy half. What matters is exposure window and blast radius: how long it sat in a pushed commit, what it authenticates, and therefore what rotating it actually requires. Purging history without rotating first accomplishes nothing, because every clone already has the value.

Findings

5

across tracked history

Still live

2

present in the working tree

Pushed

4

assume compromised

Longest exposure

730d

oldest reachable commit

Still live4 pushed
2/5in tree
Exposure window per findingoldest 730d

Marked bars were pushed to a shared remote. Those are compromised regardless of whether a later commit deleted them.

Findings5 shown
AWS access keyinfra/deploy.sh9f2c1ab412d agopushed

AKIA****************

Blast radius: Full deploy role in the production account

Deactivate the key in IAM, issue a replacement, then delete the old one after the deploy job is confirmed green.

Database URL with password.env.production4b81e0796d agoIN TREEpushed

postgres://app:****@db-prod:5432/app

Blast radius: Read and write on the primary Postgres cluster

Rotate the role password, update the secret store, then restart consumers. Assume the credential is compromised.

Stripe secret keyscripts/backfill.jsc07d55e21d agolocal only

sk_live_****************

Blast radius: Live charge and refund on the payments account

Roll the key in the dashboard immediately. Unpushed does not mean unexposed if the branch was ever shared.

Private SSH keyops/id_rsa1de49f8730d agopushed

-----BEGIN OPENSSH PRIVATE KEY-----

Blast radius: Shell access to three bastion hosts

Remove the public key from every authorized_keys, generate a new pair, and audit login history for the old key's fingerprint.

High-entropy stringsrc/config.ts77aa3108d agoIN TREEpushed

b7Qx****************

Blast radius: Unclassified. Entropy 4.9 bits/char over 44 characters.

Triage manually: confirm whether this is a live credential or a checksum before rotating anything.

Remediation order

Start with rotation. Until the credential no longer authenticates, purging history changes nothing: every existing clone still holds the value.

Zain Khalil Khan