Secure Your GitHub Repo with gh secure

Enable GitHub security checks and prove they protect your public repository.

Introduction

30 Second Summary

When your code is open for anyone to see, one missed safety setting can leave mistakes exposed. Five separate settings screens make that protection easy to postpone.

In this project, you will use a GitHub CLI extension from GitHub Security Lab to switch on every free security check for a public repository you own. You will prove the new coverage by triggering its protections with controlled test changes.

What You'll Build

You will finish with a hardened repository backed by a clear before-and-after record of each protection working.

By the end of this project, you'll have:

A before-and-after security report showing every protection covered by the project as enabled.
A blocked test push that proves push protection catches an obviously fake credential before it enters your repository.
A Dependabot advisory tied to a deliberately outdated dependency. A CodeQL results page showing findings from your own code.
Secret Mission: An optional challenge that extends your hardened repository with another security improvement.

Are there any prerequisites?

You need a GitHub account with admin or maintainer access to a public repository you own. You also need GitHub CLI installed and authenticated. The covered checks are free for public repositories, so the project costs nothing.

Before We Start

Repository security work starts with access you can prove. The checks in this project need an authenticated GitHub CLI session connected to your GitHub account.

You will prepare a public Node.js repository that already contains package.json plus source code. This gives CodeQL something to analyze before any protection changes.

In this step, get ready to:

Prepare GitHub CLI for access to your GitHub account.
Select a public Node.js repository that you can administer.
Capture the repository's initial security status.

Prepare GitHub CLI

GitHub CLI brings repository actions into your terminal. Start by checking whether the command is available.

Check your GitHub CLI installation by running this command:

gh --version

What Does This Command Do?

The command displays the installed GitHub CLI version. It then returns control to your terminal.

✔️ GitHub CLI is installed

Your version output confirms that GitHub CLI is ready. Continue to authentication below.

ⓧ Command not found

GitHub provides installation options for macOS, Windows, plus Linux. Use the option that matches your computer.

Open the official GitHub CLI installation guide.
Follow the installation instructions for your operating system.
Return to your terminal after the installation finishes.
Confirm the command is available by running this check:

gh --version

What Does This Check Confirm?

A version number confirms that your terminal can find GitHub CLI. You can now use it to authenticate.

Still Missing GitHub CLI?

Close your current terminal after installation. Start a fresh terminal so it loads the updated command path.

Use the installer option shown for your operating system if the command remains unavailable.

Help me install GitHub CLI on my computer.

The login command opens a browser-based authentication flow. The terminal may also ask whether Git can use the same credentials for future repository operations.

Start browser authentication by running this command:

gh auth login --hostname github.com --git-protocol https --web

What Does This Command Do?

The --hostname github.com option connects the session to GitHub.com.
The --git-protocol https option configures HTTPS for repository operations.
The --web option starts browser authentication.

Approve the GitHub CLI authorization request in your browser.
Approve credential setup if the terminal asks for permission.
Return to your terminal after GitHub confirms the authorization.
Check the stored authentication state by running this command:

gh auth status

What Does This Check Confirm?

The status check tests the stored session for each known GitHub host. The active account is the identity GitHub CLI uses for later commands.

You should see GitHub.com listed with your active account. Your terminal is now authenticated without displaying your token.

Authentication Not Working?

Confirm that you approved the same GitHub account that owns the repository you plan to use.

Restart the browser flow if the authorization expired before you completed it.

Help me diagnose my GitHub CLI authentication.

Choose a public Node.js repository

The repository needs a package manifest plus existing source code. Your account also needs administrative permission so the extension can change security settings in the next step.

Return to the browser used for authentication.
Select a public Node.js repository that you own.
Confirm the repository file list contains package.json.
Confirm the repository contains existing source code.
Record the repository path as <OWNER>/<REPO>.
Record the repository name as <REPO>.
Return to your terminal.
Check the repository metadata by running this command:

gh repo view [[REPOSITORY="<OWNER>/<REPO>"]] --json nameWithOwner,visibility,viewerCanAdminister,defaultBranchRef

What Does This Command Check?

The nameWithOwner field identifies the selected repository.
The visibility field confirms whether the repository is public.
The viewerCanAdminister field confirms whether your active account can administer the repository.
The defaultBranchRef field contains the default branch name.

The metadata should identify your chosen public repository. The administrator value should confirm that your account can manage its settings.

Record the name inside defaultBranchRef as <DEFAULT_BRANCH>.

Repository Does Not Match?

