Inside Hyperstack: How Every Code Change Gets Scanned for Secrets

The Key You Pasted In "Just to Test"

You are wiring up a new integration and want to see whether the call works before you build it properly. You paste the API key straight into the file, run the code and it works. A meeting starts, the change gets committed with the rest of your work and the key is now part of your codebase.

Most developers have done this at least once and most of the time nothing bad follows. The trouble is that a key sitting in code can be read by anyone who can read that code, today and for as long as the history of that code exists.

Your work runs on Hyperstack, and the systems behind the platform are built and configured from our own code.

Our latest blog explains how it works and why it is built the way it is. It also shows how you can set up the same free tool on your own projects, starting with the code that holds your Hyperstack API key.

Leaked Keys Are Common and They Stay Valid for Years

The scale of the problem is larger than most teams assume. GitGuardian counted 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% rise on the year before. Secrets tied to AI services grew faster still, reaching about 1.28 million, up 81%, and that matters for anyone building AI products because model provider keys and inference credentials are part of the daily work of an AI team.

Leaked keys also tend to keep working long after they leak. Truffle Security published research on 29 September 2026 that scanned 224 million public GitHub repositories and found 543,699 unique credentials that still authenticated when tested in July 2026. Half of those working credentials had been exposed for more than two years.

Both companies sell secret scanning products, so it is fair to read their figures with that in mind. These numbers describe public code in general and say nothing about Hyperstack, but the pattern they point to is consistent: keys leak often, and once a key has leaked it usually stays valid until someone deliberately cancels it.

Deleting a Secret Does Not Remove It

Code lives in Git, and every change a developer saves into Git is a commit. Git keeps every commit, much like the version history in a shared document. If a developer notices a key a week later and deletes the line, the current version of the file is clean but last week's commit still holds the key. Anyone who copies the repository gets every past commit with it, so they get the key as well.

This changes what fixing a leak actually means. Removing the line is necessary, but the fix is rotation: cancelling the exposed key with the service that issued it and issuing a new one, so the copy left in the history no longer opens anything. Other research from Truffle Security makes the same point from the other side, listing deleted repositories, overwritten files and rewritten history among the common clean-up steps that still left working keys active.

It also explains the cost curve that shaped our design. A secret caught on a laptop costs the developer a few seconds to delete. A secret caught after it reaches shared code has to be rotated, which involves the owner of that service and every system that uses the key. A secret that reaches the live platform or public code becomes a security problem in its own right, so we put a check at each point where catching it is cheaper than at the next.

Three Checks Between a Laptop and the Live Platform

Code does not go straight from a developer's laptop to production. It moves through a shared development copy, then through staging and pre-production, which are rehearsal copies of the platform, and only then to the live environment. An automated pipeline tests and builds the code along the way, and the secret scan now runs inside that pipeline by itself, so nobody has to remember to run it.

A change meets the scanner at three points on that journey:

1. On the laptop, before each commit. A pre-commit hook runs the scanner against the change a developer is about to save. If it finds something that looks like a secret, the commit is refused and the developer is shown the file and line. Each developer switches the hook on once in their copy of a project, and after that it takes about a second per commit.
2. On every change sent to shared code. When a developer pushes commits or opens a pull request, the pipeline scans before anything is built. It reads only the new commits so it stays quick on everyday work. Once a project is in blocking mode, which we come to below, a finding stops the pipeline there, so nothing is packaged and nothing is deployed.
3. On the full history, before going live. When a change moves to pre-production, the last rehearsal before the live platform, the scanner reads the entire history of the project, including old versions of every file. This scan takes longer, and it is the one that finds a secret saved months ago and deleted since.

Small scans on every change and one full scan before release is a deliberate trade. Scanning the full history on every push would slow every developer down to recheck commits that have already been checked and scanning only new commits everywhere would miss anything that was there before the scanner arrived. Splitting the work this way keeps everyday changes fast and still gives every release a complete check.

