January 5, 2026

Today, depthfirst’s General Security Intelligence adds first-class support for Secrets, now available in public preview. Secrets finds real credentials, including esoteric ones, and shows you which matter.
Modern software runs on secrets. Deployments and production infrastructure rely on API keys, tokens, webhooks, and credentials that end up scattered across repos, configs, CI systems, and logs. Yet most teams still treat leaked secrets as a noisy, after-the-fact problem.
You run a scanner, get flooded with alerts, and start manually digging. Hundreds of findings turn out to be stale, placeholders, or false positives. A small number actually matter, but identifying them takes real time and judgment. The result is predictable: teams either accept the risk and move on, or burn engineering hours chasing noise.
Recent breaches show why that approach doesn’t work. Attackers don’t need sophisticated exploits. They just need credentials left behind in a repo or a log file. By the time a leak is investigated, access has often already been abused, and teams are left reacting instead of preventing.
Secrets helps teams stay on offense. It finds real, active credentials, including hard-to-detect ones, and shows you which exposures actually matter. Instead of flagging every risky-looking string, Secrets tells you what to fix first and why.

Secret scanning has not kept pace with how teams build software. Most tools focus on what’s straightforward:
That works for the short head of standardized, well-known secret types: GitHub tokens, AWS keys, Datadog, Slack. But real systems run on a long tail of providers, internal services, custom integrations, and one-off credentials. That’s where most tools break down. It’s also where incidents start.
Even when a scanner finds a real secret, teams still face the same questions:
Without clear answers, everything looks urgent. Little gets fixed.
Secrets is built around a simple idea:
The job isn’t to find more secrets. The job is to fix the ones that matter.
That requires two things most tools miss.
Scanning for GitHub and AWS keys is table stakes.
Modern systems rely on a long tail of SaaS tools, APIs, internal services, and custom credentials. Secrets is built for that reality.
Detection combines deterministic techniques with agentic reasoning so results are explainable, consistent, and grounded in real usage:
Custom and esoteric credentials receive the same treatment as common ones, without sacrificing precision.
The goal is simple: broader coverage without flooding teams with noise.
Finding a secret is only half the problem.
Secrets verifies credentials to determine whether they are active and exploitable.
For each finding, we perform controlled validation against the provider or system:
This changes how teams prioritize work.
Verification does not depend on a fixed set of prebuilt connectors. depthfirst’s General Security Intelligence validates credentials across esoteric and custom systems without waiting for new integrations.
Instead of treating every string the same, Secrets brings the riskiest issues to the top.
.png)
Secrets isn’t just a list of detections. It’s designed for action.
Every finding includes:
Secrets scans more than your current codebase.
Secrets covers:
Attackers don’t care when a secret was committed. They care whether it still works.
Secrets is also secure by default:
We benchmarked our Secret Scanner against competitors using an internal dataset of 600 secrets scraped from public GitHub repositories. The dataset spans various secret providers and types, including API keys, signing secrets, and tokens. Overall, we found significant performance differences: our system identifies substantially more secrets than deterministic systems can (higher recall) while simultaneously producing less noise (higher precision).
That’s not because we match more regexes; we combine coverage, context, and verification into a single system that prioritizes what matters.
.png)
The following is an example Maven Central publishing credential pair our scanner caught in the wild that no existing scanner could identify:
File: gradle.properties
SONATYPE_HOST=CENTRAL_PORTAL
RELEASE_SIGNING_ENABLED=true
GROUP=io.github.[REDACTED]
mavenCentralUsername=[REDACTED]
mavenCentralPassword=[REDACTED]With both the username and password, an attacker could publish malicious library versions and create a supply chain attack to target any downstream user. Gradle explicitly recommends storing these locally or in the CI secrets
Traditional scanners likely missed this because Maven Central credentials lack a distinctive pattern format like AKIA... for AWS or ghp_... for GitHub.
Our LLM-first approach reasons about critical repo context: file types, variable naming patterns, and credential relationships. This allows depthfirst to detect secrets invisible to pattern-matching scanners.
Secrets is now in public preview for depthfirst customers.
If you want to see it in action, including credential verification and long-tail coverage, we’d be happy to walk you through it.
Click book a demo to schedule a walkthrough.

Secure your code to ship faster
Link your Github repo in three clicks.