Exercise: Introduction to Secret Scanning

[github-actions[bot]]

Introduction to Secret Scanning

👋 Hey there fedriactiv8! Welcome to your Skills exercise!

In this exercise, you'll learn how to identify and protect sensitive information in your repositories. 🔍 Let's work together to keep your code secure! 🛡️

As you complete each step, I will respond in the comments to:

• check your work and give feedback
• share next steps
• occasionally share tips
• congratulate you when you finish!

Good luck and have fun! - Mona

[github-actions[bot]]

Step 1: Enable Secret Protection

If you check your email, you probably just got an alert from GitHub with the subject "Possible valid secrets found". Oh no! 😮

Don't worry! We put some expired credentials in the exercise on purpose since public repositories get secret protection for free. Nice! 🕵️

In this step, you will enable secret protection on your repository. After it is enabled, you will add a new credential to see how secret protection identifies the credential and alerts you.

[!WARNING] If your repository is private, you will need GitHub Advanced Security to continue. We recommend changing this exercise repository to public to enable it.

What is a secret?

In the our context, a secret (or credential) is a plain-text string, or a pair of strings, that authorizes access a service. Examples could be AWS secret access keys/ID's, Google API keys, or GitHub Personal Access Tokens (PATs).

The GitHub Docs provides a list of all supported patterns.

What is secret protection?

Secret protection is a powerful tool which allows teams to identify these plain-text credentials, remove them, and create rules to prevent them from being written to GitHub in the first place.

Secret protection is available for free for public repositories on all plans. Enterprises that need secret protection capabilities for private repositories should review GitHub Advanced Security. Not only does it include secret protection, it also provides advanced static analysis, composition, analysis, and enterprise tools to manage your entire AppSec pipeline and reduce your risk profile.

:keyboard: Activity: Configure secret protection

1. In the header of your repository, open Settings in a new browser tab.

2. In the left navigation, under the Security section, select Code Security.

3. Scroll down past the Code Scanning and Dependabot sections until you find the Secret Protection section.

   💡 Tip: We also have exercises about code scanning and supply chain protection!

4. Adjust the default configuration to match the below.

   • Secret Protection: enabled
   • Push Protection: disabled
   

:keyboard: Activity: Commit a sensitive file

Now let's (accidentally) commit a sensitive file to see how it works. Don't worry, these are inactive credentials.

1. In the header of your repository, click the Code tab.

2. Above the list of files, click the Add file dropdown and select Create new file.

   

3. Enter the file name credentials.yml and copy following inactive example credentials into it.

   

   default:
    aws_access_key_id: AKIAQYLPMN5HNM4OZ56B
    aws_secret_access_key: Rm29CHLQCeaT6V/Rsw3UFWW1/UWQ0lhsWBa3bdca
    mongodb: mongodb+srv://svc-admin:kLeioeBne5lsopPf@mergington-high.avocado.mongodb.net
    output: json
    region: us-east-2

4. In the top right, use the Commit changes... button to commit directly to the main branch.

   ❗️ Important: Committing to your default branch is not usually a recommended practice. We only do this to simplify the exercise.

5. With our credentials file (accidentally) shared, Mona should quickly notice it and prepare the next step.

[github-actions[bot]]

Nice! Looks like you are making progress.
Let's see if I have some feedback for you... 🧐

[github-actions[bot]]

Great job configuring secret protection! 🎉 Now let's take a look at some of the alerts that got created.

[github-actions[bot]]

🎉🎉🎉 Nice work! Everything is perfect! 🎉🎉🎉
Preparing content for step 2! One moment... 🤓

[github-actions[bot]]

Step 2: Review and close secret scanning alerts

In the last step, you enabled secret protection and committed a sensitive file to the repository. Now, let's review our open secret scanning alerts and close one.

:keyboard: Activity: Triage secret scanning alerts

1. In the header of your repository, click the Security tab.

2. In the left navigation, select the Secret scanning option.

3. Notice various options in the header bar that can help triage our alerts.

   

4. Click the Provider dropdown and select Amazon AWS to filter the view. Notice only 2 of the 3 entries are listed now.

   

:keyboard: Activity: Review a secret scanning alert

1. In the list of open alerts, select the Amazon AWS Access Key ID alert. This will open a details page with more information.

2. At the top of the page, we can quickly view the alert status, when it was opened, the exposed secret, and some remediation steps.

   

