Skip to main content

Proteger pushes com digitalização de segredo

Você pode usar o varredura secreta para evitar que segredos compatíveis sejam enviados por push para a sua organização ou repositório, habilitando a proteção por push push.

Secret scanning for advanced security is available for organization-owned repositories in GitHub Enterprise Cloud if your enterprise has a license for Segurança Avançada GitHub. For more information, see "GitHub's products."

Note: Varredura secreta as a protection push is currently in beta and subject to change. To request access to the beta release, contact your account management team.

Sobre a proteção por push para segredos

Até agora, >- secret scanning for advanced security verifica segredos após um push e alerta usuários de segredos expostos. When you enable push protection, varredura secreta also checks pushes for high-confidence secrets (those identified with a low false positive rate). Varredura secreta lists any secrets it detects so the author can review the secrets and remove them or, if needed, allow those secrets to be pushed.

Varredura secreta como proteção por push atualmente verifica repositórios de segredos emitidos pelos seguintes prestadores de serviços.

ProviderSegredo compatívelSecret type
Adafruit IOChave de IO de Adafruitadafruit_io_key
Alibaba CloudID da chave de acesso da nuvem do Alibabaalibaba_cloud_access_key_id
Alibaba CloudSegredo da chave de acesso à nuvem do Alibabaalibaba_cloud_access_key_secret
AmazonAmazon OAuth Client IDamazon_oauth_client_id
AmazonAmazon OAuth Client Secretamazon_oauth_client_secret
Amazon Web Services (AWS)ID da Chave de Acesso do AWS da Amazonaws_access_key_id
Amazon Web Services (AWS)Chave de acesso secreta do AWS da Amazonaws_secret_access_key
Amazon Web Services (AWS)Amazon AWS Session Tokenaws_session_token
Amazon Web Services (AWS)Amazon AWS Temporary Access Key IDaws_temporary_access_key_id
AsanaAsana Personal Access Tokenasana_personal_access_token
AtlassianBitbucket Server Personal Access Tokenbitbucket_server_personal_access_token
AzureAzure Active Directory Application Secretazure_active_directory_application_secret
AzureAzure Cache for Redis Access Keyazure_cache_for_redis_access_key
AzureToken de acesso pessoal do Azure DevOpsazure_devops_personal_access_token
Checkout.comCheckout.com Production Secret Keycheckout_production_secret_key
ClojarsToken de implantação de Clojarsclojars_deploy_token
DatabricksToken de acesso de Databricksdatabricks_access_token
DigitalOceanDigitalOcean Personal Access Tokendigitalocean_personal_access_token
DigitalOceanDigitalOcean OAuth Tokendigitalocean_oauth_token
DigitalOceanDigitalOcean Refresh Tokendigitalocean_refresh_token
DigitalOceanDigitalOcean System Tokendigitalocean_system_token
DiscordToken de Bot de Discorddiscord_bot_token
DopplerToken pessoal de Dopplerdoppler_personal_token
DopplerToken de serviço de Dopplerdoppler_service_token
DopplerToken de CLI de Dopplerdoppler_cli_token
DopplerToken de SCIM de Dopplerdoppler_scim_token
DopplerDoppler Audit Tokendoppler_audit_token
DropboxToken de acesso à vida curta do Dropboxdropbox_short_lived_access_token
DuffelDuffel Live Access Tokenduffel_live_access_token
EasyPostEasyPost Production API Keyeasypost_production_api_key
FlutterwaveFlutterwave Live API Secret Keyflutterwave_live_api_secret_key
FullstoryFullStory API Keyfullstory_api_key
GitHubToken de acesso pessoal do GitHubgithub_personal_access_token
GitHubGitHub OAuth Access Tokengithub_oauth_access_token
GitHubGitHub Refresh Tokengithub_refresh_token
GitHubToken de acesso à instalação do aplicativo GitHubgithub_app_installation_access_token
GitHubChave privada de SSH do GitHubgithub_ssh_private_key
GoogleGoogle Cloud Storage Access Key Secretgoogle_cloud_storage_access_key_secret
GoogleGoogle Cloud Storage Service Account Access Key IDgoogle_cloud_storage_service_account_access_key_id
GoogleGoogle Cloud Storage User Access Key IDgoogle_cloud_storage_user_access_key_id
GrafanaGrafana API Keygrafana_api_key
HubspotChave da API de Hubspothubspot_api_key
IntercomIntercom Access Tokenintercom_access_token
JFrogJFrog Platform Access Tokenjfrog_platform_access_token JFrog
redirect.pizzaredirect.pizza API Tokenredirect_pizza_api_token Samsara

Habilitando varredura secreta como uma proteção por push

Para você usar varredura secreta como proteção por push, a organização ou repositório deverá ter Segurança Avançada GitHub e varredura secreta habilitados. Para obter mais informações, consulte "Gerenciando as configurações de segurança e análise para sua organização, "Gerenciando as configurações de segurança e análise do seu repositórioe "Sobre Segurança Avançada GitHub".

Os proprietários da organização, gerentes de segurança e administradores de repositórios podem habilitar a proteção por push para varredura secreta por meio da interface do usuário e da API. Para obter mais informações, consulte "Repositórios" e expanda as "Propriedades do objeto security_and_analysis " na documentação da API REST.

Habilitando varredura secreta como uma proteção por push para uma organização

  1. No GitHub.com, navegue para a página principal da organização.
  2. Abaixo do nome da sua organização, clique em Settings. Botão de configurações da organização
  1. In the "Security" section of the sidebar, click Code security and analysis.

  2. Under "Code security and analysis", find "Segurança Avançada GitHub."

  3. Em "Varredura secreta", em "Proteção push", clique em Habilitar todos. Captura de tela que mostra como habilitar a proteção push para varredura secreta para uma organização

  4. Opcionalmente, clique em "Habilitar automaticamente em repositórios privados adicionados ao varredura secreta."

