Secret scanning custom patterns get a REST API, so you can PR your detectors

The last time I added a custom secret detector at work, I did it in the org settings tab at eight in the evening, alone with a wizard nobody had ever code-reviewed. Two months later I could not tell you whether the regex I had typed into that box was still the regex running against pushes. That is the flow-killer GitHub's July 13 changelog quietly closes.

What actually shipped

GitHub made a set of REST endpoints for secret scanning custom patterns generally available. According to the changelog, security teams can now list, create, update and delete patterns through the API. The four endpoints named in the post:

• GET /.../secret-scanning/custom-patterns: list patterns for the given scope.
• POST /.../secret-scanning/custom-patterns: create a new pattern.
• PATCH /.../secret-scanning/custom-patterns/{id}: update an existing one.
• DELETE /.../secret-scanning/custom-patterns: remove one.

The changelog notes the endpoints are available at repository, organization and enterprise levels for secret scanning customers. One important caveat, called out in the post itself: dry runs and the final publishing step are still currently completed in the UI.

The missing piece for anyone with more than one repo

For anyone who has tried to run custom detectors seriously across an org, the story until now has been the same. You wrote a regex in a settings dialog. Somebody else edited it later, maybe. The audit trail was whatever the platform logged, if you knew where to look. And if you had thirty repos that all needed the same detector, you clicked thirty times.

Detectors-as-code fixes the shape of that. When the pattern lives in a file, it gets a diff, a PR reviewer, and a git blame. If the regex starts producing noise after a merge, you can trace which commit did it. If a colleague tightens the pattern in a hurry, the change lands in review before it lands in production.

That is a genuinely different day. The regex is a piece of code now, and code carries all the ceremony you already trust: review, revert, tag, roll back.

Wiring it into a pipeline

Because the endpoints are plain HTTP, the recipe is short. Store your patterns as JSON in a directory like .github/secret-patterns/. In a scheduled workflow, diff the checked-in files against the live patterns returned by GET, then reconcile: POST the new ones, PATCH the changed ones, DELETE what has been removed.

A rough sketch of the reconcile step in a workflow file:

- name: reconcile-secret-patterns
  env:
    GH_TOKEN: ${{ secrets.GH_ADMIN_TOKEN }}
  run: |
    for file in .github/secret-patterns/*.json; do
      gh api \
        --method POST \
        "/orgs/$ORG/secret-scanning/custom-patterns" \
        --input "$file"
    done

Use placeholder values for $ORG and the admin token; the exact request body is defined in the endpoint reference, and you will want a real diff tool instead of the blind POST loop above. The point of the example is that the loop is now writable at all.

The rough edge I keep hitting

Dry runs and the final publish step still live in the UI. That is not a small footnote. Dry-running a new detector against your commit history is the step that catches the regex that would have alerted on every past commit for a year. Keeping it click-only means your automation can prepare a pattern, but a human still has to open the browser, click through the dry run, eyeball the noise, and click publish. You can automate the git side of detector management. You cannot yet automate the safety belt.

That is worth knowing before you promise the security team a fully hands-off rollout.

Where I would use it tomorrow

An internal secret shape, say the token format your services use to call each other, is the obvious first pattern to move into a repo. It changes rarely, but when it changes you want the change reviewed. A shared config directory that syncs the same pattern to twenty microservice repos is worth the afternoon it takes to wire up.

What I am watching next: whether the dry-run and publish steps join the API, and whether the pattern object grows fields for the current UI-only knobs. Until then, the promise of detectors-as-code is real, and one arm of it is still tied behind the browser.