Sefism is free for learners. We are here to help you grow, one step at a time.Join for free
Sefism.
Security

Leaked Secrets Monitor with Live-Key Verification for Small Dev Teams

A secrets scanning service for small software teams that finds API keys and passwords in Git history, CI logs and config files, checks safely whether each key is still live, and walks the developer through rotating it. An intermediate security final year project on detection accuracy, verification and remediation workflow.

Topics
Difficulty

Intermediate

A small team, or one strong student willing to learn something new.
Effort

2 semesters · 2 to 3 students

Deliverables

7 to ship

3 optional extras

Suggested stack

Go or PythonGit internalsGitHub App APIPostgreSQLRedis job queueReact dashboardPre-commit hooks
A suggestion, not a requirement. Swap anything for what you already know.

What you should ship

  • A scanner that walks full Git history of a repository and detects at least 25 secret types using a mix of patterns, entropy and context rules, with a documented false-positive filter
  • A pre-commit hook and CI step that block new secrets before they are pushed, with a clear message and an allow-list mechanism
  • Safe, read-only verification for at least 8 providers (for example cloud, payment, messaging and database keys) that reports live, revoked or unknown without ever using the key to change anything
  • A GitHub App that scans on push and on install, opens a private issue for each live finding and never posts secrets in plain text
  • Per-provider rotation playbooks: step-by-step revoke, reissue and redeploy instructions, with a checklist the developer ticks off
  • A dashboard of findings by repository with severity driven by live status and exposure (public repo, fork, CI log)
  • A labelled benchmark of at least 300 seeded secrets across test repositories, with precision and recall reported against Gitleaks and TruffleHog

If you have time left

  • Scan CI build logs and Docker image layers, not just source
  • Integration with a secrets manager so rotation can write the new key directly
  • A public-repo watch for a company's own organisation that alerts within minutes of a leak

The problem small dev teams have with leaked keys

A developer pastes a payment gateway key into a config file to test something, commits it, and deletes it in the next commit. The key is still in Git history. The repository is private today, but a contractor has a clone, the CI logs printed it, and next year someone makes the repo public for a portfolio. Leaked cloud keys are abused quickly for crypto mining; leaked payment or messaging keys cost real money.

Large companies have tooling and a security team to chase these. A team of four at a software house or a fintech startup usually finds out from the bill.

What already exists and the gap

  • GitHub secret scanning and push protection: free for public repositories; for private repositories it is part of the paid Secret Protection product billed per active committer.
  • GitGuardian: a polished secrets platform with a free tier for small teams, but beyond it, pricing is per developer and aimed at larger organisations.
  • TruffleHog (open source): strong detection with verification of whether a key is live. A command-line tool; triage and remediation are up to you.
  • Gitleaks: fast, pattern-based, widely used in CI. No verification and no workflow after detection.

The gap is the part after detection. Small teams need to know which findings are live right now, and what exact steps fix each one for their provider. Detection without verification produces noise; verification without a remediation workflow produces anxiety.

What you build

Roles: team admin (installs the app, sees all findings), developer (gets assigned findings, follows playbooks).

  1. Prevent: a pre-commit hook and CI job block new secrets.
  2. Discover: installing the GitHub App scans every branch and the full history of selected repositories.
  3. Verify: each candidate is checked with a provider-specific, read-only call (for example an identity or "who am I" endpoint) and marked live, revoked or unknown.
  4. Remediate: live findings open a private tracked item with the right playbook. Closing requires confirming the old key is now revoked, which the system re-verifies.

Secrets must be stored hashed or encrypted at rest, masked in every UI and log, and verification must run from a controlled worker with rate limits.

The technically interesting part

The core problem is precision without losing recall. Pure regex matching finds test keys, example strings and random hashes. Pure entropy flags every UUID. Your detector combines provider patterns, entropy thresholds, surrounding context (variable names, file types, test folders) and verification. Build a benchmark of seeded secrets plus realistic decoys and measure how each layer changes precision and recall.

The second hard part is safe verification. For each provider, find a call that proves validity without side effects, document why it is safe, and handle rate limits and network failures so that "unknown" is never reported as "revoked".

How to evaluate it

  • Detection: precision and recall on your 300-secret benchmark, compared with Gitleaks and TruffleHog run on the same repos.
  • Verification accuracy: for keys you create and then revoke on test accounts, how often the live/revoked status is correct.
  • Performance: time to scan a repository with 10,000 commits; pre-commit hook latency (target under one second for a normal commit).
  • Remediation: in a user test with five developers, time from alert to a verified rotated key using your playbooks versus without them.

Suggested plan

  1. Weeks 1 to 4: study Git object storage, build the history walker, create test repositories and the benchmark.
  2. Weeks 5 to 9: detectors, entropy and context filters, pre-commit hook.
  3. Weeks 10 to 14: verification workers for 8 providers, secure storage of findings.
  4. Weeks 15 to 20: GitHub App, dashboard, playbooks.
  5. Weeks 21 to 26: evaluation, user tests, write-up.

Path to a product

The first customer is a software house doing client work, where one leaked client key damages a relationship. Offer a free tier for public repositories and a flat monthly price for small teams on private repositories, undercutting per-developer enterprise pricing. The playbook library and verifiers are your moat; keep them open to contributions and sell the hosted workflow.

Scope warning

Never use a found key for anything beyond a documented read-only validity check, and only for repositories whose owners installed your app. Do not scan other people's public repositories to find leaks. Do not build a general secrets manager.

Learn what you need on Sefism

Get help with this idea

Scoping a security project is mostly about deciding what you will not defend against and how you will prove the rest works. If you want a second opinion on scope, stack or your evaluation plan, a mentor can review it with you; you still build it yourselves. New to Sefism? Create a free account first.

Ideas and guidance, not finished projects

These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.

Not sure this one fits you?

I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.

Discuss this idea
Work with me

Stuck on something specific?

Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.

Book a free sessionSee all services

Follow along

New writing, resources and project ideas land here first.