3. Scroll down slightly to the Detected in X locations area. Notice that secret protection doesn't create duplicate alerts for the same secret found across multiple locations, for example in our learning issue.

   

:keyboard: Activity: Close an alert

When secret protection finds a secret in your repository, the first thing you should do is disable that secret with the provider. You should assume it has been exposed.

[!TIP] Some supported secrets are automatically sent to the provider when leaked.

1. Assuming you have taken remediation steps, we can update the status of our alert. In the top right, select the Close as dropdown.

   🚨 Caution: Do NOT close an open alert without performing remediation steps. This simply hides the problem and provides a false sense of security. It might even trigger additional alerts with your cybersecurity department. 🤦

2. Choose the Revoked option and enter a useful description of your remediation steps in the comment box (example below). Then choose Close alert.

   The secret owner was contacted. They provided proof that the exposed secret was replaced.

   💡 Tip: This is important so the audit log can later provide critical information if an investigation is required.

   

3. The alert status now displays Closed and the audit trail includes our explanation.

   

4. With at least one of our alerts resolved, let's add a comment to inform Mona we are done with this step, so she can share the next one.

   Hello @professortocat, I've resolved the security alert. What's next?

[github-actions[bot]]

Please, follow the steps above.
I'll watch your progress in the background to provide feedback. 🧐

[fedriactiv8]

Hello @professortocat, I've resolved the security alert. What's next?

[github-actions[bot]]

Nice! Looks like you are making progress.
Let's see if I have some feedback for you... 🧐

[github-actions[bot]]

Great work reviewing security alerts! 🎉 This is exactly what we wanted! GitHub detected the token pattern and alerted us so we could handle it properly.

[github-actions[bot]]

🎉🎉🎉 Nice work! Everything is perfect! 🎉🎉🎉
Preparing content for step 3! One moment... 🤓

[github-actions[bot]]

Step 3: Enable push protection

In this section, you will configure your repository to prevent new secrets from being exposed.

What is push protection?

When someone tries to send code changes to GitHub (a push), secret scanning checks for high-confidence secrets. Secret scanning lists any secrets it detects so the author can review the secrets and remove them or, if needed, allow those secrets to be pushed.

:keyboard: Activity: Configure push protection

[!IMPORTANT] We disabled push protection in our first step for learning practice. It is normally enabled by default for all public repositories.

1. In the header of your repository, click the Settings tab.
2. In the left navigation, under the Security section, select Code Security.
3. Scroll down past the Code Scanning and Dependabot sections until you find the Secret Protection section.

4. Adjust the default configuration to match the below.

   • Secret Protection: enabled
   • Push Protection: enabled
   

:keyboard: Activity: Attempt to push a secret

Now that secret push protection is enabled, let's give it a test!

1. In the header of your repository, click the Code tab.

2. In the list of files, click on the credentials.yml file to preview it.

3. Above the content preview, click the Edit button.

   

4. Copy the following inactive secret to the file, removing the <REMOVE_ME> text. It should look like the below screenshot.

    github-token: github_pat_<REMOVE_ME>11A4YXR6Y0v36CYFkuT5I1_ZRWX91c8k0waSN6x7AiVJ6zZ9ZHUQXBblBqFQpKd23V6CL7MWMPopnmBxzn

   

5. In the top right, use the Commit changes... button to try to commit directly to the main branch. Instead of committing the updated file, a push protection alert appeared. Nice! 🥰

   

[!IMPORTANT] Secret Push Protection only scans while pushing to GitHub. It cannot check your local commits. If you have a secret in a local commit and it is several commits deep, you will need to remove the secret from your branch's commit history. See resolving a blocked push on the command line.

:keyboard: Activity: Bypass push protection

In some cases, you may write code that looks similar to a secret and a commit is incorrectly blocked. For example writing tests for an authorization process. In those situations, you can choose to bypass push protection. Let's practice that.

1. Select the radio button next to It's used in tests. Notice the description, matches our current learning use case.

   

2. Click Allow secret. A notification banner reports that you can now try committing again.

3. In the top right, use the Commit changes... button to commit directly to the main branch.

4. With the file updated, Mona should be busy checking your work. After checking, she'll provide feedback and the final review. Nice work! You are all done! 🎉

[github-actions[bot]]

Please, follow the steps above.
I'll watch your progress in the background to provide feedback. 🧐