Código Seguro Sem Dores. Tem como?
A evolução dos métodos, tecnologias e habilidades para desenvolvimento de aplicações e suas infraestruturas fizeram até mesmo com que algumas empresas e times de Tech deixassem segurança para depois. Acredito que isso foi causado pelo tipo de trabalho tradicional dos times de segurança, quando lidavam muito forte com a centralização, controles e filtros. Algumas empresas ficam até mesmo sem um time de segurança por imaginarem que a velocidade das mudanças seria afetada. E isso, de certa forma, não é verdade?
TLDR: Não seja o chatão de Sec que quer fazer tudo sozinho, centralizando 600 responsabilidades: dê conhecimento aos desenvolvedores, implante serviços automáticos que incluam segurança no dia-a-dia sem criar dores e notifique os interessados. Mais transparência e participação os envolverá mais e deixará tudo mais simples e ágil (além de seguro).
Mas, vamos lá: por que não utilizar da evolução das esteiras para fazer com que a Segurança seja algo mais simples e dinâmico? Será que não conseguimos desvincular a ideia de que ela é algo adicional e posterior ao nosso trabalho e começar a olhar para o que já fazemos com mais segurança? “OK, parece uma boa ideia. Mas como?”.
Antes de falar do “como”, vamos falar de exemplos para deixar a ideia mais clara: Uma aplicação que frequentemente fica indisponível para o cliente, é uma aplicação que tem qualidade? Lembra dos 3 pilares fundamentais para a segurança? Confidencialidade, Integridade e Disponibilidade (CID). Se concordar com isso, logo vai ver que Segurança neste caso nada mais é que a própria Qualidade, elas estão absolutamente vinculadas, não independentes.
Quando falamos de DevOps também temos um dilema para a inclusão da segurança: Seria DevSecOps ou SecDevOps? Não sei, pode chamar de SecDevSecOpsSec se quiser, desde que seja funcional e torne nossas vidas mais fáceis e nossas apps mais seguras, isso não tem a menor relevância. E já estou puxando assunto de DevOps para falarmos de como, na prática, podemos incluir a tal “Sec” nesse belo ciclo de “Dev”.
Voltando ao “como”, ele é muito particular e pode funcionar diferente em diferentes empresas, mas vou deixar aqui três palavras que resumem bem um método de como deixar a segurança mais simples e no dia-a-dia do “dev”: Serviço, Transparência e Educação.
Serviço: Precisamos de ferramentas, de automação na esteira de desenvolvimento que fazem varreduras nos códigos, nos containers, nas Libs e tragam para os desenvolvedores todos os achados que devem ter atenção para melhoria da segurança. O principal aqui é não mudar o dia a dia de ninguém, mas deixar as coisas fluidas e automáticas. Esse será o principal item desse artigo pois, mais pra frente, falaremos sobre como podemos fazer isso no GitHub. \o/
Transparência: Se você tem tecnologias que vão apontar as falhas e também um time integrado, esse mesmo time também precisará ter acesso aos achados. Que tal trocar os Reports periódicos de 10 páginas que chegam para os times por algo em tempo real como todo o resto da esteira? Notificar o time em tempo real, em cada etapa do fluxo, dando o máximo de transparência parece uma jogada interessante para correções também mais rápidas. Muitaz vezes só de ter um canal centralizando alertas, alguém de outro time pode se sentir pronto para aplicar uma correção, tornando a tarefa mais colaborativa, mais rápida e levando aprendizado aos demais. Essa pode ser uma forma do tema estar no dia-a-dia, todos juntos com suas próprias responsabilidades sobre o tema.
Educação: Se você quer menos retrabalho, quer evitar que Quality Gates interrompam um fluxo ágil e ao mesmo tempo não pensa em ter uma equipe de DevSec que sozinha consiga corrigir código, esse é um item crucial. Treine os desenvolvedores, fale sobre como “codar” mais seguro, escolham e deixem à disposição frameworks e guias de referências em segurança para consulta e disponibilize soluções que os apoiem com feedbacks em tempo de desenvolvimento e deploy. Não adianta apontar para vulnerabilidades se a galera não souber o que fazer! Dando conhecimento o output dos serviços implantados será mais inteligível, as correções tenderão a ser mais rápidas e seu time inteiro de Dev será DevSec.
Algumas referências OWASP:
Guia de desenvolvimento seguro
As Vulnerabilidades mais importantes
Opa! Prometi falar de serviços para o GitHub, certo?
Então vamos lá, vou trazer alguns exemplos de ferramentas para transformar parte desse blábláblá em realidade, dessa vez utilizando o GitHub Actions com outras dicas sobre a segurança dos nossos queridos códigos:
- SonarCloud: Serviço com foco em qualidade mas que, olha só, tem feature para scan de segurança, inclusive englobando o OWASP Top Ten. Infelizmente fraquinho para algumas linguagens, como Go, mas nada que não possa ser incrementado com outras ferramentas (Gosec, Bandit…) ou substituído por ferramentas com foco em Segurança em Código Estático (SAST), como o Veracode, mas daí já mudamos o investimento. O potencial é muito interessante, pois você só precisa ativar o serviço integrando ao GitHub e habilitar o scan para os repositórios. Feito isso, todo Pull Request terá feedback por comentário, com notas de qualidade para cada item e com base no Quality Profile selecionado. Para quem prefere manter serviço interno, a opção é o SonarQube. Legal que além de uma boa API, ambos possuem SSO com GitHub :D
2. SonarLint: Esse é um plugin incrível! Tendo SonarCloud ou SonarQube você o instala na sua IDE e, em tempo de desenvolvimento, vai recebendo insights de onde pode melhorar a qualidade/segurança do seu código. Disponível para JetBrains, Eclipse, Visual Studio e VSCode. Nada melhor do que já abrir um PR bonito, né?
3. Gitleaks: Quem nunca viu uma Secret, um Token ou até uma senha “commitada” em um repo? Pra esses casos nós temos esse lindo projeto. O GitLeaks faz scan de todo commit para, através de Regex, buscar por coisas que não deveriam estar em texto plano nos nossos repositórios.
4. DependaBot: Esse é nativo do GitHub e aponta quais Libs do seu código possuem vulnerabilidades. Dá pra ativar por “default” pra todos os repos, tem automação para abrir PR de update da Lib para uma versão corrigida e você pode consultar os itens via API para integrações customizadas.
5. GoSec: Falei anteriormente que o SonarCloud não é tão bom para algumas linguagens como o GO, por exemplo. Uma boa forma de incrementar um SAST para este caso é o GoSec, pois mesmo que seja uma ferramenta a mais ela será transparente, pois o report gerado por ela pode ser enviada através da sua action para o próprio Sonar. Todos os achados, tanto do SonarCloud quanto do GoSec vão subir como um só. Coisa Linda! Dica de como fazer isso: Desative o Scan automático do SonarCloud para o Repo em questão e crie uma action para rodar primeiro o GoSec e só depois o Sonar, assim poderá utilizar o parâmetro “-Dsonar.externalIssuesReportPaths=” para enviar o report do GoSec.
6. Aqua Trivy: Essa é uma ferramenta que vai fazer scan em busca de vulnerabilidades no container da sua aplicação. Existem outras ferramentas que fazem o mesmo, mas acho interessante esta pois existem parâmetros que ajudam bastante, como: se a action deve falhar, falhar em uma severidade específica, algumas formas diferentes de output e se ele deve fazer scan também nas Libs ou apenas no SO. Pra evitar duplicatas com o Dependabot, deixe apenas para o SO.
7. Dockle: Esse é um Linter que também olha para aspectos de Segurança do seu Dockerfile, por isso acredito que é um complemento bem interessante que tem um report bem amigável!
Olha só como tudo isso se encaixa no fluxo:
Claro que focamos aqui em código, em prevenção, não falamos sobre DAST (Dynamic application security testing), mas tendo essas ferramentas ou correlatas já teremos cobertura em segurança para: Nossos códigos, as dependências desses códigos, nosso dockerfile e o SO do nosso container, o que já nos dá uma excelente visibilidade.
Existem muitas formas de levar Educação para os Devs, diversas outras ferramentas para análise e transparência via comunicadores, mas o intuito aqui é demonstrar o conceito de uma forma simples, de baixo custo e principalmente tentar demonstrar que é possível levar segurança para nossos processos dinâmicos de desenvolvimento de software sem grandes dores e de forma colaborativa.
Bônus:
Action para criar issue no jira: https://github.com/marketplace/actions/jira-create-issue
Action para enviar mensagem no slack: https://github.com/marketplace/actions/slack-send
