Guia rápido: 10 práticas recomendadas de segurança no Bitbucket

Neste guia rápido, mostramos como você pode usar o Bitbucket ou contribuir com mais segurança. Algumas recomendações são específicas do Bitbucket, mas muitas também são úteis para outros repositórios Git e não Git.

Baixar guia rápido

Vamos começar nossa lista com 10 práticas recomendadas de segurança no Bitbucket, começando pelo erro clássico de incluir senhas nos repositórios do Bitbucket!

1. Nunca armazene credenciais como código ou configuração no Bitbucket

Há várias ferramentas excelentes, como git-secrets, que analisam seus commits estaticamente por meio de um Git Hook de pré-commit para garantir que você não tente enviar senhas ou informações confidenciais para seu repositório do Bitbucket. Os commits são rejeitados quando a ferramenta identifica padrões de expressão regular configurados que indicam o armazenamento inadequado de informações confidenciais. Isso pode deixar os envios um pouco mais lentos, mas vale muito a pena.

Estabelecer regras para toda a equipe que impeçam o armazenamento de credenciais como código é uma ótima maneira de evitar práticas inadequadas no fluxo de trabalho de desenvolvimento existente. Use uma ferramenta como Vault para ajudar a gerenciar seus segredos em produção. Por fim, considere usar uma cadeia de ferramentas de gerenciamento de identidade e usuários, como Keycloak (mantido atualmente por vários desenvolvedores da Red Hat), entre outras.

A Atlassian oferece suporte à injeção de credenciais nos planos do Bitbucket por meio de variáveis de ambiente. No entanto, uma abordagem mais segura pode ser usar o ScriptRunner da Adaptavist como middleware para conectar sistemas de gerenciamento de credenciais e autenticação, como Vault e Keycloak.

Há muitas maneiras de evitar que credenciais sejam incluídas no repositório desde o início, e você deve tentar implementar o maior número possível. Ainda assim, informações confidenciais podem acabar escapando. Considere também fazer auditorias regulares dos seus repositórios com ferramentas como GitRob ou truffleHog, que examinam sua base de código e procuram informações confidenciais por meio da correspondência de padrões.

2. Remova dados confidenciais dos arquivos e do histórico do Bitbucket

Se encontrar dados confidenciais no seu repositório do Bitbucket, você precisará tomar algumas medidas para resolver a situação. Primeiro, invalide os tokens e as senhas que foram expostos. Quando um segredo é divulgado na internet, você deve presumir que está nas mãos de invasores e agir de acordo.

É claro que você também precisará remover esses mesmos dados confidenciais do repositório. Mas não se esqueça de que o Bitbucket mantém um histórico completo de todos os seus commits, incluindo registros de alterações que podem listar informações confidenciais. Ao remover dados confidenciais de um repositório, é importante limpar o histórico do Bitbucket. Para saber mais, consulte como remover arquivos do histórico do seu repositório. Embora o link seja do GitHub, as recomendações são válidas para qualquer repositório Git e também podem ser aplicadas ao Bitbucket. Você também pode usar o ScriptRunner para simplificar essas integrações.

3. Controle o acesso com rigor

Aqui no Reino Unido, quando faz muito, muito calor (ou seja, quando está só um pouco quente), nós, britânicos, costumamos abrir todas as janelas de casa para evitar que ela vire uma sauna. Mas, quando saímos, trancamos a porta da frente duas vezes, muitas vezes deixando várias janelas entreabertas para manter o ar circulando. É claro que isso não faz sentido: quem quiser invadir a casa não vai tentar entrar pela porta da frente! Vai procurar uma entrada menos óbvia, talvez escalar por uma das janelas convenientemente abertas. Muitas vezes, protegemos nossos aplicativos de forma parecida. Damos muita atenção aos vetores de ataque mais complexos, mas falhamos diante de alguns dos mais simples. Por exemplo, basta um desenvolvedor deixar a senha em um post-it preso ao monitor para que um invasor consiga acesso. Precisamos garantir que as configurações e práticas básicas sejam seguidas, tanto na plataforma Bitbucket quanto em geral. Exija que seus colaboradores adotem as seguintes práticas básicas:

1. Exija autenticação de dois fatores na conta do Bitbucket de cada colaborador.

2. Nunca permita que usuários do Bitbucket compartilhem contas ou senhas.

3. Todos os notebooks e dispositivos com acesso ao seu código-fonte devem estar devidamente protegidos.

4. Os administradores do repositório devem gerenciar o acesso da equipe aos dados. Conceda aos colaboradores acesso somente aos dados de que precisam para trabalhar.

5. As contas do Bitbucket podem ser pessoais e não são desativadas automaticamente quando alguém deixa a empresa. Revogue cuidadosamente o acesso ao Bitbucket de quem não trabalha mais com você.

O modelo de permissões de branch do Bitbucket permite controlar quem pode enviar commits para cada branch.

Você pode agendar uma tarefa do ScriptRunner para desativar usuários específicos do Bitbucket em uma data e hora determinadas, impedindo novos acessos ao Bitbucket Server. No exemplo abaixo, desativamos os usuários User e Contractor em 17 de agosto de 2018, às 9h. Na seção de observações, foi incluída a chave de uma solicitação do JIRA, ACCESS-1234, para identificar quem informou a alteração.

4. Adicione um arquivo SECURITY.md

É natural que a maioria dos proprietários e mantenedores de projetos adicione um README.md ao repositório. Hoje em dia, isso é esperado, e a ausência do arquivo costuma ser malvista. Da mesma forma, é cada vez mais comum adicionar um arquivo SECURITY.md com informações sobre a segurança do projeto. Além de fornecer aos usuários do seu projeto de código aberto informações de segurança importantes, esse arquivo também incentiva os mantenedores a pensar em como lidar com divulgações de vulnerabilidades, atualizações e práticas gerais de segurança.

Veja uma visão geral dos tópicos recomendados para incluir no arquivo SECURITY.md:

Política de divulgação

O relatório Estado da segurança do código aberto em 2017, da Snyk mostra que apenas 21% dos mantenedores que não têm uma política pública de divulgação foram notificados em particular sobre uma vulnerabilidade. Esse número sobe para 73% entre os mantenedores que têm uma política pública de divulgação. Isso demonstra a importância de definir um processo para que quem encontra um problema possa divulgar vulnerabilidades com responsabilidade. Esse processo deve indicar quem contatar e como. Isso é extremamente importante, pois permite receber feedback valioso dos usuários do projeto. Se não houver uma maneira fácil e bem definida de fazer algo, é fácil simplesmente deixar de fazer. Outras pessoas podem registrar a existência de uma vulnerabilidade como um problema público, informando o mundo antes que haja uma correção disponível. Dê aos usuários do seu projeto todas as orientações necessárias para que forneçam as informações certas aos mantenedores quando encontrarem problemas.

Política de atualizações de segurança

Vulnerabilidades de software são descobertas todos os dias. Quando uma vulnerabilidade é encontrada no seu aplicativo ou biblioteca, você tem a responsabilidade de informar os usuários do projeto. Eles podem estar usando seu código aberto em produção, em sistemas críticos. É necessário ter um processo bem definido para compartilhar as informações relevantes, incluindo a gravidade da vulnerabilidade, os riscos que ela representa e como atualizar para uma versão corrigida do código. Defina esse processo com antecedência para que as informações cheguem aos usuários do projeto e eles sejam avisados o quanto antes sobre novas vulnerabilidades de segurança, à medida que forem descobertas e corrigidas. Isso pode ser tão simples quanto uma lista de e-mails de segurança. O arquivo SECURITY.md é um bom lugar para incluir essas informações no repositório. Se você tiver um site, considere criar uma página específica — veja a página de segurança do Express.js como exemplo.

Configurações relacionadas à segurança

