This is the first in our “Bring Your Own Source” series, where we explore practical, real-world ways to extend secrets detection far beyond traditional code repositories.

It's an uncomfortable truth that every security professional needs to face: secrets no longer reside solely in code repositories.

This shift didn't happen overnight. While we at GitGuardian started by scanning your GitHub repos and GitLab instances (and rightfully so), your secrets have been quietly migrating to every corner of the digital workplace. They're living in Slack channels where developers share "quick fixes." They're documented in Confluence pages for team onboarding. They're embedded in Docker images, scattered across Jira tickets, and yes, even hiding in CI/CD logs that nobody thinks to check.

Source Breakdown by Category and Type

The numbers don't lie: our data shows that beyond the 600+ million secrets detected in code repositories, we've uncovered nearly 50 million additional secrets across other data sources—196K in container registries, 28M in messaging platforms, 13M in documentation, and 10M in ticketing systems. Organizations that expand their secrets detection beyond traditional code repositories are discovering a massive hidden attack surface they never knew existed.

Where Secrets Live in 2025

Let me walk you through the modern secrets landscape, and trust me, it's more sprawling than you think.

The obvious suspects include the sources we've all learned to monitor:

  • Source code repositories (the ones we all know about)
  • CI/CD pipeline configurations and logs
  • Container images and deployment artifacts (GitGuardian uncovered over 100,000 valid secrets leaked on public Docker infrastructure)

But then there are the hidden culprits, the places where secrets lurk undetected:

  • Chat platforms where "temporary" credentials become permanent
  • Documentation wikis with helpful "getting started" examples
  • Issue trackers filled with debugging information
  • Project management tools with configuration snippets
  • File storage systems with "backup" credential files
  • Infrastructure configurations that seemed secure at the time

The problem isn't that developers are being careless (well, not entirely). It's that our modern development workflow naturally creates these touchpoints. When you're troubleshooting a production issue at 2 AM, that Slack channel becomes your lifeline. When you're onboarding new team members, that Confluence page with "everything you need to know" seems like a godsend.

Unfortunately, these convenient workflows often become security vulnerabilities in disguise.

The Real Cost of Blind Spots

We've seen organizations learn this lesson the hard way. Here are some real scenarios that keep security leaders up at night:

A startup documented its API keys in a Confluence page to help new developers get up to speed quickly. Six months later, when they made their documentation more accessible by adjusting permissions, those keys ended up visible to a much broader audience, including a competitor who noticed the oversight.

A development team hardcoded database credentials in a Docker image during a tight deadline. The image made its way to a public registry, where automated scanners found and exploited it within hours. The result was a complete infrastructure compromise that took 72 hours to resolve fully.

During a critical bug fix, a senior developer shared temporary database access credentials in a private Slack channel. Those "temporary" credentials were never rotated, and six months later, a contractor with channel access used them to access production data.

Each of these scenarios represents millions in potential damages, not to mention the immeasurable cost to customer trust and brand reputation. Remember Uber's breach, where compromised Slack credentials enabled attackers to access multiple internal systems?

Our data shows that remediation for secrets found in messaging and ticketing platforms is the slowest, with median TTR values spiking to over 120 days.

Median Time to Remediate (TTR) by Source Category

Organizations are treating these secret exposures with less urgency, which creates long-term risk exposure that attackers can exploit.

GitGuardian's Two-Tiered Strategy

GitGuardian has a two-tiered strategy that balances immediate value with unlimited flexibility:

Tier 1: Secure Your Core Sources Instantly

For the most common and business-critical sources, GitGuardian provides battle-tested native integrations that you can set up in minutes:

  • All the major VCS platforms (GitHub, GitLab, Bitbucket, Azure DevOps)
  • Communication tools (Slack, Microsoft Teams)
  • Documentation platforms (Confluence, various wikis)
  • Container registries (Docker Hub, AWS ECR, Azure Container Registry)
  • Project management tools (Jira, various ticketing systems)
Total Monitored Sources by Type

The adoption data tells an impressive story: while code repositories lead with 366K monitored sources, we're seeing explosive growth in other categories—120K messaging sources, 25K documentation sources, and 24K ticketing sources. This isn't just theoretical; organizations are actively expanding their monitoring perimeter and discovering real security value.

These aren't afterthoughts. These are enterprise-grade integrations—fast to deploy, and built with error handling, rate limiting, and all the features needed to run in production from day one. What's more, GitGuardian has expanded its detection capabilities to cover both SaaS and self-hosted versions of these platforms, ensuring comprehensive coverage regardless of your infrastructure choices.

Tier 2: Now, Bring Your Own Source

This is where GitGuardian's approach gets interesting. We've built the "Bring Your Own Source" initiative, essentially turning our world-class secrets detection engine into a universal scanner that can work with any data source - giving you the power to discover and secure secrets wherever they leak.

The flexibility is remarkable. You can feed the detection engine anything from a simple JSON document to complex data structures with full author attribution and metadata. It's designed to be easy to plug in and start scanning, with no complex engineering required.

Got an internal tool that stores configuration data? A custom chat platform? Legacy systems with their data formats? No problem. 

Let me show you just how easy this can be with a practical example.

Real-World Integration: GH issues with n8n

What’s n8n (and why use it)?

