Beyond Infrastructure: How HailBytes ASM Monitors Public GitHub for Exposed Secrets

Most external attack surface management answers one question: what of mine is exposed on the internet? HailBytes ASM’s commit-stream monitoring answers a different one: is anyone publishing my secrets to the internet right now? A developer pushes a .env file or an API key to a public repository, realizes the mistake three hours later, and rotates the credential — but automated harvesters watching the same public feed got there first. This is a continuous, real-time axis of risk that point-in-time infrastructure scanning never touches, and it now runs inside the same platform as the rest of your attack surface.

The Attack Scenario

The leak itself is mundane: a hard-coded cloud key in a commit, a config file that should have been git-ignored, a token pasted into a test fixture. What makes it dangerous is the audience. GitHub publishes a public /events firehose, and threat actors run automated tooling against it precisely because freshly-committed secrets are valid secrets — the window between push and rotation is the window of maximum value. Defenders who only scan their own repositories on a schedule are racing the same clock from behind. The detection has to be continuous and fast, or it is mostly archaeology.

How the Detection Works

HailBytes ASM runs a bounded cron on a five-minute cadence that does three things:

1. Watch the firehose, filtered to you. It polls GitHub’s public events API for PushEvent commits whose message, repository, or author email matches per-Organization keyword filters — your apex domain, brand names, and internal service identifiers. That filter is what turns an unmanageable global stream into the handful of commits that might actually be yours.

2. Confirm with trufflehog. Matched commits are piped through trufflehog for high-confidence secret detection. Keyword matching finds commits that are plausibly relevant; trufflehog confirms whether they actually contain a live credential, which keeps the signal-to-noise ratio where an on-call engineer can trust it.

3. Raise a Critical finding — without re-leaking. Confirmed hits persist as Vulnerability rows with type “Exposed Secret in Public Commit,” severity Critical, and evidence containing the commit URL and the detector name(s). The raw secret value is deliberately omitted from the finding, so the detection record itself never becomes a second copy of the exposure.

Bounded by Design

Watching a public firehose could easily turn into an unbounded, expensive job, so the feature is constrained on purpose: a hard cap of ten pages (roughly a thousand events) per run, a cutoff once events drift older than the five-minute window, a per-commit trufflehog timeout, and deduplication keyed on commit URL so the same commit never produces two findings. Those bounds matter for more than cost — they make the capability predictable enough to run continuously in a compliance-sensitive environment, and they keep it from competing for resources with your scheduled scans. It is per-Organization opt-in via CommitStreamConfig and off by default.

Why It Matters for MSSPs and Enterprises

For an MSSP managing software companies or financial-services clients, this is exactly the failure mode that keeps customers up at night — and having the detection wired into the same platform as external scanning makes it a compelling bundled value proposition rather than yet another point tool to integrate. Because the output is a Critical-severity Vulnerability row, it routes straight into the SIEM, ticketing, and on-call dispatchers you already run, so a leaked credential becomes a page within minutes of the push instead of a line item in next quarter’s pentest report.