Adicione um arquivo SECURITY.md ao Azure Repos
Edward Thompson
6 de maio de 2019
0 minutos de leituraEsta publicação destaca a prática recomendada nº 4 — adicionar um arquivo SECURITY.md aos seus repositórios — da nossa série com 8 práticas recomendadas de segurança para o Azure Repos.
Adicione um arquivo SECURITY.md ao Azure Repos
É natural que a maioria dos responsáveis por projetos e mantenedores adicione um README.md ao repositório. Na verdade, hoje isso é esperado, e a ausência desse arquivo costuma ser malvista. Da mesma forma, está cada vez mais comum adicionar um arquivo SECURITY.md com informações de segurança do projeto. Além de fornecer aos usuários do seu projeto de código aberto informações importantes sobre segurança, ele também leva 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 Snyk State of Open Source Security de 2017 mostra que apenas 21% dos mantenedores sem uma política pública de divulgação foram avisados 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 procedimento para que quem relata um problema possa divulgar vulnerabilidades com responsabilidade. Esse procedimento deve indicar quem contatar e como. Isso é extremamente importante, pois permite receber feedback valioso dos usuários do seu projeto. Se não houver uma maneira simples e bem definida de fazer algo, é fácil acabar não fazendo nada. Outras pessoas podem registrar a existência de uma vulnerabilidade como um problema público, revelando-a inadvertidamente antes que uma correção esteja disponível. Oriente os usuários do seu projeto sobre as informações que devem fornecer aos mantenedores quando encontrarem problemas.
Política de atualização de segurança. Novas vulnerabilidades de software são descobertas todos os dias. Quando uma vulnerabilidade é encontrada no seu aplicativo ou biblioteca, você tem a responsabilidade de avisar os usuários do projeto. Eles podem estar usando seu código aberto em produção, em sistemas críticos. É preciso 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 seu 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 são descobertas e corrigidas. Isso pode ser tão simples quanto uma lista de e-mails sobre segurança. O arquivo SECURITY.md é um bom lugar para essas informações no repositório. Se você tiver um site, considere criar uma página independente para isso — veja como exemplo a página de segurança do Express.js.
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 ao projeto para que ele funcione como esperado no ambiente deles. Sugira configurações que reforcem a segurança quando o projeto for implantado. 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, então qualquer orientação que você puder oferecer será de grande ajuda.
Lacunas de segurança conhecidas e melhorias futuras. Existe um equilíbrio entre fornecer aos usuários as informações necessárias para proteger o ambiente e ajudar um invasor, sugerindo possíveis caminhos de ataque. Pense sempre em como as informações compartilhadas podem ser usadas por ambos os lados. É raro que um projeto já tenha implementado todas as melhorias de segurança desejadas. É importante informar aos usuários 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, eles até contribuam com a implementação de algum controle de segurança listado!
Continue lendo a lista das 8 práticas recomendadas de segurança para o Azure Repos:
Nunca armazene credenciais como código ou configuração no Azure Repos
Remova dados confidenciais dos arquivos e do histórico do Azure Repos
Se ainda não fez isso, baixe agora este guia de consulta rápida e deixe-o à vista para tomar decisões seguras no futuro.
