Ferramentas de DevSecOps para projetos de código aberto em JavaScript e Node.js

Neste artigo, quero propor boas práticas e discutir como mantenedores e desenvolvedores podem adotar ferramentas de DevSecOps em projetos de código aberto para fortalecer sua postura de segurança.

Não faltam incidentes de segurança e histórias assustadoras sobre pacotes maliciosos no ecossistema de código aberto do JavaScript. Como integrantes do ecossistema de código aberto, seja como mantenedores ou usuários de projetos, devemos dar a devida atenção à segurança do código aberto para garantir que ninguém fique exposto a riscos.

A seleção de ferramentas de DevSecOps e práticas de segurança a seguir se baseia na minha experiência na Snyk, trabalhando de perto com o projeto verdaccio, um proxy privado e registro npm leve. Especificamente, vamos abordar:

1. Adote uma política de divulgação responsável de vulnerabilidades e inclua-a nos seus projetos como parte das diretrizes de segurança.

2. Estabeleça um processo e diretrizes de segurança.

3. Garanta que todos os mantenedores e colaboradores ativem a autenticação de dois fatores (2FA) no GitHub e no registro npm.

4. Evite violações de dados e a exposição de informações confidenciais usando hooks de pré-commit do git para impedir que desenvolvedores revelem senhas e segredos ao fazer commit e push para um repositório.

5. Integre a análise e a correção de dependências de código aberto para evitar vulnerabilidades de segurança em pacotes de código aberto de terceiros. Integrar o Snyk ao fluxo de trabalho do git pode ajudar.

6. Use o Snyk Advisor para pesquisar e comparar mais de 1 milhão de pacotes de código aberto no registro npm e escolher o pacote npm certo.

Adote uma política de divulgação responsável de vulnerabilidades

Uma política de divulgação responsável de vulnerabilidades permite que pesquisadores de segurança e outros usuários relatem vulnerabilidades que afetam o projeto e gerenciem o processo em uma discussão privada, protegida de olhares indiscretos.

A discussão privada permite uma investigação mais aprofundada com todas as partes envolvidas — ou seja, o mantenedor e o pesquisador de segurança —, além da triagem da vulnerabilidade, da criação de uma prova de conceito e, por fim, da correção para remediar a vulnerabilidade.

Quando uma correção estiver disponível e tiver sido lançada há um período razoável, a vulnerabilidade poderá ser divulgada publicamente, e os usuários poderão atualizar o software para receber a correção de segurança.

Esse processo ajuda a proteger os usuários contra vulnerabilidades de segurança que seriam divulgadas sem coordenação prévia com o projeto.

Para entender melhor por que a divulgação responsável de vulnerabilidades é tão importante, confira Entenda a divulgação responsável. A equipe de pesquisa de segurança da Snyk oferece um programa para mantenedores de projetos de código aberto. Nossa equipe colabora na triagem da vulnerabilidade, no desenvolvimento de uma correção e na solicitação de um CVE. O programa está disponível para diversos ecossistemas de linguagens, como Node.js, Java, .NET, Python, Ruby, PHP e outros:/.

Estabeleça diretrizes de segurança

Um projeto deve contar com processos de segurança para que os membros da equipe respondam a incidentes e comuniquem aos pesquisadores de segurança seu nível de preparo em segurança e as políticas destinadas a eles.

As informações a seguir devem estar disponíveis:

1. Políticas de segurança do projeto, como quais vulnerabilidades são consideradas problemas de segurança e quais não são consideradas vulnerabilidades.

2. Uma política de divulgação responsável de vulnerabilidades ou referências a programas existentes que ofereçam esse suporte.

3. Informações de contato para falar com os responsáveis pela segurança do projeto. Recomendamos adotar os campos relevantes da especificação security.txt.

4. Evite o vazamento de segredos — sejam chaves de API, senhas ou outros segredos, eles podem acabar facilmente no controle de versão do código-fonte ou até em um pacote publicado no registro npm público.

Para facilitar a comunicação dessas informações, recomendamos disponibilizá-las em um arquivo SECURITY.md no diretório raiz do projeto.

Todos os colaboradores do projeto devem ativar a 2FA

Como mantenedores e colaboradores responsáveis por lançar versões seguras dos seus projetos, sem malware, devemos garantir que nossas contas não sejam comprometidas. Isso já aconteceu no npm, como no incidente de segurança do eslint-scope, no pacote npm mailparser e em outros casos.

Sim, pacotes já foram comprometidos e malware já foi inserido neles — e isso voltará a acontecer. Leia mais sobre o que é um backdoor e veja como é fácil criar um com Node.js e publicá-lo no npm.

Para minimizar o risco de invasão de contas e comprometimento de pacotes, garanta o seguinte:

1. Todos os colaboradores ativam a autenticação de dois fatores (ou outras formas de autenticação multifator) no repositório do código-fonte.