Choose another repository if the visibility value identifies a private repository. Choose another repository if your account cannot administer it.

Confirm that the replacement repository contains package.json plus source code before continuing.

Help me choose a suitable GitHub repository.

A local Git clone gives the security tool repository context. Keeping it on your Desktop also makes the folder easy to find during cleanup.

Move to your Desktop by running this command:

cd ~/Desktop

What Does This Command Do?

The command changes the terminal's current location to your Desktop. The clone command creates the repository folder there.

Clone your selected repository by running this command:

gh repo clone [[REPOSITORY="<OWNER>/<REPO>"]]

What Does This Command Do?

GitHub CLI downloads the repository history plus its tracked files. It also configures the GitHub repository as a remote for your local clone.

The terminal reports that it is cloning your repository. Your Desktop now contains a folder named after <REPO>.

Clone Command Failing?

Install Git from the official Git downloads page if your computer is missing Git.
Rename an existing <REPO> folder before retrying the clone.

Help me diagnose my repository clone.

Enter the cloned repository folder by running this command:

cd [[REPOSITORY_NAME="<REPO>"]]

What Does This Command Do?

The command moves your terminal into the local clone. Repository-aware commands now target this project by default.

Before you check the clone, what repository name plus branch do you expect the terminal to report?

Verify the active branch plus the connected repository by running these commands:

git status --short --branch
gh repo view

What Do These Commands Check?

The first command prints a compact working tree status with branch information.
The second command uses the current folder's GitHub remote to display the connected repository.

The branch line names <DEFAULT_BRANCH>. The repository summary identifies <OWNER>/<REPO>.

Seeing the Wrong Repository or Branch?

Check that your terminal prompt is inside the folder named <REPO>.

Compare the reported branch with the default branch recorded from the repository metadata.

Help me verify my local Git clone.

Capture the initial security baseline

The gh-secure extension collects several repository protections into one workflow. Its status command gives you a before snapshot without changing the settings.

Install the GitHub Security Lab extension by running this command:

gh extension install GitHubSecurityLab/gh-secure

What Does This Command Do?

GitHub CLI downloads the extension from the GitHub Security Lab repository. The new secure command becomes available through gh.

The terminal confirms that the extension was installed. You can now audit the current repository.

Extension Installation Failing?

Confirm that gh auth status still reports an active GitHub.com account.

Check your network connection before retrying the installation.

Help me install the gh-secure extension.

Before you run the audit, which repository protections do you expect to see disabled?

Read the current security status by running this command:

gh secure status

What Does the Status Report Cover?

The report checks branch protection on the default branch.
The report checks private vulnerability reporting.
The report checks secret scanning with push protection.
The report checks Dependabot features.
The report checks CodeQL code scanning.

You will see the repository name followed by its current protection statuses. Each disabled protection becomes part of your before record.

Good work. Your terminal now holds the baseline that every later test builds on.

Setup Checkpoint

Your local clone is connected to <OWNER>/<REPO>.
Your current branch is <DEFAULT_BRANCH>.
The public repository contains package.json plus source code that CodeQL can analyze.
The repository security settings still match the baseline you captured.

Your repository is ready for hardening. Next, you will enable each protection through the interactive security workflow.

Check Your Repository Security Status

Security settings are easy to change without a record of where you started. A baseline gives you evidence of every missing protection before remediation begins.

The GitHub Security Lab extension adds a status check to your authenticated GitHub CLI session. You will use it to capture the repository's initial security report.

In this step, get ready to:

Install the GitHub Security Lab security extension.
Run a status check against your selected public repository.
Capture the report before changing any protections.

Add the repository security command

A GitHub CLI extension adds commands to your existing installation. This extension uses the authentication you already established.

Install the GitHub Security Lab extension by running this command:

gh extension install GitHubSecurityLab/gh-secure

What Does This Command Do?

The gh extension install command downloads an extension from its GitHub repository.
The GitHubSecurityLab/gh-secure value identifies the extension repository.
The gh secure command is added to your GitHub CLI installation.

Confirm the terminal returns to its prompt after reporting that the extension was installed.

That is the first piece in place. Your existing GitHub CLI can now inspect repository protections.

Did the Installation Stop?

Confirm your existing GitHub CLI session is still authenticated.
Retry the installation after restoring network access to GitHub.

Help me diagnose the extension installation. Review the extension's support guide.

Capture the baseline report

The status command reads the current feature state without enabling anything. Running it from your local clone targets the repository connected to that clone.

Before you run the check, which protections do you expect the tool to flag?

