Secret scanning coverage updates

GitHub expanded secret scanning coverage in a changelog release that blocks more secrets via push protection, adds one new secret scanning partner, and ships richer metadata on alerts. The update sits under GitHub’s secret scanning partnership program, where Lovable Labs is the new partner named in the announcement.

On the product side, the change tightens the scan-and-block path at push time: push protection now covers a wider set of secret patterns so more credential-like strings are stopped before they land in a remote. Alert payloads gain richer metadata, which should make triage less of a guess when an alert fires—context that helps map a hit to issuer, type, or other fields the scanner can attach without requiring a separate lookup.

For engineers and builders, the practical effect is fewer accidental commits of partner-issued tokens and clearer signal when something does slip into an alert. Teams that already run push protection get a broader net without changing repo layout; teams that rely on post-commit alerts get denser fields on each finding, which shortens the path from “secret detected” to revoke-or-rotate.

In market terms, this is GitHub deepening its secret-scanning partnership model rather than shipping a brand-new scanner: coverage grows by onboarding partners (here, Lovable Labs) and by expanding what push protection will refuse, which keeps scanning competitive with other VCS and AppSec tools that sell credential detection as a default control.

Watch for how the new partner’s secret types show up in your org’s alert volume and whether the richer metadata fields are enough to drive automated routing into your existing incident or secrets-rotation workflows; if you run push protection, confirm the expanded block list does not need policy or allowlist tweaks for any legitimate CI secrets you still push by design.