Secret scanning

As a service provider, you can partner with GitHub to have your secret token formats secured through secret scanning, which searches for accidental commits of your secret format and can be sent to a service provider's verify endpoint.

In this article

GitHub scans repositories for known secret formats to prevent fraudulent use of credentials that were committed accidentally. Secret scanning happens by default on public repositories, and can be enabled on private repositories by repository administrators or organization owners. As a service provider, you can partner with GitHub so that your secret formats are included in our secret scanning.

When a match of your secret format is found in a public repository, a payload is sent to an HTTP endpoint of your choice.

When a match of your secret format is found in a private repository configured for secret scanning, then repository admins are alerted and can view and manage the secret scanning results on GitHub. For more information, see "Managing alerts from secret scanning."

Note: Secret scanning for private repositories is currently in beta.

This article describes how you can partner with GitHub as a service provider and join the secret scanning program.

The secret scanning process

How secret scanning works in a public repository

The following diagram summarizes the secret scanning process for public repositories, with any matches sent to a service provider's verify endpoint.

Flow diagram showing the process of scanning for a secret and sending matches to a service provider's verify endpoint

Joining the secret scanning program on GitHub

  1. Contact GitHub to get the process started.
  2. Identify the relevant secrets you want to scan for and create regular expressions to capture them.
  3. For secret matches found in public repositories, create a secret alert service which accepts webhooks from GitHub that contain the secret scanning message payload.
  4. Implement signature verification in your secret alert service.
  5. Implement secret revocation and user notification in your secret alert service.
  6. Provide feedback for false positives (optional).

Contact GitHub to get the process started

To get the enrollment process started, email

You will receive details on the secret scanning program, and you will need to agree to GitHub's terms of participation before proceeding.

Identify your secrets and create regular expressions

To scan for your secrets, GitHub needs the following pieces of information for each secret that you want included in the secret scanning program:

  • A unique, human readable name for the secret type. We'll use this to generate the Type value in the message payload later.
  • A regular expression which finds the secret type. Be as precise as possible, because this will reduce the number of false positives.
  • The URL of the endpoint that receives messages from GitHub. This does not have to be unique for each secret type.

Send this information to

Create a secret alert service

Create a public, internet accessible HTTP endpoint at the URL you provided to us. When a match of your regular expression is found in a public repository, GitHub will send a HTTP POST message to your endpoint.

Example POST sent to your endpoint
Host: HOST
Accept: */*
Content-Type: application/json
GITHUB-PUBLIC-KEY-IDENTIFIER: 90a421169f0a406205f1563a953312f0be898d3c7b6c06b681aa86a874555f4a
Content-Length: 0123

    "token": "X-Header-Bearer: as09dalkjasdlfkjasdf09a",
    "type": "ACompany_API_token",
    "url": ""

The message body is a JSON array that contains one or more objects with the following contents. When multiple matches are found, GitHub may send a single message with more than one secret match. Your endpoint should be able to handle requests with a large number of matches without timing out.

  • Token: The value of the secret match.
  • Type: The unique name you provided to identify your regular expression.
  • URL: The public commit URL where the match was found.

Implement signature verification in your secret alert service

We strongly recommend you implement signature validation in your secret alert service to ensure that the messages you receive are genuinely from GitHub and not malicious.

You can retrieve the GitHub secret scanning public key from and validate the message using the ECDSA-NIST-P256V1-SHA256 algorithm.

Assuming you receive the following message, the code snippets below demonstrate how you could perform signature validation. The code also assumes you've set an environment variable called GITHUB_PRODUCTION_TOKEN with a generated PAT ( The token does not need any permissions set.

Sample message sent to verify endpoint

Host: HOST
Accept: */*
content-type: application/json
GITHUB-PUBLIC-KEY-IDENTIFIER: 90a421169f0a406205f1563a953312f0be898d3c7b6c06b681aa86a874555f4a
Content-Length: 0000

[{"token": "some_token", "type": "some_type", "url": "some_url"}]

Validation sample in Go

package main