Run the baseline check from the terminal at your local clone:

gh secure status

What Does the Report Cover?

The gh secure status command reads the current feature status without changing repository settings.
Branch protection governs changes to the default branch.
Private vulnerability reporting provides a private route for reporting security issues.
Secret scanning checks for exposed credential patterns.
Dependabot checks dependencies for known vulnerabilities.
CodeQL code scanning analyzes source code for security issues.

Your terminal should show a status report for the current repository. Any disabled or unconfigured protections appear in that report.

Keep the full status report visible in your terminal.

Does the Report Look Wrong?

Return to the terminal from earlier inside your selected local clone.
Confirm the status report names the repository you selected.
Confirm your GitHub CLI account has admin access to that public repository.

Help me diagnose my repository status report.

Strong start. Your before-remediation report now records the protections that need attention. Next, you will use interactive mode to switch those protections on.

Enable Every Security Protection

Your first status report turned the repository's security gaps into a checklist. You now have a clear before-state for every change.

The installed extension applies five protection groups in one interactive pass. You will approve each group before confirming the visible settings in your browser.

In this step, get ready to:

Apply every offered protection through the interactive extension.
Confirm the branch protection rule for <DEFAULT_BRANCH>.
Verify private vulnerability reporting in the repository settings.

Enable the protections interactively

Interactive mode lets the GitHub CLI extension present each protection before applying it. This command changes repository settings while leaving your source files untouched.

Return to the terminal in the local clone of <OWNER>/<REPO>.
Start the interactive security configuration by running this command:

gh secure

What Does Interactive Mode Change?

The gh secure command includes every protection when you do not specify individual feature names.
Branch protection adds guardrails to your default branch.
Private vulnerability reporting gives researchers a private disclosure path.
Secret scanning detects supported credential patterns. Push protection blocks matching secrets before they reach the repository.
Dependabot enables vulnerability alerts. It also enables security updates.
CodeQL code scanning analyzes the repository's source code for security problems.

Review the target repository shown when the interactive session begins.
Accept each offered protection as its prompt appears.
Wait for the extension to finish applying the accepted protections.
Confirm the terminal reports a configuration result for all five protection groups.

That is the bulk of the hardening done. One interactive pass has replaced five separate settings changes.

Does a Protection Fail?

Confirm the extension targeted <OWNER>/<REPO>.
Confirm the repository is public.
Confirm your authenticated GitHub account has admin or maintainer permission.

Help me diagnose the failed protection.

Confirm branch protection

A branch protection rule limits risky changes to the branch that holds your main project history. The settings page lets you verify that the extension targeted the correct branch.

Pause to predict which branch should appear under the new rule.
Switch back to the browser tab for <OWNER>/<REPO>.
Select Settings below the repository name.
Reload the settings page.
Select Branches in the left sidebar.
Review Branch protection rules to identify the branch targeted by the listed rule.

You will see a rule for <DEFAULT_BRANCH>. An Edit action sits beside the rule.

That is the first browser check complete. The default branch now has the protection created by the extension.

Is the Branch Rule Missing?

Confirm the browser shows the settings for <OWNER>/<REPO>.
Return to the terminal result from the interactive configuration.
Look for a reported failure associated with branch protection.

Help me find the missing branch rule.

Verify private vulnerability reporting

Private vulnerability reporting gives researchers a secure route to contact the repository maintainers. An enabled setting shows the action that would turn the feature off.

Pause to predict which control should appear beside the setting when the feature is enabled.
Select Advanced Security in the repository settings sidebar.
Reload the page.
Review the control beside Private vulnerability reporting.

You will see Disable beside Private vulnerability reporting. That control confirms the feature is currently enabled.

Your repository now has every offered protection switched on. Next, you will test push protection with a safe fake credential.

Test Secret-Scanning Push Protection

Your GitHub repository now has secret scanning plus push protection enabled. A security control earns trust when you test its boundary.

This step uses Git with a harmless training token. The experiment stays on a local test branch while GitHub decides whether to accept the commit.

In this step, get ready to:

Create an isolated branch for the secret-scanning test.
Commit a deliberately fake credential pattern.
Attempt the push to inspect the protection response.

Create an isolated test branch

A separate branch keeps the test commit away from your normal work. The branch begins from the default branch already checked out in your local clone.

Return to the terminal for the local clone from earlier.
Create the test branch by running this command:

git switch -c test-secret-scanning

What Does This Command Do?

The command creates test-secret-scanning from the current commit.
The -c flag switches your local clone to the new branch immediately.

