CMF
RDK Releases
Documentation
CMF Videos
Support
Support for CMF is provided by the RDK Support group.
To contact RDK Support:
Enter a ticket: https://jira.rdkcentral.com/
or
E-mail: support@rdkcentral.com
Executive Summary: Enabling Secret Scanning Protection in GitHub Advanced Security
Secret Scanning Protection is a key feature of GitHub Advanced Security (GHAS) that helps prevent the accidental exposure of sensitive information such as API keys, credentials, and tokens in source code.
Purpose
Secret scanning proactively detects and alerts on secrets committed to repositories. It includes push protection, which blocks commits containing specific secrets before they reach the repository.
Enablement Process at the Organization Level
- Prerequisites
- GitHub Advanced Security must be enabled for the organization.
- Steps
- Navigate to the Organization Settings.
- Go to Security > Code security and analysis.
- Under Secret Scanning, enable:
- Secret scanning alerts: Detects secrets already committed.
- Push protection: Prevents new specific secret types from being committed.
- Repository-Level Enforcement
- Organization admins can enforce secret scanning via security configurations.
Benefits
- Proactive Protection: Prevents secrets from being pushed to GitHub.
- Automated Alerts: Notifies developers and admins of exposed secrets.
- Compliance Support: Helps meet internal and external security standards.
- Developer-Friendly: Offers bypass options for valid use cases (e.g., test keys).
Remediation
Team members with maintainers role do not have access to view secrets in security tab at repo level. Only admin and security manager role has access to view/remediate secret alerts.
Before Enabling Secret Protection:
After Enabling Secret Protection:
Excluding folders and files from secret scanning
You can customize secret scanning to automatically close alerts for secrets found in specific directories or files by configuring a secret_scanning.yml file in your repository.
Feature | Description |
Validity checks | Automatically verify if a secret is valid by sending it to the relevant partner. |
Non-provider patterns | Scan for non-provider patterns. Learn more about non-provider patterns. |
Scan for generic passwords | Copilot Secret Scanning detects passwords using AI. Learn more about generic password detection. |
Push protection | Block commits that contain supported secrets. |
Copilot Secret Scanning:
Below is an example of a commit detected by secret scan. GH would alert the user through email.
Secret scanning alerts:
Example:
Default alerts list
The default alerts list displays alerts that relate to supported patterns and specified custom patterns. This is the main view for alerts.
Generic alerts list
The generic alerts list displays alerts that relate to non-provider patterns (such as private keys), or generic secrets detected using AI (such as passwords). These types of alerts can have a higher rate of false positives or secrets used in tests. You can toggle to the generic alerts list from the default alerts list.
About push protection:
Push Protection: Block commits that contain supported secrets.
Service providers update the patterns used to generate tokens periodically and may support more than one version of a token. Push protection only supports the most recent token versions that secret scanning can identify with confidence. This avoids push protection blocking commits unnecessarily when a result may be a false positive, which is more likely to happen with legacy tokens.
In above screenshots, user is provided with a github link to browse as shown below
Select a suitable option above to bypass push protection.
When you allow a secret to be pushed, an alert is created in the Security tab. GitHub closes the alert and doesn't send a notification if you specify that the secret is a false positive or used only in tests. If you specify that the secret is real and that you will fix it later, GitHub keeps the security alert open and sends notifications to the author of the commit, as well as to repository administrators. For more information, see Managing alerts from secret scanning.
About secret scanning - GitHub Docs
Push protection blocks contributors from pushing secrets to a repository and generates an alert whenever a contributor bypasses the block. Push protection can be applied at the repository, organization, and user account level.
Who can use this feature?
Push protection is available for the following repository types:
- Public repositories on GitHub.com
- Organization-owned repositories on GitHub Team with GitHub Secret Protection enabled
In this article
Push protection is a secret scanning feature that is designed to prevent sensitive information, such as secrets or tokens, from being pushed to your repository in the first place. Unlike secret scanning, which detects secrets after they have been committed, push protection proactively scans your code for secrets during the push process and blocks the push if any are detected.
Push protection helps you avoid the risks associated with exposed secrets, like unauthorized access to resources or services. With this feature, developers get immediate feedback and can address potential issues before they become a security concern.
You can enable push protection:
- At repository/organization level, if you are a repository administrator or an organization owner. You will see alerts in the Security tab of your repository when a contributor to the repository bypasses push protection.
- For your account on GitHub, as a user. This type of push protection is referred to as "push protection for users". It protects you from pushing secrets to any public repository on GitHub, but no alerts are generated.
Push protection has some limitations. For more information, see Troubleshooting secret scanning.
Push protection works:
- From the command line. See Working with push protection from the command line.
- In the GitHub UI. See Working with push protection in the GitHub UI.
- On files uploaded onto the repository on GitHub.
- From the REST API. See Working with push protection from the REST API.
Once enabled, if push protection detects a potential secret during a push attempt, it will block the push and provide a detailed message explaining the reason for the block. You will need to review the code in question, remove any sensitive information, and reattempt the push.
By default, anyone with write access to the repository can choose to bypass push protection by specifying one of the bypass reasons outlined in the table. If a contributor bypasses a push protection block for a secret, GitHub:
- Creates an alert in the Security tab of the repository.
- Adds the bypass event to the audit log.
- Sends an email alert to organization or personal account owners, security managers, and repository administrators who are watching the repository, with a link to the secret and the reason why it was allowed.
This table shows the behavior of alerts for each way a user can bypass a push protection block.
Bypass reason | Alert behavior |
It's used in tests | GitHub creates a closed alert, resolved as "used in tests" |
It's a false positive | GitHub creates a closed alert, resolved as "false positive" |
I'll fix it later | GitHub creates an open alert |
If you want greater control over which contributors can bypass push protection and which pushes containing secrets should be allowed, you can enable delegated bypass for push protection. Delegated bypass lets you configure a designated group of reviewers to oversee and manage requests to bypass push protection from contributors pushing to the repository. For more information, see About delegated bypass for push protection.
About the benefits of push protection
- Preventative security: Push protection acts as a frontline defense mechanism by scanning code for secrets at the time of the push. This preventative approach helps to catch potential issues before they are merged into your repository.
- Immediate feedback: Developers receive instant feedback if a potential secret is detected during a push attempt. This immediate notification allows for quick remediation, reducing the likelihood of sensitive information being exposed.
- Reduced risk of data leaks: By blocking commits that contain sensitive information, push protection significantly reduces the risk of accidental data leaks. This helps in safeguarding against unauthorized access to your infrastructure, services, and data.
- Efficient secret management: Instead of retrospectively dealing with exposed secrets, developers can address issues at the source. This makes secret management more efficient and less time-consuming.
- Ability to detect custom patterns: Organizations can define custom patterns for detecting secrets unique to their environment. This customization ensures that push Protection can effectively identify and block even non-standard secrets.
- Delegated bypass for flexibility: For cases where false positives occur or when certain patterns are necessary, the delegated bypass feature allows designated users to approve specific pushes. This provides flexibility without compromising overall security.
Every user across GitHub can also enable push protection for themselves within their individual settings. Enabling push protection for your user account means that your pushes are protected whenever you push to a public repository on GitHub, without relying on that repository to have push protection enabled. For more information, see Push protection for users.
Define custom patterns that push protection can use to identify secrets and block pushes containing these secrets. For more information, see Defining custom patterns for secret scanning.
- Enabling push protection for your repository
- Working with push protection from the command line
- Working with push protection in the GitHub UI
- Defining custom patterns for secret scanning
- About delegated bypass for push protection
From <https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection>
Note
Push protection and validity checks are not supported for non-provider patterns.
Below link provides all supported secrets for push protection.
Steps to Handle Secrets Listed in the Security Tab by Developers:
Review the Alert
- Go to Repo → Security → Secret scanning.
- Click on each alert to see:
- The file and line where the secret was found.
- The type of secret (e.g., GitHub token, AWS key).
- Whether it’s still active or revoked.
While closing the alert, select appropriate action, add relevant comment and close the alert as shown below
More helpful articles listed below
About secret scanning alerts
Learn about the different types of secret scanning alerts.
Viewing and filtering alerts from secret scanning
Learn how to find and filter secret scanning alerts for users for your repository.
Evaluating alerts from secret scanning
Learn about additional features that can help you evaluate alerts and prioritize their remediation, such as checking a secret's validity.
Resolving alerts from secret scanning
After reviewing the details of a secret scanning alert, you should fix and then close the alert.
Monitoring alerts from secret scanning
Learn how and when GitHub will notify you about a secret scanning alert.
Overview
Community Forums
Content Tools
Tasks