Most of what your secrets scanner flags isn't a secret. Regex can't tell a live key from a checksum. Pixee reads the code around each finding and tells you which are real, with the evidence. Your developers stop chasing false alarms.
A pattern match stops the build. Someone still has to prove it's a secret.
A secrets scanner doesn't find secrets. It matches shapes. At one global bank the rules were three regexes: a password =-style assignment, a standard UUID, and a 64-character hex string meant to catch crypto-wallet private keys.
40,000+findings in the bank's manual review queue
<200were real secrets
~40people triaging them by hand
That's roughly 200 false alarms for every real secret. The team couldn't keep up.
It isn't one bank's problem. When researchers benchmarked nine secret-detection tools, five scored under 7% precision, tripping on placeholders, commit IDs and other long, random-looking strings. (Basak et al., 2023)
A 64-character hex string could be an Ethereum private key, a SHA-256 hash, an HMAC signature or a CSP hash. The SHA-256 of the word "hello" is itself a valid wallet private key, and the Bitcoin address it unlocks has received real funds.
And one match hard-fails the build, so a developer with a perfectly safe change ships on another team's schedule.
How it works
Pixee reads the code, not just the pattern.
Pixee runs the same checks a careful engineer would, on every finding, every time. No fresh guess from a chat prompt.
01
Code-context analysis
Pixee reads what surrounds each finding (variable names, file paths, imports, config, data flow) and decides from that context whether it's a secret.
02
Knows what's never a secret
Every finding starts from a curated catalog of the usual false alarms: analytics IDs, Sentry DSNs, publishable keys, placeholders like changeme, and the pk_-vs-sk_ convention.
03
The same questions, every finding
A secret or a field name? Test code? A client-side token? Localhost only? A real secret in a test still flags, at lower severity.
04
Handles rules it's never seen
Point Pixee at a rule it has never seen. It works out the finding type from rule metadata, CWE tags and code context. No pattern tuning.
05
Evidence, not a flag
Every verdict, whether true positive, false positive or inconclusive, carries its reasoning, so your team reviews a rationale instead of a binary.
See it next
The same 64-hex value, triaged two ways.
Worked example
Two identical strings. Opposite verdicts.
Both findings below match the bank's noisiest rule, the 64-character hex pattern. Pixee reads the code around each and reaches opposite verdicts.
the privateKey name beside network=mainnet, the "Crypto tipping" comment, and how the app loads its properties at startup.
Verdict:
a real private key. The feature is switched off, but the key still ships in the repo, the build and every deployment.
False positive
A CSP hash in web.xml
The finding:
the same 64-hex shape.
What Pixee read:
the contentSecurityPolicy parameter name and the sha256- prefix.
Verdict:
a CSP hash, a browser integrity check rather than a credential.
In your pipeline
Unblock developers. Keep real secrets blocked.
Pixee adds one step after the scan you already run. It reads each finding and passes a verdict to your build. False alarms stop blocking developers, and real secrets still stop the build. Your Gitleaks or SonarQube scan doesn't change.
Today
PR opened
Gitleaks runs
A match hard-fails the build
Developer opens a PR against the central Gitleaks config
Security team reviews and merges
Scan re-runs: days, for a safe change
With Pixee
PR opened
Gitleaks runs
Findings go to Pixee for triage
Pixee returns a verdict on each finding
Every finding cleared as a false positive? Your pipeline passes the build
Any finding not cleared? Your pipeline fails the build
Set it to fail safe. The build passes only when every finding is a confirmed false positive, and anything uncleared or unresolved fails it. Nothing ships on an unconfirmed secret.
For the bank's pilot, we also designed a step where Pixee prompts the developer's coding agent to open the Gitleaks suppression PR, with its evidence attached. Ask on a demo what's turnkey for your stack.
The evidence
Every verdict shows its work.
Each finding comes back with the files Pixee read, the controls it found and the counterpoints it checked. Your team gets a rationale it can defend in a review, not a verdict to take on faith.
True positivePixee's verdict, the config that proves it, and the counterpoints it checked
Scope
Triage first. Fixing a secret is a human job.
Pixee triages secrets findings and hands your team the evidence. It doesn't rotate credentials, scrub git history or manage a vault. Fixing a leaked secret means rotating it and updating everywhere it's used, and that belongs with the people who own the system. Pixee gets them to the findings that matter, fast.
Coverage & deployment
One engine, across your scanners, wherever your code runs.
One engine
Secrets isn't a separate product. It's the same triage engine that already clears noise from your SAST and SCA findings, with the same code-context analysis and evidence. Every finding lands in one place.
Where it runs
Cloud (SaaS)
Self-hosted in your VPC
Air-gapped
In a self-hosted deployment, your code never leaves your infrastructure and is processed for analysis, not stored permanently. Air-gapped runs use a self-hosted LLM inside your perimeter, with no calls to a third-party model.
We ran the bank's own rules, unseen, against a codebase we didn't tune for. It got every finding right.
To test code-context triage, we ran the bank's own three detection rules against Apache Roller, a large open-source Java application seeded with real and fake secrets. We used a public reference codebase because we can't test on a customer's proprietary code. Pixee had never seen the rules. With zero configuration, it classified every finding correctly.
Caught: the real ones
Database passwords
SMTP API keys
LDAP bind credentials
An Ethereum private key
Webhook signing secrets
It found each one by reading the code that used it.
Dismissed: the look-alikes
SHA-256 test assertions
CSP hashes
Maven dependency checksums
Password-validation regex constants
UUID-formatted schema identifiers
Documentation examples
It cleared each one by reading the code that showed it wasn't a secret.
False positivePixee clears a CSP hash and shows why
FAQ
Questions teams ask.
Which scanners does Pixee work with?+
Pixee post-processes your existing secrets scanner's output, for example Gitleaks and custom SonarQube rules, by reading its SARIF report. Because Pixee derives a finding's meaning from the rule metadata and the surrounding code, it can triage rules it has never seen before, so it isn't limited to a fixed list. Your current scan and report stay untouched; Pixee adds the triage step.
Does the triage step slow my build down?+
It adds one step between your scan and the build gate: the time Pixee takes to triage that batch of findings. It runs as post-processing on your scanner's existing report, so it doesn't change the scan itself.
What happens if Pixee can't reach a clear verdict on a finding?+
Your gate treats an inconclusive finding as not cleared, so the build fails and a human reviews it, the same as a true positive. Nothing passes on a finding Pixee couldn't confirm was safe.
What if the triage step itself errors or times out?+
Because the gate you wire only passes on a confirmed false positive, an error or timeout isn't a clearance. The build fails rather than shipping an unchecked finding.
Does Pixee fix secrets?+
No. Pixee triages. It tells you which findings are real and why. Rotating and replacing the credential stays with your team.
Does our code leave our environment?+
You choose. Pixee runs as cloud (SaaS), self-hosted in your own VPC, or fully air-gapped. In a self-hosted deployment your code never leaves your infrastructure. It's processed for analysis, not stored permanently. Air-gapped runs use a self-hosted LLM inside your perimeter.
How is this different from my scanner?+
Your scanner matches a pattern. Pixee reads the code around each match to tell a real secret from a look-alike, and shows its work.
How is this different from other secrets tools?+
Most secrets tools detect. They find more matches, or check whether a leaked key is still live. Pixee is a triage layer on top of the scanner you already run: it reads the code around each finding to decide which ones are real, with evidence.
Point it at your own findings.
Bring your last Gitleaks or SonarQube report. No rule tuning. See which of your findings are real, with the evidence for each.
