Client
A UK specialist lender with around 900 staff and about 140 engineers across four teams
Sector
Financial Services
Engagement
Repository estate review, secret and personal-data discovery, access redesign and detection engineering - nine-week programme.
What the client needed
Over ten years the lender had accumulated more than 600 repositories across two hosting platforms. Almost every engineer could read almost every repository, personal access tokens never expired, and nobody could say whether customer data had ever been committed for testing. The risk committee asked a narrow question after a large technology company disclosed that a stolen employee login had been used to copy code and personal data from its repositories: could the same thing happen here, and what would be in the haul?
How we worked
- Inventoried every repository, its owner, its last activity and the number of people able to read it.
- Scanned full commit history, including branches and forks, for live credentials and for patterns that look like personal data, then sampled the hits by hand to separate real from synthetic.
- Rotated every confirmed secret in order of what it could reach, starting with anything touching production or payment systems.
- Put both platforms behind single sign-on with phishing-resistant authentication, removed standing read access to everything, and replaced non-expiring tokens with short-lived ones tied to the organisation.
- Added pre-commit and pipeline checks that block new secrets and flag suspected personal data, with a straightforward way to mark a false alarm.
- Built an alert for one identity cloning an unusual number of repositories, or cloning outside its normal hours or network, routed to the on-call engineer.
Measured results
Results confirmed with the client. Names, counts and platform details withheld in line with our standard confidentiality terms.
- Confirmed live credentials found in history were all rotated within the programme, and none had been used from an unexpected location according to the logs we could review.
- The few files containing real customer details were removed from history, and the affected datasets were replaced with generated test data.
- Read access to the most sensitive repositories dropped from nearly the whole engineering function to the named teams that work on them.
- A simulated bulk clone using a test account reached the on-call engineer in under ten minutes.
- New commits containing a secret are now stopped before they reach the shared branch.
"We always said customer data stays out of source control. It turned out we had said it much more often than we had checked it."
Working on something similar?
If this engagement looks like the kind of problem you are facing, we would be glad to compare notes by email.
Context and constraints
The engineering teams were mid-way through a delivery deadline, so nothing could stop builds for long. The two hosting platforms had grown up separately, one inherited with an acquisition. We agreed to start with discovery and rotation, which ask nothing of developers, and make the access changes only once we could show which teams needed what.
Why history mattered more than the current code
Current branches were mostly clean. The trouble sat in commits years old: a database dump added to reproduce a bug, a configuration file with a service password, a spreadsheet of test applicants that had once been real. Deleting a file does not remove it from history, and anyone with read access can still pull it. Recent reporting on a large company whose repositories held personal data against its own policy was a useful reminder that this is not a hypothetical.
Where control really sits
The assumption at the start was that the lender needed a better scanner. It needed fewer people able to reach the material in the first place and a way to notice a mass download. The scanner found the past; the access change and the clone alert shrank what any single login could take in the future.
Lessons learned
First, count the readers of each repository before you argue about controls, because the number is usually a surprise. Second, treat a "synthetic data" label as a claim and check a sample. Third, rotate in order of blast radius, not alphabetically, and rehearse it. A secret you cannot rotate quickly is a secret you do not control.
If your repositories hold more than you would want a stranger to read, we would be glad to talk. Email sales@halfteck.com.