As considerações de segurança do seu projeto vão além do código. É provável que os usuários do seu projeto de código aberto precisem adicionar configurações para que ele funcione como necessário no ambiente deles. Forneça recomendações de configuração que fortaleçam a postura de segurança durante a implantação do projeto. Alguns exemplos são ativar o HTTPS, adicionar uma camada de autorização e, é claro, substituir as senhas padrão (uma orientação que muitos usuários do MongoDB gostariam de ter recebido). Lembre-se de que muitos usuários têm pouco conhecimento sobre segurança. Por isso, qualquer orientação que você puder oferecer será de grande ajuda.

Lacunas de segurança conhecidas e melhorias futuras

Há um equilíbrio entre fornecer aos usuários as informações necessárias para proteger o ambiente e dar a invasores sugestões de caminhos para ataques. Sempre considere como as informações que você compartilha podem ser usadas por ambos os lados. É muito raro que um projeto já tenha implementado todas as melhorias de segurança desejadas. É importante informar aos usuários do projeto quais controles de segurança ainda não foram implementados. Eles têm o direito de conhecer todos os detalhes para tomar decisões conscientes sobre como usar o projeto. Quem sabe, talvez até contribuam com a implementação de um controle de segurança listado!

5. Receba dicas de segurança no fluxo de trabalho com o Code Insights

O Code Insights foi criado para destacar informações relevantes em uma solicitação de pull, ajudando autores e revisores a tomar decisões mais bem fundamentadas. A Snyk oferece uma integração que analisa todas as solicitações de pull abertas para garantir que elas não introduzam novas vulnerabilidades de código aberto. Quando isso acontece, a integração pode bloquear a mesclagem da solicitação.

Se uma nova vulnerabilidade for encontrada, a Snyk avisa você e abre uma solicitação de pull de correção, com sugestões de atualização ou patches da Snyk para corrigir a vulnerabilidade.

Na interface de solicitações de pull do Bitbucket, as alterações são analisadas e os resultados aparecem em anotações detalhadas em linha, ao lado das alterações que introduzem novos problemas. Essas anotações facilitam a compreensão dos resultados da análise da Snyk e ajudam na tomada de decisões informadas.

Para saber mais sobre instalação e uso, confira esta publicação do blog da Snyk sobre o Bitbucket Code Insights, que inclui um vídeo demonstrativo!

6. Avalie cuidadosamente os aplicativos do Bitbucket

Toda boa plataforma pode ser ampliada, e o Bitbucket, com seu marketplace de aplicativos, não é exceção. Os aplicativos são desenvolvidos por organizações e desenvolvedores terceirizados; tenha isso em mente ao adicioná-los ao seu repositório. Ao selecionar e instalar aplicativos do Bitbucket, considere o seguinte:

• Não conceda aos aplicativos mais permissões de acesso do que o necessário.

• Questione por que um aplicativo precisa do nível de acesso solicitado e pense nos danos que ele poderia causar com essas permissões.

• Antes de conceder acesso aos seus repositórios, verifique se o autor ou a organização responsável pelo aplicativo é legítimo e confiável, assim como faria ao adicionar um novo colaborador ao projeto.

Sua segurança depende do elo mais fraco. Se um aplicativo ao qual você concedeu acesso tiver uma postura de segurança deficiente, uma invasão do código dele poderá dar aos invasores acesso ao seu código — um dos seus ativos mais confidenciais.

Por fim, monitore ou audite seus aplicativos e colaboradores periodicamente para confirmar que ainda precisa deles, continua confiando neles e considera justificadas as permissões de que necessitam. Acompanhe a gestão de aplicativos e remova os que não forem mais necessários ou exigirem permissões que você não se sinta confortável em conceder.

7. Inclua testes de segurança nas solicitações de pull