The terminal confirms that you switched to a new branch named test-secret-scanning.

Does the Branch Already Exist?

An earlier test may already be using the branch name. Preserve any work from that branch before you rename or remove it.

Get help reviewing the existing branch safely.

Plant and commit a fake token

GitHub publishes a dummy token for learning how secret scanning responds. This training value cannot authenticate to an account or service.

Placing a credential pattern in a commit can feel risky. This exercise uses the documented dummy value while keeping the commit local.

macOS

Create fake-api-key.txt with the training token by running this command:

printf '%s\n' 'secret_scanning_ab85fc6f8d7638cf1c11da812da308d43_abcde' > fake-api-key.txt

What Does This Command Do?

The printf utility writes the dummy token as one line.
The output redirection stores that line in fake-api-key.txt.

Windows

Create fake-api-key.txt with the training token by running this command in PowerShell:

Set-Content -Path .\fake-api-key.txt -Value 'secret_scanning_ab85fc6f8d7638cf1c11da812da308d43_abcde'

What Does This Command Do?

The Set-Content command creates fake-api-key.txt in the current folder.
The -Value parameter writes the dummy token into the file.

Confirm that Git can see the new file by running this command:

git status

What Does This Command Check?

The command compares your files with the current commit. It reports new files that Git has not started tracking.

You should see fake-api-key.txt listed as an untracked file on test-secret-scanning.

Is the Test File Missing?

Confirm that the terminal is inside the local clone from earlier.
Confirm that the file name is exactly fake-api-key.txt.

Help me find the missing test file.

✔️ Awesome, I've got everything!

Great. Your local test file contains the harmless training token.

ⓧ I'd like to double check the full code

Compare the complete contents of fake-api-key.txt with this reference.

secret_scanning_ab85fc6f8d7638cf1c11da812da308d43_abcde

Record the test file in local history by running these commands:

git add fake-api-key.txt
git commit -m "Add fake API key for push protection test"

What Do These Commands Do?

The first command stages only fake-api-key.txt.
The second command stores the staged file in the local branch history.

Good work. The terminal reports a new local commit that creates fake-api-key.txt.

Did the Commit Fail?

Check the working tree status to confirm that fake-api-key.txt is staged. If Git requests author details, follow its guidance to configure your commit identity.

Help me diagnose the local test commit.

Challenge push protection

The local commit is now the test payload. A push asks GitHub whether that commit can enter the remote repository.

Before you run this, which outcome do you expect: a new remote branch or a stopped transfer?

Attempt to push the test branch by running this command:

git push origin test-secret-scanning

Push Protection Stops the Transfer

GitHub rejects the push before creating the remote branch. Your commit remains only on the local test-secret-scanning branch.

The message identifies GitHub Secret Scanning secret as the detected token type. It also points to fake-api-key.txt.

Read the line that names the detected token type.
Leave the provided bypass URL unused.
Keep the blocked-push output visible for your checkpoint.

Did the Push Succeed?

A successful push means the remote branch received the fake test file. Clear that unexpected remote state before continuing.

Return to the repository branch list in the browser from earlier.
Delete the remote test-secret-scanning branch.
Return to the secret-scanning settings from earlier.
Confirm that push protection remains enabled.

Help me diagnose why push protection allowed the training token.

You have proved that push protection stops a matching credential before it reaches your remote repository. Next, you will test how the repository reports a vulnerable dependency.

Review a Dependabot Alert

Your GitHub push protection has already proved that the fake credential cannot reach the remote repository. The blocked commit remains safely isolated on your local test branch.

Now Dependabot needs a dependency change it can inspect. You will publish a deliberately outdated version on a separate branch. You will use the resulting alert to connect that version to a security advisory.

In this step, get ready to:

Create a separate branch for the vulnerable dependency test.
Add lodash version 4.17.20 to package.json.
Review the first Dependabot alert plus its matched advisory.

Create the dependency test branch

The secret-scanning test belongs on test-secret-scanning. A separate Git branch keeps that local-only commit out of the dependency test.

Return to the terminal from the push-protection test.
Create dependabot-test from your default branch by running this command:

git switch -c dependabot-test [[DEFAULT_BRANCH="<DEFAULT_BRANCH>"]]

What Does This Command Do?

The -c option creates a new branch.
The final argument makes your default branch the starting point.
Your local test-secret-scanning branch keeps its blocked commit unchanged.

The terminal confirms that Git switched to dependabot-test. Your new test starts from the repository's normal code.

Branch Creation Failed?