2. Todos os colaboradores com permissão para publicar o pacote ativam a autenticação de dois fatores no registro npm.

3. Não se esqueça de testar seus projetos para detectar backdoors conhecidos!

Evite violações de dados e a exposição de informações confidenciais

Um problema comum na gestão de repositórios públicos de projetos de código aberto é a facilidade com que senhas, chaves de API e outras informações confidenciais podem ser publicadas por engano.

Já vi isso acontecer várias vezes, tanto em projetos de código aberto quanto em projetos privados que adotam o modelo inner source — que também não estão imunes aos impactos do vazamento de segredos. Lembre-se: o git guarda tudo!

Como usar hooks do git

Você pode ter segredos no diretório de trabalho, em arquivos específicos como .env, que devem ser ignorados para não serem enviados a um SCM ou registro de pacotes. Mas erros acontecem, por isso precisamos de controles para nos preparar para essa possibilidade.

Há várias ferramentas excelentes que analisam estaticamente seus commits por meio de um hook de pré-commit do Git para garantir que você não esteja tentando enviar senhas ou informações confidenciais para o repositório do GitHub. Os commits serão rejeitados se a ferramenta encontrar correspondências com padrões de expressões regulares configurados para detectar informações confidenciais. Isso pode deixar os pushes um pouco mais lentos, mas vale muito a pena.

Você também pode usar ferramentas desse tipo nos pipelines de CI e CD, como o GitGuardian, para interromper automaticamente os builds quando informações confidenciais forem encontradas no código ou em um arquivo de configuração. Adotar regras para toda a equipe que evitem esse tipo de ocorrência é uma ótima maneira de coibir práticas inadequadas no fluxo de trabalho de desenvolvimento.

Por que isso é importante?

1. https://github.blog/2019-05-14-git-ransom-campaign-incident-report/

2. https://about.gitlab.com/2019/05/14/git-ransom-campaign-incident-report-atlassian-bitbucket-github-gitlab/

Como evitar o vazamento de senhas: a ferramenta detect-secrets

É essencial garantir que os mantenedores e desenvolvedores do projeto de código aberto Verdaccio para npm, usado para fornecer um registro npm privado e um servidor proxy, não vazem senhas nem informações confidenciais.

Juntei-me à equipe para colaborar em um Pull Request que adiciona uma ferramenta ao fluxo de trabalho de desenvolvimento, protegendo-a contra o vazamento de informações confidenciais para o controle de versão do código-fonte.

A escolha do projeto detect-secrets, da Yelp, se deve à flexibilidade para gerenciar um manifesto de segredos em um repositório e à arquitetura para auditar os segredos detectados. Isso permite gerenciar manifestos de segredos offline para rastrear e incluir itens na lista de permissões, além de aplicar medidas preventivas quando o usuário interage com o repositório git.

Modos de operação:

1. Medida preventiva: para impedir que usuários adicionem segredos ao controle de versão do código-fonte, o projeto oferece um executável detect-secrets-hook que recebe arquivos como argumentos e os verifica em busca de segredos. Ao detectar qualquer segredo, ele emite um alerta e interrompe o processo.

2. Verificação offline para auditoria e inclusão na lista de permissões: a medida preventiva descrita acima só é aplicada quando os commits são feitos e, portanto, só impede a inclusão de segredos a partir do momento em que é implementada. Uma verificação offline permite analisar todos os arquivos de um repositório git e criar uma linha de base dos segredos conhecidos. Assim, é possível auditar se são falsos positivos ou segredos que precisam ser removidos e revogados corretamente.

Os dois modos de operação são complementares e oferecem flexibilidade para adotá-los de forma independente, conforme as necessidades dos desenvolvedores.

Usar o detect-secrets como ferramenta nos hooks do git pode não ser adequado para todos os projetos, especialmente os de JavaScript e Node.js, porque a ferramenta exige um ambiente Python funcional. Se isso não causar problemas para o seu projeto, você pode instalá-la e começar a usá-la assim:

$ pip install --user detect-secrets

Outra opção é seguir este passo a passo para usá-la em projetos JavaScript e Node.js baseados em npm e evitar a exposição de informações confidenciais com o detect-secrets.

Para implementar uma medida preventiva de pré-commit para desenvolvedores JavaScript, vamos usar as duas dependências de projeto a seguir:

• O husky facilita o gerenciamento de hooks do git em projetos npm por meio de um manifesto no nível do projeto e de uma dependência npm que simplifica a gestão de hooks para desenvolvedores JavaScript com ferramentas que já conhecem.

• O lint-staged permite executar tarefas, como linters e formatadores, nos arquivos preparados para commit, para que eles sejam atualizados de acordo com as regras de conformidade predefinidas ao serem enviados ao controle de versão do código-fonte.