The scan is one shared building block that every project plugs into, so the rules are the same across the platform instead of being configured differently by each team. Changes that only touch a project's README file get a small scan of their own, so documentation is checked as well. A developer can skip the laptop check if they choose to, but the pipeline runs the same scan regardless, so skipping it only moves the catch to a point where it costs more to fix.

The Scanner Must Not Become a Leak Itself

A scanner that finds a secret has to report it somewhere, and that report is one more place the secret could leak from. Pipeline logs are read by many people and kept for a long time, and the results file a scan saves is often downloaded and passed around. Our scanner redacts the value in both, recording which file and line the finding is on without ever printing the secret itself.

The pipeline also posts a summary to our team chat each time it runs, and that summary now includes the number of secrets found. When there is a finding the message turns red, so the person who made the change sees it straight away without the value appearing anywhere new.

Warn First, Clean Up, Then Block

Turning on a blocking check across an established codebase has an obvious problem. Most mature projects have something in their history that looks like a secret, whether that is an old key, a test value or a placeholder. If the scanner blocked from day one, the first full-history scan would stop releases on projects that have not added anything new.

So the rollout runs in two phases. In the first, the scanner runs on every project but only warns: findings appear in the report and in the chat summary and nothing is stopped. Teams use that window to go through what the scanner has flagged, keeping in mind that a finding is anything that looks like a secret, and many turn out to be test values or placeholders rather than real credentials.

Every finding goes through the same four steps. If it is a real secret, it is rotated first, since the old value stays in the history whatever else happens, and then removed from the current code if it is still there. The finding is then marked as handled in an ignore list using its fingerprint, a unique ID the scanner gives every finding, so the full-history scan does not flag the same old value on every run. The team then runs the full scan locally to confirm nothing is left.

Once a project comes back clean, it moves to blocking, where a finding fails the scan and the build and release are skipped. During the warning phase, we are clear with every developer that a new secret on a normal change has to be fixed straight away, even though the pipeline lets it through.

This pattern of warning first, cleaning up and then blocking works for most new controls. It gets the tool running on real code from the start, gives each team an accurate picture of what is already there and avoids the day when a well-intentioned check freezes every release.

How Betterleaks Tells a Key From a Word

Betterleaks is a free, open-source scanner announced in March 2026 by Zach Rice, who also wrote Gitleaks, one of the most widely used secret scanners of the last decade. Much of its detection comes from rules that match known key formats, such as the fixed prefixes many providers put at the start of their tokens. The harder case is a generic secret with no recognisable prefix, sitting in a line of code next to ordinary variable names.

Older scanners handle that case by measuring entropy, which is how random a string looks. Betterleaks adds a test based on a tokeniser, the same kind of tool language models use to split text into pieces. A tokeniser is trained on ordinary text, so a common word or variable name splits into a few familiar pieces, while a random key breaks into many short ones because the tokeniser has rarely seen those character combinations. How many pieces a string breaks into, relative to its length, is a useful signal of whether a person wrote it or a machine generated it.

Articles about Betterleaks often quote a 98.6% figure. It comes from a test of this one filter on a benchmark dataset, and it is not the share of real-world secrets the tool catches. No scanner catches every secret, and ours is no exception, which is why scanning sits alongside rotation and careful handling of keys rather than replacing them.

How to Set Up the Same Checks on Your Own Code

Your Hyperstack API key is a sensible place to start because it authorises calls against your account and deserves the same care as any production credential. The setup below mirrors our three checks and works on any Git repository. The commands are written for Betterleaks 1.9.0. Version 2 changes some of the options, so once the scanner is installed, run betterleaks version to check which one you have.

Install the scanner. Betterleaks is a single binary, available through the usual package managers or as a container image:

brew install betterleaks
# or
docker pull ghcr.io/betterleaks/betterleaks:v1
# or
go install github.com/betterleaks/betterleaks@latest

