extuno
Find leaked API keys and credentials before they ship
Extuno runs more than 1000 anchored secret detectors over extension and package source code and over the network traffic the code sends at runtime. Each hit names the file, the line, the provider, and the full value so you can rotate it.
What does secret leak detection catch?
Extensions and packages routinely ship credentials by accident: an API key hardcoded for a build that was never stripped, a token in a config file, a connection string with an embedded password. Extuno runs over 1000 secret detectors across the bundled source of all 12 supported ecosystems, covering cloud provider keys, version control and registry tokens, payment and messaging credentials, database connection strings, and private key blocks.
Each detector is anchored to a specific provider prefix or token format, so a hit means a credential, not a random string. The result lands in the report with the file, the line, and the recommended rotation action. See the detection rules for the full catalog.
How does it avoid false positives?
A secret scanner that cries wolf gets turned off. Extuno's detectors match a credential and never a bare hostname, URL, public identifier, or code token. Every rule is tied to a distinctive format - an access key prefix, a token shape, a key block header - rather than a generic high-entropy guess.
Public endpoints, measurement IDs, content hashes, and base64 image blobs are explicitly excluded, and the same value embedded inside a larger encoded blob is not treated as a leak. The goal is a clean inventory where every row is worth acting on, so the finding can safely block a CI build without drowning the team in noise.
Does it scan runtime traffic too?
Static scanning misses a credential that only appears when the code runs - a key the extension fetches from a server and forwards to another endpoint. Extuno's dynamic sandbox runs the extension or package in an isolated, network-segmented microVM and captures every request before encryption, so HTTPS bodies are visible without a proxy.
The full secret catalog runs over those captured request and response bodies and headers. A token that leaks only at runtime lands in the same inventory as a static finding, tagged with the host and the exact part of the traffic where it leaked. This is how Extuno catches secrets that never sit in a source file.
Why show the full secret value?
Masking a leaked value tells you a secret exists but not which one. To rotate a credential you need the exact string to grep for across your other systems and confirm it is the same key. Extuno shows the full value, bounded in length, in the finding evidence, the secret inventory, the source viewer, and the CSV export.
The value is encrypted at rest. There is no mask-on-display path, because the analyst doing the rotation is the person reading the report. The inventory also deduplicates by value and tracks every location a single key appears, so one rotation closes every instance at once.
How does it fit into CI and rotation workflows?
Secret findings carry a severity and a category, so a CI gate can fail a build when a credential leaks. Extuno emits machine-readable SARIF and JSON for inline pull request annotations, plus a pass/fail gate you set with fail_on severities or categories. GitHub Action, GitLab CI, and pre-commit recipes are available.
Optional live validation checks whether a detected credential is still active with its provider through one read-only request, so you can prioritize the keys that are genuinely exploitable. Review a worked example on the sample report page.
{
"rule_id": "det.secret.aws_access_key",
"category": "secret",
"severity": "critical",
"provider": "AWS",
"file": "background/index.js",
"line": 412,
"value": "AKIA2RT4F7QX9KLMZ8PQ",
"location": "source",
"why": "Hardcoded AWS access key id; usable from any client that ships this bundle.",
"action": "Rotate the key in IAM and remove it from the build."
}Frequently asked questions
How many secret detectors does Extuno run?
Extuno runs over 1000 secret and API-key detectors as part of its static analysis. They span cloud provider keys, version control and registry tokens, payment and messaging credentials, AI provider keys, database connection strings, and private key blocks. The same catalog also runs over captured runtime traffic during dynamic analysis.
Will it flag random strings as secrets?
No. Every detector is anchored to a specific provider prefix or token format rather than a generic entropy guess. Public hostnames, URLs, identifiers, content hashes, and code tokens are excluded by design, so a finding means an actual credential. The detectors are tuned for near-zero false positives so the result can safely gate a CI build.
Does it catch secrets that only appear at runtime?
Yes. Extuno runs the code in an isolated microVM sandbox and captures network requests before encryption. The full secret catalog scans those request and response bodies and headers, so a key the code fetches and forwards is flagged with the host and the exact part of the traffic where it leaked, even when it never sits in a source file.
Why does the report show the full credential?
Because rotating a secret requires the exact value to grep for and confirm across your systems. Extuno shows the full value, bounded in length, in the finding evidence and exports. The value is encrypted at rest, and the inventory deduplicates by value so one rotation closes every instance of the same key.
Can I block a build when a secret leaks?
Yes. Secret findings carry a severity and category, and Extuno emits SARIF and JSON plus a pass/fail gate you configure with fail_on. Set the gate to fail on the secret category to stop a leak at the pull request. GitHub Action, GitLab CI, and pre-commit recipes are available on the CI/CD secret scanning page.