Observação: lint-staged é opcional, mas costuma ser uma dependência bastante comum em projetos JavaScript.

Depois de adicionar lint-staged e husky como dependências de desenvolvimento do projeto, você pode atualizar o package.json com a configuração necessária para o hook de pré-commit:

"husky": {
   "hooks": {
     "pre-commit": "lint-staged"
   }
 },
 "lint-staged": {
   "linters": {
     "**/*.js": [
       "detect-secrets-hook --baseline .secrets-baseline"
     ]
   }
 }

A partir daí, sempre que um arquivo for adicionado ou atualizado no controle de versão do git, ele será verificado em busca de informações confidenciais, como segredos, senhas e chaves de API, e a operação de commit no repositório será interrompida.

Observação: em monorepos com dependências husky e lint-staged instaladas em diretórios aninhados, e não no diretório de nível superior, será necessário atualizar a configuração do .git/ para contemplar essa situação com o lint-staged:

 "lint-staged": {
   "relative": true,
   "linters": {
     "**/*.js": [
       "detect-secrets-hook --baseline .secrets-baseline"
     ]
   }
 }

Linha de base dos segredos

Para garantir que todos os arquivos do repositório git tenham sido verificados em busca de possíveis segredos, fazemos uma verificação pontual:

detect-secrets scan > .secrets-baseline

Após a verificação, o resultado gerado serve como linha de base dos segredos permitidos em toda a base de código. Os resultados em JSON incluem metadados de todos os plug-ins usados, a data em que a verificação foi gerada, um hash do segredo e detalhes do arquivo onde ele foi encontrado.

Às vezes, strings parecidas com segredos aparecem em arquivos de documentação, como arquivos README. Nesse caso, é esperado que elas sejam enviadas ao controle de versão, pois não são segredos reais. Em outros casos, segredos de fato são encontrados e precisam ser tratados com segurança. Depois de resolver a situação, uma nova ação de scan gera uma nova linha de base sem os segredos removidos.

Para ajudar as equipes a remediar segredos encontrados na base de código, a ferramenta oferece o recurso audit, que percorre o arquivo da linha de base e pergunta interativamente se um segredo é um falso positivo — por exemplo, um segredo usado em arquivos de teste — ou um verdadeiro positivo. Nesse último caso, ele já está no controle de versão do código-fonte e precisa ser removido.

Integre o Snyk para desenvolver com agilidade e segurança

Como desenvolver com agilidade e segurança?

Mantenedores e colaboradores de projetos de código aberto costumam incluir pacotes de código aberto em seus projetos e, com o tempo, adicionar ainda mais dependências. Como saber se a próxima dependência que você adicionar não tem vulnerabilidades?

A equipe do Verdaccio criou uma integração com o git que integra o Snyk ao repositório do GitHub, oferecendo um fluxo de trabalho do git totalmente compatível com testes de segurança na CLI.

Quer começar a usar o Snyk rapidamente? Confira este guia e passe de iniciante a especialista em segurança. Melhor ainda: assista a um vídeo de 1 minuto e 35 segundos para começar a usar o Snyk rapidinho:

Play Video: Getting Started with Snyk: Import and Test a GitHub Repository

Use o Snyk Advisor para escolher o pacote certo

O projeto npm Verdaccio usa dependências como commander, mas, como desenvolvedor, como saber se o pacote npm commander é um projeto saudável?

Ainda bem que o Snyk Advisor ajuda você a pesquisar e comparar mais de 1 milhão de pacotes de código aberto e avaliar fatores importantes para a tomada de decisão, como manutenção, popularidade, comunidade e postura de segurança do projeto. Com essas informações, o Snyk Advisor calcula uma pontuação geral de saúde do pacote.

O Verdaccio também depende de cookies e cors. Que notas eles recebem? Vou deixar você descobrir!

Considerações finais

Em resumo, apresentamos várias ferramentas de DevSecOps e práticas de segurança que você pode usar como responsável pela manutenção de um projeto de código aberto ou como desenvolvedor que trabalha em um. As opções vão desde impedir que senhas vazem para o controle de código-fonte até testar e monitorar dependências em busca de vulnerabilidades e escolher o pacote npm certo com o Snyk Advisor.

Recomendo que você continue a leitura com:

• Hub de DevSecOps, para saber mais sobre as práticas de segurança adotadas por outras organizações, como Auth0 e Datadog. O hub também inclui análises aprofundadas de práticas de segurança, como modelagem de ameaças.

• Com Juan Picado, escrevemos as 10 práticas recomendadas de segurança para npm e um guia de consulta rápida. Você pode baixar um PDF ou ler o conteúdo no blog.

• É bem provável que você já tenha trabalhado com arquivos de lock em pacotes baseados em npm. Você sabia que arquivos de lock podem ser um ponto cego de segurança para a injeção de módulos maliciosos?