import (

func main() {
  payload := `[{"token": "some_token", "type": "some_type", "url": "some_url"}]`

  kID := "90a421169f0a406205f1563a953312f0be898d3c7b6c06b681aa86a874555f4a"

  kSig := "MEUCICxTWEpKo7BorLKutFZDS6ie+YFg6ecU7kEA6rUUSJqsAiEA9bK0Iy6vk2QpZOOg2IpBhZ3JRVdwXx1zmgmNAR7Izpc="

  // Fetch the list of GitHub Public Keys
  req, err := http.NewRequest("GET", "", nil)
  if err != nil {
    fmt.Printf("Error preparing request: %s\n", err)

  if len(os.Getenv("GITHUB_PRODUCTION_TOKEN")) == 0 {
    fmt.Println("Need to define environment variable GITHUB_PRODUCTION_TOKEN")

  req.Header.Add("Authorization", "Bearer "+os.Getenv("GITHUB_PRODUCTION_TOKEN"))

  resp, err := http.DefaultClient.Do(req)
  if err != nil {
    fmt.Printf("Error requesting GitHub signing keys: %s\n", err)

  decoder := json.NewDecoder(resp.Body)
  var keys GitHubSigningKeys
  if err := decoder.Decode(&keys); err != nil {
    fmt.Printf("Error decoding GitHub signing key request: %s\n", err)

  // Find the Key used to sign our webhook
  pubKey, err := func() (string, error) {
    for _, v := range keys.PublicKeys {
      if v.KeyIdentifier == kID {
        return v.Key, nil

    return "", errors.New("specified key was not found in GitHub key list")

  if err != nil {
    fmt.Printf("Error finding GitHub signing key: %s\n", err)

  // Decode the Public Key
  block, _ := pem.Decode([]byte(pubKey))
  if block == nil {
    fmt.Println("Error parsing PEM block with GitHub public key")

  // Create our ECDSA Public Key
  key, err := x509.ParsePKIXPublicKey(block.Bytes)
  if err != nil {
    fmt.Printf("Error parsing DER encoded public key: %s\n", err)

  // Because of documentation, we know it's a *ecdsa.PublicKey
  ecdsaKey, ok := key.(*ecdsa.PublicKey)
  if !ok {
    fmt.Println("GitHub key was not ECDSA, what are they doing?!")

  // Parse the Webhook Signature
  parsedSig := asn1Signature{}
  asnSig, err := base64.StdEncoding.DecodeString(kSig)
  if err != nil {
    fmt.Printf("unable to base64 decode signature: %s\n", err)
  rest, err := asn1.Unmarshal(asnSig, &parsedSig)
  if err != nil || len(rest) != 0 {
    fmt.Printf("Error unmarshalling asn.1 signature: %s\n", err)

  // Verify the SHA256 encoded payload against the signature with GitHub's Key
  digest := sha256.Sum256([]byte(payload))
  keyOk := ecdsa.Verify(ecdsaKey, digest[:], parsedSig.R, parsedSig.S)

  if keyOk {
    fmt.Println("THE PAYLOAD IS GOOD!!")
  } else {
    fmt.Println("the payload is invalid :(")

type GitHubSigningKeys struct {
  PublicKeys []struct {
    KeyIdentifier string `json:"key_identifier"`
    Key           string `json:"key"`
    IsCurrent     bool   `json:"is_current"`
  } `json:"public_keys"`

// asn1Signature is a struct for ASN.1 serializing/parsing signatures.
type asn1Signature struct {
  R *big.Int
  S *big.Int

Validation sample in Ruby

require 'openssl'
require 'net/http'
require 'uri'
require 'json'
require 'base64'

payload = <<-EOL
[{"token": "some_token", "type": "some_type", "url": "some_url"}]

payload = payload

signature = "MEUCICxTWEpKo7BorLKutFZDS6ie+YFg6ecU7kEA6rUUSJqsAiEA9bK0Iy6vk2QpZOOg2IpBhZ3JRVdwXx1zmgmNAR7Izpc="

key_id = "90a421169f0a406205f1563a953312f0be898d3c7b6c06b681aa86a874555f4a"

url = URI.parse('')

raise "Need to define GITHUB_PRODUCTION_TOKEN environment variable" unless ENV['GITHUB_PRODUCTION_TOKEN']
request =
request['Authorization'] = "Bearer #{ENV['GITHUB_PRODUCTION_TOKEN']}"

http =, url.port)
http.use_ssl = (url.scheme == "https")

response = http.request(request)

parsed_response = JSON.parse(response.body)

current_key_object = parsed_response["public_keys"].find { |key| key["key_identifier"] == key_id }

current_key = current_key_object["key"]

openssl_key =

puts openssl_key.verify(, Base64.decode64(signature), payload.chomp)

Implement secret revocation and user notification in your secret alert service

For secret scanning in public repositories, you can enhance your secret alert service to revoke the exposed secrets and notify the affected users. How you implement this in your secret alert service is up to you, but we recommend considering any secrets that GitHub sends you messages about as public and compromised.

Provide feedback for false positives

We collect feedback on the validity of the detected individual secrets in partner responses. If you wish to take part, email us at

When we report secrets to you, we send a JSON array with each element containing the token, type identifier, and commit URL. When you send us feedback, you send us information about whether the detected token was a real or false credential. We accept feedback in the following formats.

You can send us the raw token:

    "token_raw": "The raw token",
    "token_type": "ACompany_API_token",
    "label": "true_positive"

You may also provide the token in hashed form after performing a one way cryptographic hash of the raw token using SHA-256:

    "token_hash": "The SHA-256 hashed form of the raw token",
    "token_type": "ACompany_API_token",
    "label": "false_positive"

A few important points:

  • You should only send us either the raw form of the token ("token_raw"), or the hashed form ("token_hash"), but not both.
  • For the hashed form of the raw token, you can only use SHA-256 to hash the token, not any other hashing algorithm.
  • The label indicates whether the token is a true ("true_positive") or a false positive ("false_positive"). Only these two lowercased literal strings are allowed.

Note: Our request timeout is set to be higher (that is, 30 seconds) for partners who provide data about false positives. If you require a timeout higher than 30 seconds, email us at

Did this doc help you?

Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

Or, learn how to contribute.