n8n (and similar tools like Tines) are powerful workflow automation platforms. They let you connect your favorite apps and automate complex tasks using an intuitive drag-and-drop editor. This means anyone can build robust automations across their stack, saving time and reducing repetitive work. For this demo, we’ll work with n8n.

Setting Up the Integration

  1. Create a Custom Source in GitGuardian
    Head to your GitGuardian dashboard, then navigate to:
    Settings > Integrations > Sources > Custom Sources.
    Give your source a clear name and description. Once saved, note the generated UUID—you’ll need it soon.
  2. Set Up Authentication
    Create a service account in GitGuardian with the permissions scan:create-incidents and scan. Name it something recognizable (e.g., n8n-testing-custom-sources). In n8n, set up a Header Auth credential with:
    • Header Name: Authorization
    • Value: Token <GG_TOKEN_VALUE> (replace with your GitGuardian token)
  3. Trigger the Workflow with a GitHub Webhook
    In n8n, add a Webhook node as the trigger. Copy the test URL, then navigate to your GitHub repository’s settings. Under Webhooks, add the n8n URL and set it to trigger on “Issues” events.
  4. Send Issues to GitGuardian’s API
    Add an HTTP node in n8n. Configure it to send a POST request to https://api.gitguardian.com/v1/scan/create-incidents using your Header Auth credentials. For the request body (JSON), use:
{
  "source_uuid": "my_source",
  "documents": [
    {
      "document_id": "{{ $json.body.issue.url }}",
      "document": {{ JSON.stringify($json.body.issue.body) }}
    }
  ]
}
  1. (Replace "my_source" with your actual UUID)
  2. Test Your Workflow
    Click “Execute workflow” in n8n, then create an issue in your GitHub repo—try including a mock secret like token=glpat-irXkcx-6XT7ChgyKvrFs. Seconds later, you should see a security incident pop up in your GitGuardian dashboard!
  3. Go Live
    Activate the workflow. Now, every new GitHub issue is scanned in real time. You can track executions in n8n’s “Executions” tab.

Pro Tips

  • This setup is just the beginning! You can expand it to scan more events, like comments or pull requests, or even roll it out org-wide.
  • For historical scans (older issues), consider a one-off script to fetch and scan past data.
🚀
The entire setup takes less than 30 minutes, and suddenly, you have real-time secrets detection running on a completely new data source. This demonstrates the power and simplicity of the "Bring Your Own Source" approach. It's not about complex engineering projects, but rather smart integrations that provide immediate security value.

Why This Matters More Than You Think

The benefits go way beyond just finding more secrets (though that's certainly valuable). When you expand your detection perimeter, you're fundamentally changing your security posture in several key ways :

Complete attack surface visibility: You can't protect what you can't see. Comprehensive scanning gives you full visibility of all occurrences of a secret across your organization and provides global secret observability. This holistic view is crucial for understanding your true risk exposure.

Proactive threat detection: Instead of waiting for breaches to reveal your blind spots, you're actively hunting for problems before they become incidents. This shift from reactive to proactive security can mean the difference between a minor remediation effort and a major breach response.

Cultural transformation: When developers see security incidents flagged in their natural workflows, whether that's Slack, Jira, or documentation tools, they naturally become more conscious about hardcoding secrets in those environments. Security becomes part of their daily routine rather than an afterthought.

Compliance made simple: Many regulatory frameworks require comprehensive data protection. Having visibility across all your data sources makes compliance audits significantly less painful and demonstrates due diligence to auditors and stakeholders.

AI Training data protection: As organizations feed internal documentation to AI models, secrets in docs become training data contamination. Our initiative helps you clean your data before it trains your AI, preventing a completely new class of exposure.

These benefits compound over time, creating a security culture where secrets protection becomes embedded in every aspect of your development and collaboration workflows.

Your Next Steps

If you're ready to expand your secrets detection beyond traditional code repositories, here's my recommendation:

Start small, think big: Begin with one or two native integrations for your highest-risk data sources. Slack is often a good starting point because it's where a lot of informal information sharing happens. Once you see the immediate value, you can start experimenting with custom sources like the GitHub Issues example we walked through.

Measure and learn: Track what you find. You'll likely be surprised by both the volume and variety of exposed secrets in non-code sources. This data becomes powerful ammunition for expanding your program and securing additional resources.

Build momentum: Use your early wins to justify expanding the program. When you can show concrete examples of secrets that would have been missed by traditional scanning, especially high-impact credentials found in collaboration tools, the business case becomes compelling and almost impossible to ignore.

Share and collaborate: The security community benefits when we share our approaches and lessons learned. Consider contributing integration patterns or examples that could help others. The more we collectively raise the bar on secret security, the safer we all become.

The Bottom Line

Today, the development environment is interconnected, secrets live everywhere, and your security strategy needs to account for that reality. The traditional approach of focusing solely on code repositories is no longer sufficient. It's like locking the front door while leaving all the windows wide open.

The tools to address this challenge comprehensively already exist. GitGuardian's "Bring Your Own Source" initiative gives you the flexibility to monitor any data source where secrets might hide, from native integrations that work out of the box to custom solutions you can build in minutes.

Your secrets are out there, hiding in plain sight across your digital infrastructure. Attackers are already looking for your secrets. The only question is whether you'll find them first or let them find you.

Ready to discover what secrets are hiding in your organization's collaboration tools? It's time to bring your own sources to the secrets detection game.