Habilitando varredura secreta como uma proteção por push para um repositório

  1. No GitHub.com, navegue até a página principal do repositório.

  2. No nome do seu repositório, clique em Configurações. Botão de configurações do repositório

  3. In the "Security" section of the sidebar, click Code security and analysis.

  4. Under "Code security and analysis", find "Segurança Avançada GitHub."

  5. Em "Varredura secreta", em "Proteção de push", clique em Habilitar. Captura de tela que mostra como habilitar a proteção push para varredura secreta para um repositório

Usando varredura secreta como proteção por push da linha de comando

Ao tentar enviar um segredo compatível para um repositório ou organização com varredura secreta como uma proteção push habilitada, o GitHub bloqueará o push. Você pode remover o segredo do seu commit ou seguir um URL fornecido para permitir o push.

Até cinco segredos detectados serão exibidos por vez na linha de comando. Se um segredo específico já foi detectado no repositório e um alerta já existe, GitHub não bloqueará esse segredo.

Captura de tela que mostra que um push está bloqueado quando um usuário tenta fazer push de um segredo para um repositório

Se você precisar remover o segredo do seu último commit (ou seja, HEAD) no branch pressionado e quaisquer commits anteriores que contenham o segredo, você poderá remover o segredo de HEAD e, em seguida, fazer a combinação por squash dos commits entre quando o commit foi introduzido e a primeira versão do HEAD para a qual o segredo foi removido.

Atenção:

  • Se sua configuração do git é compatível com pushes para vários branches, e não apenas para o branch padrão, seu push pode ser bloqueado devido a novos refs indesejados. Para obter mais informações, consulte as opções push.default na documentação do Git.
  • Se varredura secreta vencer em um push, GitHub ainda executará uma digitalização após o push.

Permitindo que um segredo bloqueado seja enviado por push

Se GitHub bloquear um segredo que você acredita ser seguro enviar por push, você poderá permitir o segredo e especificar a razão pela qual ele deve ser permitido.

Se você confirmar que um segredo é real e pretender corrigi-lo mais tarde, você deverá procurar remediar o segredo o mais rápido possível. Por exemplo, você pode revogar o segredo e remover o segredo do histórico de commit do repositório. Para obter mais informações, consulte "Removendo dados confidenciais de um repositório".

Quando você permite que um segredo seja feito push é criado um alerta na guia "Segurança". 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. Para obter mais informações, consulte "Gerenciando alertas da digitalização do segredo".

  1. Acesse o URL retornado por GitHub quando seu push foi bloqueado. Captura de tela que mostra o formulário com opções para desbloquear o push de um segredo
  2. Escolha a opção que melhor descreve por que você deve ser capaz de enviar por push o segredo.
    • Se o segredo é usado apenas em testes e não apresenta nenhuma ameaça, clique em É usado em testes.
    • Se a seqüência de caracteres detectada não é um segredo, clique É um falso-´positivo.
    • Se o segredo é real mas você pretende corrigi-lo mais tarde, clique em Eu vou corrigi-lo mais tarde.
  3. Clique Me permite enviar por push este segredo.
  4. Tente novamente na linha de comando em três horas. Se não enviou por push em três horas, você terá de repetir este processo.

Usando a digitalização de segredo como uma proteção de push da interface de usuário web

Ao usar a interface de usuário web para tentar confirmar um segredo suportado para um repositório ou organização com digitalização de segredo como uma proteção de push habilitada GitHub bloqueará o commit. Você verá um banner no topo da página com informações sobre a localização do segredo, e o segredo também será sublinhado no arquivo para que você possa encontrá-lo facilmente.

Captura de tela que mostra o commit na interface de usuário da web bloqueado devido à proteção de push da digitalização de segredo

GitHub só exibirá um segredo detectado por vez na interface do usuário. Se um segredo específico já foi detectado no repositório e um alerta já existe, GitHub não bloqueará esse segredo.

Você pode remover o segredo do arquivo usando a interface de usuário da web. Depois de remover o segredo, o banner no topo da página mudará e dirá que agora você pode fazeer commit das suas alterações.

Captura de tela que mostra o commit na interface de usuário da web, permitido após correção do segredo

Ignorando a proteção de push para um segredo

Se GitHub bloquear um segredo que você acredita ser seguro enviar por push, você poderá permitir o segredo e especificar a razão pela qual ele deve ser permitido. Se você confirmar que um segredo é real e pretender corrigi-lo mais tarde, você deverá procurar remediar o segredo o mais rápido possível.

Quando você permite que um segredo seja feito push é criado um alerta na guia "Segurança". 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. Para obter mais informações, consulte "Gerenciando alertas da digitalização do segredo".

Se você confirmar que um segredo é real e pretender corrigi-lo mais tarde, você deverá procurar remediar o segredo o mais rápido possível.

  1. No banner que apareceu na parte suérior da página quando GitHub bloqueou o seu commit, clique em Ignorar proteção.

  2. Escolha a opção que melhor descreve por que você deve ser capaz de enviar por push o segredo.

    • Se o segredo é usado apenas em testes e não apresenta nenhuma ameaça, clique em É usado em testes.
    • Se a seqüência de caracteres detectada não é um segredo, clique É um falso-´positivo.
    • Se o segredo é real mas você pretende corrigi-lo mais tarde, clique em Eu vou corrigi-lo mais tarde.

    Captura de tela que mostra o formulário com opções para desbloquear o push de um segredo

  3. Clique Permitir segredo.