{"meta":{"title":"Sobre a proteção por push","intro":"Proteja seus segredos evitando que alcancem seu repositório com proteção por push.","product":"Qualidade de segurança e código","breadcrumbs":[{"href":"/pt/code-security","title":"Qualidade de segurança e código"},{"href":"/pt/code-security/concepts","title":"Concepts"},{"href":"/pt/code-security/concepts/secret-security","title":"Segurança secreta"},{"href":"/pt/code-security/concepts/secret-security/about-push-protection","title":"Proteção por push"}],"documentType":"article"},"body":"# Sobre a proteção por push\n\nProteja seus segredos evitando que alcancem seu repositório com proteção por push.\n\n\n## What is push protection?\n\nPush protection is a secret scanning feature designed to prevent hardcoded credentials, such as secrets or tokens, from ever being pushed to your repository. Rather than alerting you to credential leaks after the fact, push protection blocks pushes that contain secrets *before* they reach your repository.\n\n## How push protection works\n\nPush protection blocks secrets detected in:\n\n* Pushes from the command line\n* Commits made in the GitHub UI\n* File uploads to a repository on GitHub\n* Requests to the REST API\n* Interactions with the GitHub MCP server (public repositories only)\n\nWhen 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.\n\n## Types of push protection\n\nThere are two types of push protection:\n\n* [Push protection for repositories](#push-protection-for-repositories)\n* [Push protection for users](#push-protection-for-users)\n\n### Push protection for repositories\n\nYou can enable push protection for repositories at the repository, organization, or enterprise level. This form of push protection:\n\n* Requires GitHub Secret Protection to be enabled\n* Is disabled by default, and can be enabled by a repository administrator, organization owner, security manager, or enterprise owner\n* Blocks pushes containing secrets from reaching specific protected repositories\n* Generates alerts for push protection bypasses in the ** Security and quality** tab of the repository, organization, and enterprise\n\n> \\[!TIP]\n> Regardless of the enablement status of push protection, organizations on GitHub Team and GitHub Enterprise can run a free report to scan their code for leaked secrets. The report also shows how many secret leaks could have been prevented by push protection. See [About secret security with GitHub](/en/code-security/securing-your-organization/understanding-your-organizations-exposure-to-leaked-secrets/about-secret-risk-assessment).\n\n### Push protection for users\n\nPush protection for users is only available on GitHub.com, and is specific to your GitHub account. This form of push protection:\n\n* Is enabled by default\n* Stops you from pushing secrets to public repositories on GitHub\n* Does not generate alerts when you bypass push protection unless push protection is also enabled at the repository level\n\n## Push protection bypass and alerts\n\nFor push protection for repositories, by default, anyone with write access to the repository can bypass push protection by specifying a bypass reason. When a contributor bypasses a push protection block, GitHub:\n\n* Creates an alert in the ** Security and quality** tab of the repository, organization, and enterprise\n* Adds the bypass event to the audit log\n* Sends an email alert to personal account, organization, and enterprise owners, security managers, and repository administrators who are watching the repository, with a link to the secret and the reason it was allowed\n\nThis table shows the behavior of alerts for each bypass reason a user can specify.\n\n| Bypass reason | Alert behavior |\n| --------------------- | ----------------------------------------------------------- |\n| It's used in tests | GitHub creates a closed alert, resolved as \"used in tests\" |\n| It's a false positive | GitHub creates a closed alert, resolved as \"false positive\" |\n| I'll fix it later | GitHub creates an open alert |\n\nIf you want greater control over which contributors can bypass push protection and which pushes containing secrets should be allowed, you can configure delegated bypass for push protection. With delegated bypass, you can grant actors:\n\n* **Bypass privileges**, allowing them to bypass push protection themselves, as well as review and approve bypass requests from other contributors\n* **Exemption from push protection**, allowing them to push commits without triggering push protection\n\n## Benefits of push protection\n\n* **Preventative security:** Push protection acts as a frontline defense mechanism by scanning code for hardcoded secrets at the time of the push. This preventative approach helps prevent credential leaks before they become ingrained in the repository's history, making it easier to address and remediate threats.\n* **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.\n* **Reduced risk of credential leaks:** By blocking commits that contain hardcoded credentials, push protection significantly reduces the risk of accidental credential leaks and secret sprawl. This helps in safeguarding against potential breaches and maintaining the integrity of the codebase.\n* **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.\n* **Bypass functionality for flexibility:** For cases where false positives occur or when certain patterns are necessary, you can bypass push protection for users, and designated users can use the delegated bypass feature to bypass push protection for repositories. Additionally, you can exempt trusted actors from push protection entirely. This provides flexibility without compromising overall security.\n* **Ability to detect custom patterns (for repositories in organizations):** 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.\n\n## Customization\n\nAfter you enable push protection for repositories, you can customize it by:\n\n* Defining custom patterns to block pushes containing unique secret patterns\n* Designating contributors who can bypass push protection and approve bypass requests for other contributors, or are exempt from push protection entirely\n* Configuring which secret patterns are included in push protection at the enterprise or organization level\n\n## Next steps\n\nTo enable push protection:\n\n* **For a repository**, see [Enabling push protection for your repository](/en/code-security/secret-scanning/enabling-secret-scanning-features/enabling-push-protection-for-your-repository).\n* **For an organization or enterprise**, you need to apply a security configuration. See [Creating a custom security configuration](/en/code-security/how-tos/secure-at-scale/configure-organization-security/establish-complete-coverage/applying-the-github-recommended-security-configuration-in-your-organization) and [Creating a custom security configuration](/en/code-security/how-tos/secure-at-scale/configure-enterprise-security/establish-complete-coverage/applying-the-github-recommended-security-configuration-to-your-enterprise).\n\nFor a list of secrets and service providers supported by push protection, see [Supported secret scanning patterns](/en/code-security/secret-scanning/introduction/supported-secret-scanning-patterns#supported-secrets)."}