Confirm that you are inside the local clone of your repository. Git cannot create this branch from another folder.

If dependabot-test already exists locally, switch to that branch instead of creating it again.

Help me create the Dependabot test branch without changing test-secret-scanning.

The package.json file is a JSON manifest of the packages your project uses. Adding an exact dependency version gives Dependabot a concrete package record to compare with known advisories.

Add lodash version 4.17.20 to the manifest by running these commands:

npm pkg set dependencies.lodash=4.17.20
npm pkg get dependencies.lodash

What Do These Commands Do?

The first command writes lodash under the dependencies object in package.json.
The exact version gives the scanner a reproducible dependency record.
The second command reads the saved lodash version back from the manifest.

You should see version 4.17.20 in the terminal. That visible result confirms that package.json now contains the test dependency.

Dependency Value Missing?

Confirm that the terminal is inside the folder containing package.json. The command edits the manifest in its current folder.

If the npm command is unavailable, add lodash with version 4.17.20 under the existing dependencies object in your text editor.

Help me verify the lodash dependency in package.json.

Publish the manifest change

Dependabot can inspect a manifest after the change reaches GitHub. A focused commit makes the deliberately outdated dependency easy to identify later.

Commit the manifest change by running these commands:

git add package.json
git commit -m "Add Dependabot test dependency"

What Do These Commands Record?

The first command stages only package.json.
The second command records the staged manifest on dependabot-test.
The fake credential commit remains confined to test-secret-scanning.

The commit summary identifies package.json as the changed file. Your dependency test is ready to publish.

Nothing to Commit?

Read the stored dependency again to confirm that lodash is set to 4.17.20. A missing value means the manifest edit did not land in this branch.

Confirm that the current branch is dependabot-test. Committing from another branch would put the test in the wrong history.

Help me diagnose why the Dependabot test commit has no changes.

Before you push, predict whether secret-scanning push protection will reject a branch that contains an outdated dependency without a credential.

Publish dependabot-test by running this command:

git push -u origin dependabot-test

What Does This Push Do?

The command publishes the local commit to a remote branch with the same name.
The -u option connects the local branch to its remote counterpart.
Dependabot can now inspect the pushed manifest change.

That is the branch published. GitHub accepts the push because this test contains a package version instead of a credential.

Push Rejected?

Confirm that the current branch is dependabot-test. The local test-secret-scanning branch still contains the blocked credential pattern.

Confirm that your authenticated GitHub account has write access to the repository. The remote branch cannot be created without that permission.

Help me diagnose the failed dependabot-test push.

Review the matched advisory

A Dependabot alert connects a vulnerable package record to information from a security advisory. The alert shows the affected dependency plus the risk GitHub matched to it.

The first scan can take a little while after the branch reaches GitHub. A quiet alerts page during processing does not mean your manifest was ignored.

Switch back to the GitHub repository in your browser.
Select the Security and quality tab under the repository name.
Select Dependabot in the Findings section.
Click Vulnerabilities.
Refresh the vulnerability list until an open alert for lodash appears.

No Alert Yet?

Confirm that the remote dependabot-test branch contains package.json with lodash version 4.17.20.

Allow the first dependency scan to finish before refreshing the vulnerability list again.

Help me check why the lodash alert has not appeared.

Before you open the alert, predict which details will connect the package version to its security risk.

Select the first open lodash alert.
Confirm that the affected dependency is lodash at version 4.17.20.
Review the severity shown in the alert details.
Open the related security advisory from the alert details.
Identify the fixed version when the advisory provides one.

You can now see the vulnerable package plus the advisory GitHub matched to it. The alert turns a version in package.json into a specific security finding you can investigate.

What Does the Advisory Add?

The alert identifies where the vulnerable dependency appears in your repository. The advisory explains the underlying vulnerability plus its potential impact.

A fixed version gives you a concrete remediation target when one is available.

Your repository has now exposed a vulnerable dependency through a reviewable alert. Next, you will inspect the first CodeQL workflow plus the findings it reports.

Inspect CodeQL Results

Your Dependabot alert proved that the repository can catch a risky dependency. Now CodeQL checks the repository's own code for security findings.

This final check follows the initial analysis through GitHub Actions. You will review the result that analysis produced.

In this step, get ready to:

Confirm the initial CodeQL workflow run has finished.
Open the code scanning results.
Review any findings from the completed analysis.

Wait for the initial CodeQL run

A CodeQL workflow run turns the enabled protection into a completed analysis. The first analysis can take a while.

