10 práticas recomendadas de segurança para Maven

Mais uma vez, estamos trazendo para você um guia com foco em segurança! Este mês, apresentamos 10 práticas recomendadas para você aprimorar seu domínio do Maven. O Maven é, sem dúvida, a principal ferramenta de build no ecossistema Java e JVM. *ALERTA DE SPOILER!* Os resultados da nossa pesquisa sobre o ecossistema JVM, que serão divulgados em outubro, mostram que o domínio do Maven continua em 2018 e não parece estar perto do fim: seis em cada dez desenvolvedores usam essa ferramenta de build em seu projeto principal, como mostra a imagem abaixo.

Este é o quinto guia que a Snyk publica neste ano (nossa, como o tempo voa!), depois de já termos criado guias sobre inferência de tipos em Java, práticas recomendadas de segurança para GitHub, Zip Slip e 10 práticas recomendadas de segurança para Spring Boot nos meses anteriores. Esta publicação foi idealizada em Creta, enquanto eu descansava na praia com o presidente do projeto Apache Maven, Robert Scholte. Sentados na gloriosa areia dourada e nadando nas belas águas quentinhas de Creta, criamos as 10 dicas de segurança a seguir — não diga que nunca fazemos nada por você.

1. Criptografe seus segredos

Desde o Maven 2.1.0, é possível criptografar senhas em máquinas de build compartilhadas. Quando vários usuários têm acesso a uma máquina compartilhada ou um arquivo settings.xml pode ser acessado por muitas pessoas, todos os segredos armazenados nele devem ser criptografados. Se você compartilha arquivos settings.xml com outros desenvolvedores, considere remover os segredos do arquivo para que somente usuários autorizados possam implantar artefatos do Maven nos repositórios, em vez de toda a equipe. Esses usuários autorizados teriam um arquivo settings-security.xml armazenado localmente na pasta de configurações do Maven ou em algum local privado. Se seus builds forem executados em um local compartilhado com toda a equipe, criptografe os segredos no arquivo settings.xml. Para isso, você precisará criar uma senha mestra que possa armazenar e compartilhar com segurança.

Você pode criar a senha mestra e as senhas dos servidores usando a CLI do Maven, executando o seguinte comando:

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-master-password
Master password:
{dDwpv7c3ZvAHBuXJjZrmz6nUaPrLK5Rt7F1n1N1FdZc=}

Depois de criada, armazene-a no arquivo ~/.m2/settings-security.xml da seguinte forma:

<settingsSecurity> <master>{dDwpv7c3ZvAHBuXJjZrmz6nUaPrLK5Rt7F1n1N1FdZc=}</master> </settingsSecurity>

Agora, você pode criar uma senha de servidor executando o seguinte comando:

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-password
Password:
{155kWnu2OdgHXof80X5kjyzhX/hAQbxNFCZtSE6aR7c=}

Armazene-a no arquivo settings.xml da seguinte forma:

<server> <id>my.server</id> <username>smaple</username> <password>Simon reset this password on 2019-03-11, expires on 2019-04-11 {155kWnu2OdgHXof80X5kjyzhX/hAQbxNFCZtSE6aR7c=}</password> </server>

Para saber mais, consulte a página da documentação do Maven sobre como armazenar segredos no arquivo settings.xml.

2. Não use senhas na CLI

No exemplo anterior, mostramos a maneira correta de incluir segredos nos arquivos de configuração. Mas também existe uma maneira errada, e queremos garantir que você saiba qual é para poder evitá-la! Uma opção antiga dos comandos da CLI mostrados acima é informar uma senha na linha de comando para os dois comandos de criptografia, como neste exemplo:

MacBook-Pro-33:~ simonmaple$ mvn --encrypt-master-password P@ssw0rd

Embora isso funcione e gere segredos criptografados, nunca digite seus segredos em texto simples na linha de comando. Eles ficam armazenados no histórico do console e podem ser recuperados facilmente.