Scan your full history once. Run the scanner against your repository to see what is already there, old commits included. If it finds a real key, rotate it before you do anything else: create a new key, update the systems that use it and revoke the old one, then remove the value from the code.

betterleaks git . --verbose --redact

Add the laptop check. Betterleaks ships a hook for the open-source pre-commit framework. Install the framework first with pip install pre-commit or brew install pre-commit. Then add the hook to a .pre-commit-config.yaml file in your repository and run pre-commit install once in each copy of the project:

repos:
  - repo: https://github.com/betterleaks/betterleaks
    rev: v1.9.0
    hooks:
      - id: betterleaks

The first commit after installing takes a few minutes because the hook builds the scanner locally. After that it scans only your staged changes, which takes about a second.

Add the pipeline check. Run the same scan as a step in your CI pipeline before the build step, with redaction switched on so the value never appears in your logs. Make sure the job fetches the full Git history first, because some CI systems fetch only the latest commit by default. On GitHub Actions, for example, set fetch-depth: 0 on the checkout step. Betterleaks returns a non-zero exit code when it finds a secret, which most CI systems treat as a failed step, so the build stops there. If you have older findings to work through first, add --exit-code 0 to run it in warning mode, where findings are still reported but the step passes. Remove the flag once your history is clean to switch it to blocking.

Handle false positives explicitly. When the scanner flags a test value or a placeholder on a line you have not committed yet, add a betterleaks:allow comment on that line. For a value that is already in your history, list the finding's fingerprint in a .betterleaksignore file at the root of your repository instead, because a comment added later does not change the old commit. Add --legacy-print to the scan command to see each finding's fingerprint. Either way, the decision is written down where a reviewer can see it.

The simplest protection of all is to keep the key out of the code in the first place. Read it from an environment variable or a secrets manager, so the scanner has nothing to find.

What This Means for the Platform You Build On

Every change to Hyperstack's code is now scanned for secrets, and once a project is in blocking mode a finding stops the release until it has been dealt with. No scanner can promise that a secret will never get through, but one of the most common ways keys leak, a value pasted in during testing and then forgotten, now meets up to three checks before it can reach the systems your workloads depend on.

The same tool and the same three checkpoints are free to use on your own projects. Start with a full-history scan of the repository that holds your Hyperstack API key and you will quickly see whether it finds anything you need to rotate.

New to Hyperstack?

Sign up to launch GPU virtual machines on NVIDIA GPUs and generate your first API key. Set up the checks in your repository before that key goes anywhere near your code.

FAQs

What is secret scanning and why does it matter for code stored in Git?

Secret scanning is an automated check that reads code for passwords, API keys and tokens that were saved by mistake. It matters in Git because every commit is kept in the project's history, so a key that reaches a repository stays usable by anyone with a copy of the code until the key itself is cancelled.

If I delete an API key from my code, is it still exposed?

Yes, because deleting the line only cleans the current version of the file while earlier commits in the Git history still hold the key. The real fix is to rotate the key by revoking it with the service that issued it and creating a new one, so the copy left in the history no longer works.

Does Hyperstack's secret scanning change anything for customers using the platform?

Nothing changes in how you use Hyperstack, since the scanner checks our own internal code rather than your workloads or data. It reduces the chance that a key behind the systems your work runs on ever reaches the live platform, which is why we wanted to show how it works.

Can Betterleaks catch every leaked secret in a repository?

No scanner catches every secret, and the 98.6% figure often quoted for Betterleaks comes from a benchmark test of one of its filters rather than its real-world detection rate. Scanning works best as one layer alongside keeping keys out of code and rotating any key that may have been exposed.

How do I stop my Hyperstack API key from leaking in my own projects?

Keep the key out of your code by reading it from an environment variable or a secrets manager, then run a full-history Betterleaks scan on the repository to check that nothing is already there. Adding the Betterleaks pre-commit hook on your laptop and the same scan in your CI pipeline gives you a check before every commit and before every build.