O Bitbucket conta com uma poderosa estrutura de Git Hooks orientada a eventos, que permite enviar solicitações HTTP POST para o serviço que você escolher quando determinados eventos ocorrem. Há muitos eventos que você pode escolher, mas um dos mais úteis para testar alterações incrementais no código é o evento pull_request. Muitas ferramentas de análise estática de código são compatíveis com Git Hooks: quando um PR é criado, uma solicitação HTTP POST é enviada para que elas testem suas atualizações mais recentes. Esse é um ótimo momento para garantir que as alterações no código e na configuração estejam alinhadas às suas expectativas de segurança.

Por exemplo, o Snyk analisa estaticamente seu repositório para encontrar dependências vulneráveis que você possa estar usando e ajuda a corrigi-las. Você pode testar seus repositórios pela interface do Snyk para encontrar problemas e também impedir que os desenvolvedores adicionem novas bibliotecas vulneráveis: basta testar os pull requests e reprovar o teste se uma nova vulnerabilidade for introduzida.

Além da integração prática com o Bitbucket, os pull requests são melhores do que “interromper o build” porque não precisam bloquear um merge — na verdade, por padrão, eles apenas fornecem informações — e permitem testar as alterações, não apenas o resultado. Por exemplo, o teste pode falhar somente se você introduzir uma biblioteca vulnerável, e não se ela já estiver presente.

Além do Snyk, considere também usar o SonarCloud ou o CodeClimate para automatizar revisões de segurança do código. Outra opção é adicionar um script do ScriptRunner para garantir que você não envie segredos para seu repositório.

8. Adicione testes de segurança aos seus pipes do Bitbucket

O Bitbucket Pipes permite personalizar e automatizar um fluxo de trabalho de CI/CD com um conjunto de tarefas prontas para uso. O Snyk oferece um pipe pronto para uso que verifica as dependências da sua aplicação e as imagens Docker em busca de vulnerabilidades de segurança conhecidas em software de código aberto, como parte do fluxo de integração e entrega contínuas (CI/CD).

Para adicionar o pipe do Snyk ao seu fluxo de trabalho, basta copiá-lo e colá-lo no pipeline.

Depois de adicionado ao fluxo de trabalho do Bitbucket Pipelines, o pipe do Snyk verifica suas dependências em busca de vulnerabilidades em software de código aberto como parte do fluxo de CI/CD. Se encontrar vulnerabilidades, o pipe do Snyk bloqueia o processo de acordo com as configurações que você definiu. Por exemplo, ele pode impedir que vulnerabilidades de alta gravidade avancem no build. Para saber mais, consulte a documentação.

Outro pipe que você pode incluir no pipeline para aumentar a resiliência da sua segurança é o SonarCloud.

9. Escolha a opção do Bitbucket mais adequada às suas necessidades de segurança

Dependendo das normas aplicáveis ao seu projeto ou à sua organização, você talvez só possa usar softwares executados localmente. Ou pode haver restrições sobre onde o código-fonte fica armazenado ou quais organizações podem acessá-lo. Essa é uma restrição comum em instituições financeiras, órgãos governamentais e outros setores altamente regulamentados. Mas isso não significa que você não possa usar o Bitbucket!

Conheça a opção Bitbucket Server totalmente local, que permite hospedar os repositórios do Bitbucket dentro da sua organização. Assim, você pode ficar desconectado da internet e ainda ter acesso interno aos seus projetos nos repositórios do Bitbucket Server.

10. Alterne as chaves SSH e os tokens de acesso pessoal

O acesso ao Bitbucket costuma ser feito por meio de chaves SSH ou tokens de usuário pessoais — em vez de uma senha, porque você ativou a autenticação de dois fatores (2FA). Mas e se esses tokens forem roubados sem que você saiba? Atualize suas chaves e seus tokens periodicamente para reduzir os danos causados por chaves que possam ter sido expostas.

Para saber mais sobre segurança no Bitbucket, leia também os avisos de segurança do Bitbucket. E, se ainda não fez isso, baixe esta folha de dicas agora e deixe-a à vista para tomar decisões mais seguras no futuro!