This month's release for TruffleHog Enterprise is focused on seeing more of your secret exposure and closing the gap between finding a secret and fixing it. It's headlined by Topology, a new interactive graph that maps how a leaked secret in one service can be used to reach others, turning a list of findings into a visualized blast radius. Alongside it, Shared Secrets gets a UX overhaul that makes handing a finding to the person who can fix it fast and secure, and Multi-Org GitHub App Scanning extends coverage to every GitHub organization your app is installed in from a single connection.
Topology
Topology is a new interactive graph that shows how a leaked secret in one service can be used to access others. Each node is a service. Each edge is one or more secrets that grant access from a source service to a target service. Together they map the blast radius of a leak, showing not just where a secret was found but everywhere it could take an attacker next.
What's new
Topology is a live map of your secret exposure.
Nodes are services, grouped into three categories that make the map actionable. Scanned services are actively monitored. Not monitored services are scannable but not configured yet. Non-scannable services are targets with no scanning integration available. Click a node to see how many secrets were found there and how many grant access to it. If it is a scannable service that is not yet monitored, you can configure scanning inline.
Edges are the secrets flowing from a source service to a target service. TruffleHog aggregates them, so a single line carries a total secret count and the distinct secret types it represents. Click an edge to see the full flow: source, destination, total secrets, and every secret type involved, with one-click routing to the filtered Secrets view. Filtering can be by category or triage state.
The problem we're solving
A list of secrets tells you what leaked. It does not tell you what that leak threatens. The real risk of a credential is defined by what it connects to. A token found in a repo might unlock a cloud bucket, a database, or a payment provider, and tracing that chain usually means cross-referencing findings by hand.
There is a second, quieter problem. Secrets often point to services you have not yet connected to TruffleHog. Those blind spots are where risk hides and having a comprehensive view of coverage gaps is helpful in prioritizing coverage.
Topology addresses both. It makes lateral-movement risk visible as a path you can follow, and it makes coverage gaps obvious by showing the services your secrets reach that are not being scanned.
See it in action
What's happening under the hood
Topology is derived from the same verified, deduplicated secrets that power the rest of TruffleHog Enterprise. There is no separate data source to configure.
For each secret, TruffleHog resolves the source service where it was found and the target service it grants access to. Targets are inferred from the secret type, so the graph stays current as new detectors ship without maintaining a hand-written map of secret types. Secrets are then collapsed by unique source-to-target pair, so each edge reflects a real relationship with an accurate count and type breakdown.
Services TruffleHog can scan are matched against the set of supported integrations and marked accordingly. Anything a secret points to that we do not have an integration for is still rendered as a target, so the destination stays visible even when it cannot be scanned. The graph loads progressively, streaming findings page by page so large environments render incrementally instead of blocking on one large fetch. Triage filtering is applied as the data loads, so the map reflects exactly the subset of findings you care about.
What this unlocks
Topology moves teams from a catalog of findings to reasoning about risk. In one view you can trace the blast radius of a leaked credential, prioritize the exposures that reach your most sensitive systems, and spot the scannable services you have not connected yet. That turns coverage gaps into a concrete, prioritized list. For security leaders, it is another step from reporting on what was found to reporting on risk reduction.
Shared Secrets UX Enhancements
What's new
Clicking Share on a detected secret generates a secure, time-limited link you can send to whoever needs to fix it, with access locked to people on your trusted domains and an expiration you choose, from a single read to a set number of days.
The problem we're solving
When you find a leaked secret, the person who can actually rotate it often isn't the person who leaked it, and getting the details to them safely is harder than it sounds. Pasting a credential into email or Slack just creates a second leak, and a screenshot strips away the context needed to act on it. You want the owner to see exactly what was found and where, without handing that information to anyone who happens to get the link.
What's happening under the hood
Each link is scoped to a single secret and gated behind your own login, so a recipient has to sign in with Google or SAML and match one of your trusted domains before anything loads. TruffleHog checks the link's status and the viewer's domain on every open, then shows a read-only page with the finding's details, where it was found, and rotation guidance, and never the raw secret itself.
What this unlocks
A faster, safer handoff from the person who finds a secret to the person who fixes it. Owners get the full context to act on, links expire on their own, and you can revoke every active link at once, so a shared finding never turns into a lingering exposure.
Multi-Org GitHub App Scanning
What's new
Connecting a GitHub App now lets TruffleHog Enterprise discover and scan every organization that the app is installed in, not just one. With a single connection using your app ID and private key, we automatically enumerate members and access across all of your GitHub organizations, with no need to configure each org individually or supply more than one installation ID.
The problem we're solving
Most enterprises don't live in a single GitHub organization. They have several, often behind strict security controls like IP allowlists. Getting complete visibility used to mean stitching together separate connections, and security-conscious teams frequently hit a wall. The result was partial coverage.
What's happening under the hood
TruffleHog Enterprise discovers each installation of your GitHub App and then connects to every organization using that organization's own installation token, rather than reusing one org's token everywhere. Because each request is properly scoped, it satisfies per-org IP allowlists instead of tripping them. If one organization runs into an issue, it stays isolated so scanning of the others can complete. Additionally, each failure is tracked individually so nothing gets silently missed.
What this unlocks
Complete repository coverage across your entire GitHub footprint, even for the most locked-down, multi-org enterprises. Setup gets simpler too, since a single app connection covers everything without per-org wiring. The goal is comprehensive coverage that works with your security posture.
All features are available now and included in TruffleHog Enterprise. For more information, visit trufflesecurity.com/enterprise. Or if you would like a demo of TruffleHog Enterprise, reach out to us at: https://trufflesecurity.com/contact
