Manage detector definitions as reviewed configuration, but keep dry runs and publishing in the UI until GitHub exposes those steps safely through the API.
GitHub security teams can now manage secret scanning custom patterns through generally available REST endpoints. The API covers listing, creation, modification, and deletion at repository, organization, and enterprise scope.
Custom patterns are useful for credentials that belong to an internal service or a vendor pattern GitHub does not detect by default. The API makes those definitions easier to standardize, but it also makes a bad detector easier to distribute.
What is—and is not—automated
The available endpoints provide the basic CRUD lifecycle for custom patterns. GitHub says dry runs and final publishing still happen in the web interface. That boundary is helpful: a team can automate inventory and draft changes while retaining a human checkpoint before a noisy pattern becomes active.
The API is available to secret scanning customers at all three management levels. Access tokens should receive only the scope needed for the chosen level.
Treat patterns like production rules
Store the intended token format, examples that must match, examples that must not match, owner, affected services, and last review date. Test against representative history before publishing. A pattern that matches too broadly can bury real exposures in alert noise; one that is too narrow creates false confidence.
Changes should go through review because deletion or weakening can reduce coverage across many repositories at once.
A practical automation boundary
Use the API to detect configuration drift, prepare new definitions, and report coverage. Keep dry-run result review and publication as an explicit security task. Log who requested the rule, who approved it, and which repositories were tested before enterprise-wide rollout.
PatchMemo independently selects and evaluates the topics it covers. We clearly label sponsorships and affiliate relationships.