A running job shows that CodeQL is still working through the repository.

Switch back to the <OWNER>/<REPO> repository page from earlier.
Select the Actions tab.
Find the initial CodeQL workflow run.
Select the run to inspect its current status.
Wait for the run to finish.

You will see the initial CodeQL analysis listed as complete.

What Does the Completed Run Prove?

The completed workflow proves that CodeQL analysed the repository's code. Its output now feeds the repository's code scanning results.

Still Waiting for the Workflow?

Refresh the Actions tab after a short wait.
Check the workflow list for the newest CodeQL run.

Use this if the run remains unavailable: Help me diagnose the missing CodeQL workflow run.

Review the code scanning results

Code scanning results capture the output from the completed analysis. Your repository can contain reported findings or finish with no findings.

Before you open the results, do you expect CodeQL to report a finding or a clean analysis?

Return to the repository page from the workflow run.
Select the Code scanning results tab.
Review the result summary from the completed analysis.
Open the first reported finding if the results contain one.
Confirm the completed analysis if no findings are listed.

You will see either a list of findings or a completed analysis with no findings.

How Should You Read the Result?

A reported finding includes an affected location plus a security explanation. These details show what CodeQL detected in the repository's code.

A completed analysis with no findings confirms that CodeQL finished its first pass. Future code changes still need continuous scanning.

Are the Results Still Loading?

Return to the Actions tab.
Confirm the CodeQL run has finished.
Refresh the Code scanning results tab.

Use this if the results remain unavailable: Help me diagnose my CodeQL results page.

That closes the loop. Your repository's first CodeQL analysis is complete with its result reviewed.

Secret mission

Map Your Repository's Security Coverage

Turn your completed security tests into a five-control evidence map. Match every protection to proof from your repository. Identify one risk that still needs a human response.

Clean Up Your Resources

Your security checks can stay enabled at no cost for this public GitHub repository. Choose whether to preserve the test artifacts or remove them now.

Resources you used:

The local test-secret-scanning branch with the unpushed commit that adds fake-api-key.txt.
The dependabot-test branch in your local clone plus its remote counterpart. This branch carries lodash version 4.17.20 in package.json.

Keep everything running

No cleanup is required. Choose this if you want to repeat the protection tests with the same artifacts.

Keep test-secret-scanning in your local clone.
Keep dependabot-test in your local clone.
Keep the remote dependabot-test branch on GitHub.
Leave every repository protection enabled.

Pause - I'll come back to this later

Step away without changing the repository's security posture. No running process needs to be stopped.

Use the local branch controls to switch back to <DEFAULT_BRANCH>.
Keep both local test branches in place.
Keep the remote dependabot-test branch in place.
Leave every repository protection enabled.

Delete - I don't want to use this again

Deleting these branches removes only the deliberately planted tests. Every repository protection stays enabled.

Your Git client may ask for confirmation because test-secret-scanning contains an unmerged commit. That commit is the fake credential test you intend to discard.

Return to the local working clone from earlier in your Git client.
Use its branch controls to switch to <DEFAULT_BRANCH>.
Use its branch manager to delete the local test-secret-scanning branch.
Use the same branch manager to delete the local dependabot-test branch.
Return to the browser tab for <OWNER>/<REPO>.
Open the repository's Branches page from the link above the file list.
Select Delete branch beside dependabot-test.
Refresh the Branches page.

Your local branch list no longer includes either test branch. GitHub no longer lists dependabot-test.

The fake credential commit disappeared with test-secret-scanning. The outdated dependency disappeared with dependabot-test.

Cleanup complete. Your security configuration remains intact.

Capture the Final Status

A final status report checks the protection configuration itself. It confirms that cleanup did not weaken the repository.

Return to the terminal session authenticated with the GitHub CLI.
Rerun the same status command from Step 1 against <OWNER>/<REPO>.

You should see a clean report with no protection left disabled or unconfigured.

Capture a screenshot of the clean report as your final before-and-after record.

Strong finish. Your repository still carries every protection you enabled.

Nice Work!

Brilliant work! You turned a public GitHub repository into a hardened project with five layers of protection.

You've learned how to:

Capture a before-state security report. Enable five repository protections in one interactive pass with the GitHub CLI extension.
Test secret-scanning push protection with a fake credential. Read the rejected push to identify the detected token type.
Review a Dependabot advisory for a deliberately outdated dependency. Inspect the completed CodeQL analysis. Read its code-scanning results.
Secret Mission: Complete the optional challenge to push your repository security skills further.

Ready to quiz yourself?