Deleting an API Key From Git Doesn't Mean It's Gone

Yusup Atahanov — Mon, 09 Nov 2026 14:02:58 +0000

Imagine accidentally committing an API key to a Git repository.

You notice the mistake, delete the key, commit the change, and push again.

Problem solved?

Not necessarily.

Git stores the history of your project. Removing a secret from the latest version of a file doesn't automatically remove it from previous commits.

Here's a simple example.

Create a test repository

mkdir git-history-demo
cd git-history-demo
git init

Create a file containing a fake credential:

echo "API_KEY=example-not-a-real-key" > config.env
git add config.env
git commit -m "Add configuration"

Now remove it:

git rm config.env
git commit -m "Remove configuration"

The file no longer exists in your working directory.

But the original commit still exists.

Check the Git history

Run:

git log -p --all -- config.env

You'll see the earlier commit containing the fake credential.

This is normal Git behavior, but it becomes a security problem when developers accidentally commit real API keys, authentication tokens, or passwords.

Deleting a secret does not mean it was never exposed.

What happens if a real secret is committed?

The first priority should be to revoke or rotate that credential.

Rewriting Git history may help remove sensitive data from the repository, but it cannot guarantee that nobody has already copied it.

GitHub provides official guidance:

Removing sensitive data from a repository

Why I started building JetScan

While working on developer tools, I wanted a straightforward way to identify security problems without uploading source code to a third-party scanning service.

So I started building JetScan, a source-available security scanner written in Rust.

It can check:

Exposed secrets in project files and Git history

Known vulnerabilities in supported dependency ecosystems

Potentially risky GitHub Actions workflows

Certain local credential and machine security issues

For example:

jetscan secrets .

Or run a broader scan:

jetscan scan .

JetScan supports local scanning and offline operation. Dependency vulnerability checks can query OSV using package names and versions unless offline mode is used.

The project is still young. It doesn't detect every possible secret, and I don't want to pretend it does.

The fake credential in the example above is for demonstrating Git history; it isn't a verified JetScan detection example.

Why Git history scanning matters

Many developers already use .gitignore to avoid accidentally committing local configuration files.

That's useful, but .gitignore does not remove secrets that were committed previously.

Even when a repository looks clean today, its history may contain sensitive information.

That's why checking the current files alone isn't always enough.

Try JetScan

I've released JetScan for Windows, Linux, and macOS.

You can explore the source code, releases, and technical documentation here:

GitHub: https://github.com/y6861977-ui/jetscan

I'm looking for feedback from developers who use security scanning tools in their projects or CI pipelines.

What matters most to you in a security scanner: detection accuracy, performance, privacy, integrations, or something else?

I'd be interested to hear your experience.

I built a package manager because npm doesn't work in my country.

Yusup Atahanov — Sat, 03 Oct 2026 09:05:27 +0000

hi guys, my name is Yusup.

I'm a developer from Turkmenistan. If you haven't heard much about it — the internet here is one of the most locked-down in the world. npm gets blocked, connections die halfway, and some days npm install just sits there forever.

For a long time I thought that was just how it is. You wait. You retry. You keep a VPN open and hope. Setting up a React project could eat an afternoon.

At some point I got tired of being stuck, so I started building my own package manager. I called it jet. Took about 6 months, mostly at night, on my own.

The idea is simple — it should keep working when the network doesn't:

if a mirror is blocked, it quietly switches to another one mid-install
if a package is already on disk, it never touches the network
if a download dies at 80%, it continues from there instead of starting over
one small binary, no Node needed

It's not the fastest out there — bun wins that race, and I'm fine with it. I wasn't chasing a benchmark. I just wanted the thing to not fail.

A few people have tried it already. One was on a Mac — and that one got me, because I'm on Windows and never even tested there. A real stranger, somewhere out there, running something I built alone in a country where the internet fights you.

It's free, works on Windows/Mac/Linux. If your connection is rough — or censored — it might save you some pain.

If you try it, I'd honestly love to hear what breaks. It's the first thing I've ever put out into the world.Thank you for read this post

github url: https://github.com/y6861977-ui/jet
site url: https://jet.kim/

DEV Community: Yusup Atahanov

Deleting an API Key From Git Doesn't Mean It's Gone

I built a package manager because npm doesn't work in my country.