3. Sempre use HTTPS

Os repositórios do Maven podem ser locais ou remotos. Os repositórios locais, geralmente encontrados no diretório ~/.m2/repository/ da sua máquina, armazenam em cache versões de projetos que você baixou anteriormente. Entre os repositórios remotos estão o Maven Central e um repositório configurado pela sua organização, usando o Artifactory ou uma ferramenta semelhante. Você pode ver quais repositórios seu build está usando consultando o elemento correspondente no arquivo pom.xml. Como acontece com a maioria das comunicações hoje em dia, é fundamental usar HTTPS ao se conectar a serviços de terceiros — e com os repositórios Maven não é diferente. Verificar se você está se comunicando com os servidores corretos reduz o risco de ataques man-in-the-middle ou, mais especificamente, de uma vulnerabilidade causada pelo download de recursos por um protocolo inseguro.

Para evitar isso, sempre se comunique com qualquer repositório por HTTPS, mesmo que ele seja hospedado pela sua própria organização. Para isso, verifique se os elementos correspondentes no arquivo pom.xml usam https nas URLs.

4. Verifique a integridade das dependências

O uso de dependências de terceiros em nossos aplicativos é extremamente comum, e muitas vezes os desenvolvedores as incluem sem pensar muito além de “isso funciona?”. Também é importante avaliar se a dependência é confiável o bastante para ser incluída no aplicativo. Para avaliar a saúde de um projeto do qual você está pensando em depender, considere:

Número de contribuidores ativos — Projetos de código aberto mantidos por apenas uma ou duas pessoas podem ser arriscados, pois dependem de uma única pessoa para atualizações e lançamentos. Uma equipe de contribuidores reduz significativamente esse risco.

Políticas de segurança documentadas — Disponibilizar um procedimento para que os usuários relatem problemas de segurança aumenta as chances de que eles sejam comunicados. Da mesma forma, oferecer um mecanismo para notificar os usuários sobre problemas de segurança e correções assim que surgirem permite que eles usem as dependências com mais segurança.

Atualizações e lançamentos regulares — Certifique-se de que os projetos dos quais você depende estão em desenvolvimento ativo. Isso ajuda no desenvolvimento futuro do seu próprio projeto, pois você sabe que suas dependências continuarão atualizadas com os recursos da linguagem e assim por diante. Do ponto de vista da segurança, também é importante saber que os problemas identificados serão corrigidos rapidamente.

5. Teste se há vulnerabilidades conhecidas

Os invasores estão mirando cada vez mais nas dependências de código aberto, pois a reutilização de bibliotecas oferece muitas vítimas em potencial para quem tenta explorar uma vulnerabilidade conhecida. É importante garantir que não existam vulnerabilidades conhecidas em toda a árvore de dependências do seu aplicativo.

Ferramentas como a Snyk sinalizam as dependências com vulnerabilidades conhecidas ao testar os artefatos do seu build Maven. Em um painel, elas mostram uma lista das vulnerabilidades presentes nos pacotes incluídos pelo arquivo pom.xml.

Além disso, a ferramenta sugere como corrigir os problemas, seja atualizando versões ou aplicando patches criados pela equipe de segurança da Snyk. Se você conectar sua ferramenta de gerenciamento de código-fonte, como GitHub, Bitbucket ou GitLab, por exemplo, poderá corrigir automaticamente os problemas de segurança por meio de uma solicitação pull/merge. A Snyk continua protegendo seu ambiente ao testar automaticamente, por meio de webhooks, todas as futuras solicitações pull/merge, para garantir que outros desenvolvedores não introduzam novas vulnerabilidades no projeto.

A Snyk está disponível na interface web e também na CLI, o que facilita a integração ao seu ambiente de CI e permite configurar a interrupção do build Maven quando houver vulnerabilidades acima do limite de gravidade definido por você.

Você pode usar a Snyk gratuitamente em projetos de código aberto ou em projetos privados com um número limitado de testes mensais.

