omerta er vår åpen kildekode-kontroll for hemmeligheter i git. Den leser verdiene i et prosjekts env-filer og feiler når en av dem er i git: staget for neste commit, i en sporet fil eller hvor som helst i historikken. Den første utgivelsen, 0.1.0, er ute i dag.
Dette innlegget er kortversjonen: hva omerta gjør, hva den første utgivelsen har, hvorfor det betyr noe, og hvordan du bruker den. Detaljene står i repositoriet. Eksemplene deler én oppdiktet applikasjon: en agent som bestiller reparasjonsbesøk for et selskap som reparerer hvitevarer. Den sender kundene SMS gjennom en SMS-tjeneste og lagrer bilder av feilene i en bøtte i skyen, og .env-filen dens har nøkkelen til SMS-tjenesten og navnet på bøtta.
Hva omerta gjør
I prosjektets katalog, én kommando:
uvx omerta check --all
Den henter verdiene i env-filene i prosjektets rot som git ikke sporer, .env og .env.*, og søker etter hver av dem i alle sporede filer: slik verdien er skrevet, og slik den ville stått i en URL, i en JSON-streng og i base64, i tekst, i binærfiler og i filnavn. En env-fil som git sporer, er et funn i seg selv. Uten --all søker omerta check i det som er staget for neste commit.
Mønsterskannere, som gitleaks og TruffleHog, ser etter det som ser ut som en nøkkel: et format som en av reglene deres beskriver. omerta ser etter nøklene dine. Den trenger ikke å vite hvordan en verdi ser ut, så den finner nøkkelen til en liten leverandør, navnet på en bøtte eller ID-en til en organisasjon like sikkert som en nøkkel med et velkjent prefiks, og den har ingenting å si om en sjekksum som bare ligner på en.
Agentens tester tok opp et kall til SMS-tjenesten, og opptaket har nøkkelen i URL-en, prosentkodet. Dette er omertas rapport for agentens repositorium:
app/photos.py:1: BUCKET (from .env)
tests/visit.yaml:4: SMS_KEY (from .env)
Hver linje navngir filen, linjen og variabelen, og aldri verdien. Kontrollen feiler så lenge noe blir funnet, så en commit eller en CI-jobb stopper der. omerta kjører uten nett: Den har ingen nettverkskode.
omertas lanseringsvideo, med musikk. En env-fil har en nøkkel til OpenAI og navnet på en bøtte for lagring, og filmen sier at hemmelighetene dine bor i .env. Nøkkelen limes inn i koden i src/client.py, én innliming unna git, og en commit ville beholdt den i historikken for godt. Så kommer navnet omerta og linjen dens, fang .env-hemmeligheter som lekker inn i git, dine egne verdier og ikke etterligninger. En commit kjører omerta, som feiler og stopper den, navngir OPENAI_API_KEY i src/client.py og i opptaket fra en test og aldri skriver ut nøkkelen. Strenger som bare ligner nøkler, blekner bort, og prosjektets egne verdier blir stående, navnet på en bøtte, et databasepassord og ID-en til en organisasjon. Hver blir funnet i enhver form, slik den er skrevet eller kodet i en URL, i JSON eller i base64. omerta kontrollerer det som er staget, hver sporede fil og hele historikken. Filmen slutter med navnet omerta, kommandoen uvx omerta check --all og adressen til repositoriet.
En første utgivelse
0.1.0 har de to kontrollene, omerta check for filene og omerta history for hver commit, hver tagg og hver commit-melding, de fire formene av hver verdi, en pre-commit-hook og innstillinger i .omerta.toml eller i pyproject.toml. Hver form av hver verdi søkes etter i én gjennomgang av hver fil, med Hyperscan. De to avhengighetene, python-dotenv og hyperscan, ser verdiene i klartekst, så begge er låst til eksakte versjoner: En ny utgivelse av en av dem når omertas brukere bare gjennom en utgivelse av omerta. Den kjører på Python 3.11 og nyere. Hva den leser og kjører, og hva den aldri gjør med en verdi, står i sikkerhetsmodellen.
Hvorfor det betyr noe
De fleste hemmeligheter som lekker, har ikke et format som en regel kan beskrive. GitGuardian, som selger deteksjon av hemmeligheter, telte 28,65 millioner nye hemmeligheter i offentlige commits på GitHub i 2025, med sine egne detektorer, og skrev i 2024 at nøkler fra velkjente leverandører, som ofte følger bestemte mønstre, utgjør mindre enn 40 % av alle hemmelighetene selskapet finner, og at de fleste lekkasjer altså ikke følger et enkelt, gjenkjennelig mønster («account for less than 40% of all the secrets we uncover. This means that most leaks don't adhere to a simple, recognizable pattern»).
Det som ikke har noe mønster, blir bedømt ut fra sammenhengen, og sammenhengen kan villede. GitHub, der hemmelighetsskanningen nå finner slike hemmeligheter med en egen modell, forklarer at strukturerte tilgangsnøkler ofte har et særpreget prefiks, en lengde, et alfabet eller en sjekksum, og at generiske hemmeligheter kanskje ikke har det («Structured credentials often include a distinctive prefix, length, alphabet, or checksum. Generic secrets may not.»). Modellen avgjør ut fra hvor en verdi står («Context is the deciding signal»), og regner den samme passordlignende verdien i testdata blant det som sannsynligvis er harmløse etterligninger («The same password-shaped value in a test fixture»). Det er en rimelig gjetning for det meste av testdata, og en gal en for opptaket til agenten, som har den ekte nøkkelen. omerta gjetter ikke: Den kjenner verdiene. Den finner verdiene i env-filene dine og ingenting annet, så en nøkkel som ikke står i noen env-fil, er fortsatt en mønsterskanners å finne, og de to brukes sammen.
Å slette en nøkkel fra git tar den ikke tilbake. 27. mai 2026 ble en konfigurasjonsfil for OpenCode, en kodeagent, committet til et offentlig repositorium hos LiteLLM, med hovednøkkelen til en installasjon av selskapets Agent Platform i seg. LiteLLMs redegjørelse for det som fulgte: Feilen ble raskt oppdaget, commiten ble overskrevet med en force-push, og nøklene som var eksponert, ble vurdert som nøkler som måtte tilbakekalles, men hovednøkkelen ble aldri tilbakekalt («The error was quickly identified, the commit force-pushed over, and we identified the exposed keys as requiring revocation. However, key revocation did not occur for the master key.»). 10. oktober brukte en angriper nøkkelen, og nådde gjennom den tokener som lot vedkommende publisere en kompromittert utgivelse av litellm til PyPI 21. oktober, der den lå i nesten to timer. LiteLLM skriver selv at hendelsen er en tydelig illustrasjon av risikoen ved å la være å rotere en nøkkel som kan ha vært eksponert («This incident has provided a strong illustration of the risks associated with failing to rotate a potentially exposed key.»).
En kontroll før commiten holder verdiene i env-filene dine ute av git. En verdi som allerede er i git, må tilbakekalles og erstattes, uansett hvor commiten har tatt veien siden.
Slik bruker du den
Slik installerer du den som verktøy:
uv tool install omerta
Før hver commit. omerta check søker i det som er staget, og det gjør den til en pre-commit-hook. Med pre-commit:
repos:
- repo: https://github.com/shcherbak-ai/omerta
rev: v0.1.0
hooks:
- id: omerta
Repositoriet har det samme for Husky, Lefthook og en vanlig git-hook.
Verdier som ikke er hemmeligheter. omerta søker etter verdiene i env-filene, hemmelige eller ikke, så DB_HOST=localhost blir også funnet. En variabel som ikke har noen hemmelighet, utelates:
ignore = ["DB_HOST"]
Det som allerede er i historikken. Én gang, over hele historikken:
uvx omerta history
Den rapporterer hver verdi ved commiten der den kom inn i en fil, også der en senere commit fjernet den. Opptaket til agenten ble slettet i en senere commit, og omerta history finner fortsatt nøkkelen i commiten som tok opp kallet.
I CI. CI har ingen .env å hente verdier fra, så der finner omerta env-filene som er committet. Repositoriet har en arbeidsflyt for GitHub Actions.
Spørsmål du bør stille
Enten kontrollen er omerta, en mønsterskanner eller begge, viser disse spørsmålene om den dekker prosjektet ditt.
- Hvilke av hemmelighetene deres har et format som skannerens regler kjenner, og hvilke har ingen?
- Kjører kontrollen før en commit, eller først når den er pushet?
- Søker den i historikken, eller bare i filene slik de er nå?
- Ville den funnet en nøkkel i opptaket fra en test, kodet i en URL?
- Skriver rapporten ut hemmeligheten den fant?
- Når en nøkkel blir funnet i historikken, hvem tilbakekaller den, og hvor raskt?
Vi publiserer bare verktøy vi bruker selv og kan anbefale til andre. Hvert av dem gjenspeiler hvordan vi bygger, og omerta gjenspeiler ett ord av det: styrt. Vi bygger AI-agenter tilpasset din virksomhet, verifiserbare, begrensede og styrte.