An organization's core credentials sat in public repositories for years. The security industry's answer: "Out of scope." Two Keys, Two Programs, Zero Accountability A security research team discovered two API keys, Admin-level or functionally equivalent in blast radius, sitting in public GitHub repositories. Not buried in obscure corners of the internet. Plain text, accessible to anyone with a browser. The problem is what happened after the disclosures. First key: Slack Bot Token (3 years of exposure) A Slack Bot Token had been sitting in a public GitHub repository for three years. Slack is no longer a messenger in any meaningful sense. Strategy discussions, HR conversations, customer data, and technical infrastructure information flow in real time across hundreds of channels. Based on the granted scopes, the token allowed broad access: channel message reading, file downloads, user directory enumeration, and more. The more serious concern is lateral movement. Channels routinely carry credentials for other services. Messages along the lines of "staging server access info" or "sharing the AWS key" survive in pinned messages, DMs, and private channels at more organizations than anyone would admit. Bots and webhook integrations wire Slack into dozens of services, including CI/CD pipelines, Jira, GitHub, and monitoring systems. Slack Connect channels can even expose partner organization data. A single Bot Token effectively provides a map of an organization's entire technology stack. The research team reported the finding through the organization's official bug bounty program. The classification that came back: "Out of scope." The core contradiction is unavoidable. An API key is a company asset. The entire purpose of a bug bounty program is to protect those assets. Vulnerabilities matter because they enable unauthorized access to corporate assets. Classifying a publicly exposed key that grants direct access to those same assets as "out of scope" contradicts the program's reason for existing. Second key: Asana Admin API Key (2 years of exposure) This key originated from a previously independent organization that had since been consolidated. The important detail is that the parent organization was actively using the Asana workspace tied to this key after consolidation. It was not a neglected relic. It was active infrastructure carrying project timelines, task assignments, and strategic documents. The key was exposed in a public GitHub repository for two years and carried full read/write permissions across every project in the workspace. This was also reported through the official bug bounty program. The classification, again: "Out of scope." The rationale: the asset originated from a separate entity, so it falls outside program boundaries. Actively used and managed, yet the security responsibility is declared out of scope. The blind spot "Out of scope" creates What both cases share is that the organizations do not treat their own credential exposures as managed risk, and "Out of scope" is the classification that formalizes that blind spot. The irony: both organizations classified these findings as "Out of scope" yet took action anyway. They revoked the keys and rotated them. One organization explicitly stated in its response that, based on the disclosure, it had conducted a broader review and remediated additional cases. The risk was acknowledged, the value of the disclosure was leveraged, and yet the official classification remained "Out of scope." Out-of-scope action for what is allegedly an out-of-scope finding. This contradiction is the clearest window into what is broken. These two cases are representative examples from dozens of similar NHI exposure findings. The same pattern repeats every time. Reports are dismissed, and critical access is handled as "Out of scope." Case after case, one conclusion became inescapable: the bug bounty credential-exposure handling model itself is broken. Why This Keeps Happening The repetition is structural. The design assumptions behind bug bounty programs and the nature of credential exposure as a threat are fundamentally misaligned. This is not a theoretical risk. Toyota exposed an access key in a public GitHub repository for roughly five years, leading to 296,019 customer email addresses and customer IDs being exposed in 2022. Uber's 2016 breach affecting 57 million users also originated from hardcoded AWS credentials in a GitHub repository. According to GitGuardian's 2025 report, 23.8 million secrets were detected on public GitHub in 2024 alone, a 25% increase year over year. The scale of the problem is accelerating, not shrinking. Scope shield — credential exposure outside bug bounty scope Asset Exposure Is Not a Program Bug Bug bounty programs were designed to find "program vulnerabilities," meaning bugs. RCE, SQL injection, XSS, and other code-level flaws get reported, receive severity ratings based on potential impact, and are rewarded accordingly. CVSS underpins this m...