6. Teste as somas de verificação

Uma soma de verificação serve para detectar erros que podem ocorrer durante a transmissão ou o armazenamento de dados. É importante verificar as somas de verificação das dependências de cada projeto. Elas costumam ser usadas para verificar a integridade dos dados e, embora não devam ser consideradas uma forma de confirmar a autenticidade das dependências, são uma proteção extra que ajuda. No Maven 4, as somas de verificação de todas as dependências serão testadas por padrão. Até lá, use a opção -C nos comandos do Maven para ativar esses testes, que interromperão o build se as somas não corresponderem.

$ mvn -C install // fail if checksums don’t match

$ mvn -c install // warn if checksums don’t match

7. Não use propriedades para senhas

No Maven, as propriedades são usadas com frequência como espaços reservados em arquivos pom.xml. Você pode definir uma propriedade — que chamaremos de my.property — no exemplo de arquivo pom.xml abaixo:

<properties>
  <my.property>value</my.property>
</properties>

Agora, você pode fazer referência à propriedade my.property em qualquer parte desse arquivo pom.xml usando a notação ${my.property}. Embora esse recurso seja muito útil, ele também facilita o armazenamento de senhas para uso em outros lugares. No entanto, isso significa armazenar senhas em texto simples e possivelmente compartilhá-las com toda a equipe. É recomendável que os plug-ins usem entradas de servidor do seu settings.xml.

8. Use desenvolvedores/funções do Maven

Como mostrou o relatório Segurança do código aberto, é importante fornecer às pessoas as informações necessárias para que possam relatar problemas de segurança. Repositórios do GitHub com um processo de divulgação de vulnerabilidades têm mais de três vezes mais chances de receber relatos de bugs de segurança do que repositórios sem um processo documentado.

No arquivo pom.xml do Maven, você pode adicionar uma tag de desenvolvedores com informações sobre os contatos de segurança, caso alguém da equipe precise ser contatado sobre um problema. Veja o exemplo abaixo, em que adiciono Danny, nosso responsável interno por segurança.

<developers>
    <developer>
      <id>grander</id>
      <name>Danny Grander</name>
      <email>danny@snyk.io</email>
      <organization>Snyk</organization>
      <organizationUrl>https://snyk.io</organizationUrl>
      <roles>
        <role>security</role>
      </roles>
    </developer>
  </developers>
  ...
</project>

De preferência, use um endereço de e-mail mais genérico, como security@yourdomain.com. Assim, se algo acontecer com o contato de segurança, a mensagem ainda chegará a uma caixa de entrada monitorada.

9. Mantenha-se atualizado

Como sempre, as atualizações de segurança chegam nas versões mais recentes. Por isso, tente manter o Maven atualizado. Assim, você reduz as chances de usar uma versão com uma falha de segurança. Em particular, evite o Maven 3.0.4, que contém um problema crítico de segurança e ignora certificados em conexões HTTPS. Para baixar a versão mais recente do Maven, acesse a página de downloads do Maven.

10. Consulte os boletins de segurança

A equipe do Maven publica boletins de segurança no site do Apache Maven para informar sobre problemas. Quando a equipe de segurança da Snyk encontrou recentemente vários casos da vulnerabilidade Zip Slip, a equipe do Apache (que trabalhou muito com a gente para eliminar casos de Zip Slip em projetos Apache) publicou um boletim no site do Apache Maven, conforme mostrado abaixo:

Não deixe de assinar a lista de e-mails announce@maven.apache.org e/ou seguir @ASFMavenProject no Twitter para acompanhar as últimas notícias do projeto Apache Maven.

E essas foram nossas 10 práticas recomendadas de segurança para o Apache Maven. Baixe este guia e deixe-o sempre à vista para se lembrar de pensar na segurança dos seus builds!

BAIXE O GUIA!

Imprima o guia e deixe-o em algum lugar visível para lembrar algumas das práticas recomendadas que você deve seguir ao desenvolver com Maven.