The Enterprise Security Gap Hiding in Plain Sight
Most organizations with a mature security program have a threat intelligence function. They subscribe to commercial feeds. They have Security Information and Event Management (SIEM) integrations pulling in Indicators of Compromise (IOCs). Some run dedicated threat intelligence platforms. A subset have full threat intelligence teams doing adversary tracking and campaign analysis. By conventional measures, they are covered.
And yet, when we run Exploit Shield across Fortune 500 companies and mid-market organizations alike, we find live exposures in nearly every sector. Valid credentials sitting in public repositories, production API keys exposed in Postman workspaces, internal configuration files indexed in GitHub for months or years. Secrets that threat actors could have been using the entire time.
The organizations we find these in are not unsophisticated. Many have significant security investments, dedicated teams, and programs that check every conventional box. The exposure exists anyway, because the threat intelligence discipline has a structural blind spot, and almost no one has built a program specifically designed to address it.
What Threat Intelligence Programs Are Actually Designed to Do
To understand the gap, it helps to be honest about what conventional threat intelligence is built for and what it is not.
Commercial threat intelligence feeds are fundamentally reactive and indicator-focused. They collect data about known bad actors: IP addresses, domains, file hashes, malware signatures. They distribute that data so defenders can block or detect activity associated with those indicators. This model is useful for catching known threats that behave in predictable ways. It is not designed to catch exposure of your own data that has not yet been weaponized.
Dark web monitoring has become a standard offering. Organizations pay for alerts when their data surfaces on criminal forums, paste sites, or illicit marketplaces. This sounds like it addresses the problem, but it does not. By the time credentials or secrets appear on a dark web forum for sale, they have already been exfiltrated, likely already used, and possibly already the subject of an undiscovered breach. Dark web monitoring catches the residue of exploitation, not the initial exposure.
Attack Surface Management (ASM) tools try to enumerate what an organization has exposed to the internet: open ports, certificate transparency data, misconfigured storage buckets, exposed panels. These are legitimate and valuable. But ASM operates on infrastructure the organization controls. It does not monitor the developer ecosystem that exists outside organizational boundaries.
The gap nobody is watching sits in the middle: the public developer platforms where organizational secrets escape quietly, with no alert, no ticket, and no one looking.
Why This Keeps Getting Missed
When we explain this problem to security leaders, the reaction is often some version of "We have GitHub Advanced Security" or "Our developers know not to commit secrets." Both of those statements can be true simultaneously with live exposure in the wild.
Native platform controls have a jurisdictional problem. GitHub's built-in secret scanning works on repositories within the organization's GitHub organization. It does not monitor personal repositories belonging to employees or contractors. It does not monitor forks of organizational repositories that now live under personal accounts. When a developer copies a work script to their personal GitHub for reference, that repository is outside the platform's administrative scope, and any secrets it contains are invisible to the organization's tooling.
Postman is a persistent and undermonitored surface. It has become a significant exposure vector that receives almost no attention from existing threat intelligence tooling. In one engagement, a contractor's public Postman workspace exposed application client IDs and client secrets tied to production APIs. These are not traditional passwords. In Open Authorization (OAuth) and OpenID Connect (OIDC) flows, exposed client credentials allow an attacker to impersonate the application itself. The resulting access is long-lived, trusted, and difficult to distinguish from legitimate traffic.
Git history outlasts security awareness. When a developer commits a secret, realizes the mistake, and immediately pushes a fix, the original commit remains in repository history. A credential that was removed from a repository two years ago is still in the commit log. The developer believes the problem was addressed. The credential may still be valid.
The source of the leak is almost never a threat actor. Across over a year of research, the leaks we encounter most often come from long-tenured staff, former employees, and contractors. People using personal resources to escape restrictive corporate environments, stashing notes while preparing to leave an organization, or simply setting a sensitive repository public by accident. Most commit authors have Gmail addresses. These cases fall entirely outside corporate monitoring tools. They are the unknown-unknowns.
A Real Example: One Repository, 23 Financial Institutions
The clearest illustration of this problem is not hypothetical. It is something we found in the course of monitoring GitHub for a credit union client.
Exploit Shield flagged a .properties file that appeared to contain core banking credentials. The filename matched the credit union's naming convention. But when we looked closer, it was not just one file for one institution. In the same directory were 23 nearly identical configuration files, each named for a different financial institution.
The contents were not placeholders. They included hard-coded credentials tied to core banking systems like Symitar and Fiserv DNA, alongside API keys used to connect to Visa and Mastercard payment processors. The repository belonged to a shared technology vendor, an integration layer used by dozens of financial institutions as a gateway to the payment networks.
The repository had been public from May 2022 to February 2025. During that time, none of the 23 credit unions detected it. Visa and Mastercard did not detect it. Bug bounty programs did not report it. The vendor itself was unaware.
We eventually reached the Chief Technology Officer (CTO), who also served as head of cybersecurity, by calling the vendor's sales line after emails went unanswered. The reaction was immediate: "Holy s**, that's all of our code. That's not supposed to be public."* Within an hour, the repository was taken down.
Every one of those 23 institutions had a security program. Several had recently completed penetration tests. None of them detected the exposure, because it did not exist on their infrastructure, it did not exist in any monitored source control environment, and it had never appeared on a dark web forum. By every conventional measure, they were covered.
The Same Pattern Repeats Across Industries
The financial services case is dramatic in scale, but the underlying pattern is not unusual.
In a penetration test for a large healthcare organization, Open Source Intelligence (OSINT) surfaced a public repository tied to a long-tenured employee, a personal archive spanning roughly two decades of work. Inside were scripts, documentation, and spreadsheets containing plaintext credentials accumulated over years: domain administrator credentials with unrestricted control, Virtual Private Network (VPN)-capable user credentials, service account credentials used for integrations, and data center backup credentials accessing production data. The repository had been public for more than four months. No internal alerting triggered.
Looking at another engagement, OSINT reconnaissance surfaced a public repository referencing an in-scope File Transfer Protocol (FTP) server with valid credentials. The notes appeared to belong to a contractor's generalized work archive spanning multiple organizations. The repository had been public for more than a year. Internal monitoring never detected it because the artifact lived outside corporate identity, source control, and logging. No exploitation was required. The access path already existed.
In the manufacturing sector, we identified a public GitHub repository belonging to a Fortune 500 automotive company that contained years of sensitive research, development data, and confidential intellectual property tied to an autonomous driving program. The exposure created ransomware leverage, trade secret risk, and the potential to accelerate a competitor's research and development (R&D), all from a single repository nobody was watching.
Across all of these cases, the failure was not technical sophistication. It was a lack of awareness that the exposure existed at all.
The Third-Party Vendor Problem Is Bigger Than Your Security Program Accounts For
The credit union case illustrates something the industry systematically underestimates: the exposure surface created by your vendor ecosystem is often larger than the surface you directly control, and it is almost entirely outside the scope of standard threat intelligence programs.
Every organization operates inside a web of third-party vendors. Core platforms, managed service providers, Software as a Service (SaaS) integrations, staffing contractors, implementation partners. Each of those relationships represents a channel through which organizational credentials, configuration data, and infrastructure details can escape into public developer platforms without any action by anyone inside the organization.
This is not a vendor management problem in the traditional third-party risk sense. Questionnaires and audits do not catch a developer accidentally pushing a public repository. Third-party vendor questionnaires rarely ask where source code is stored, whether production secrets are hard-coded, or whether public repositories are actively monitored. Continuous monitoring catches it, but only if the monitoring scope includes vendor domains, not just your own.
The relevant question for any mature program is not just whether your credentials escaped. It is whether any credential that can reach your environment escaped from anywhere in the vendor ecosystem. Those are meaningfully different scopes, and the second one is the one conventional programs miss.
What Effective Detection Actually Requires
Detecting exposure in the developer ecosystem is a different problem than traditional threat intelligence collection, and it requires a different approach.
First, it starts with organizational context. Generic pattern matching against known credential formats produces enormous false positive volume. Effective detection requires knowing what is specific to a given organization: the domain names and subdomains they use, the internal naming conventions developers follow, the credential prefixes for the services they rely on, the GitHub and GitLab account names associated with employees and contractors. Without that context, the signal-to-noise ratio makes the program operationally unworkable.
This extends to the supply chain. Monitoring needs to encompass the domains and identifiers of third-party vendors who have access to organizational systems. These are meaningfully different scopes, and the second one is the one conventional programs miss.
Additionally, it requires coverage across platforms that traditional tooling ignores. GitHub gets the most attention, but Postman is equally significant. Commit histories need to be evaluated, not just current repository state. Personal accounts associated with employees and contractors need to be in scope.
And it requires human triage. A tool can return a string that matches a credential pattern. It cannot determine whether the credential is still valid, whether it has already been exploited, what it accesses if used, or how it got there. Without that analytical layer, the detection capability generates noise rather than intelligence.
There is also a meaningful distinction between point-in-time OSINT and continuous monitoring. A snapshot shows what exists now. Continuous monitoring shows what appears, changes, and persists. In one engagement, a credit union operating under a continuous monitoring agreement had passed a clean initial penetration test with no public credentials identified. Several months later, continuous monitoring surfaced a public repository tied to a legacy domain, exposed for years, containing application secrets and credentials originating from a third-party contractor. The original test was not wrong. It simply could not detect exposure the organization did not yet know to look for.
The Coverage Assumption Is Wrong
The organizations finding live exposure in our assessments did not have weak security programs. They had programs designed around a threat model that does not account for developer ecosystem exposure.
GitHub Advanced Security covers organizational repositories. It does not cover personal accounts. Dark web monitoring catches exploited credentials after the fact. It does not catch live secrets before they are used. Commercial threat intelligence feeds track adversary infrastructure. They do not monitor public developer platforms for organizational credential exposure. Penetration testing evaluates authorized systems at a moment in time. Public exposure often exists outside those boundaries and can persist for years unnoticed.
Every mature security program should treat three things as non-negotiable: continuous OSINT monitoring tied to the organization's brand, vendors, and known developer identifiers; a public vulnerability disclosure intake (security.txt or a formal Vulnerability Disclosure Program) that actually reaches security staff; and penetration testing scope that explicitly includes OSINT discovery rather than treating it as optional.
Without these, organizations will continue to pass audits and complete penetration tests while carrying exposed credentials in plain sight, not because attackers did something clever, but because no one was looking at the right places.
The gap is real, it is consistent across every industry we work in, and it is almost always populated when someone looks. The question for any security program is not whether this exposure exists. It is whether anyone is watching for it before someone else finds it first.
