Por que as ferramentas SAST com foco no desenvolvedor são o futuro da segurança de código

Segurança de aplicações abrange muitas áreas para equipes que desenvolvem e entregam aplicações nativas da nuvem. Esse cenário inclui diversos processos, ferramentas e profissionais, desde a automação de pipelines seguros (olá, DevSecOps) até a segurança de código aberto e os testes de segurança da infraestrutura em nuvem. Algumas dessas metodologias de teste de segurança de aplicações têm foco na segurança de código e são oficialmente conhecidas como ferramentas de teste estático de segurança de aplicações (SAST) — às vezes chamadas de ferramentas de análise estática de código.

Se você não conhece o termo técnico SAST, vamos começar com uma introdução aos conceitos básicos e, em seguida, entender como as ferramentas SAST com foco no desenvolvedor vão moldar todo o setor de segurança.

O que são ferramentas SAST?

As ferramentas SAST são ferramentas de teste estático de segurança de aplicações que analisam o código-fonte para acompanhar o fluxo de dados desde possíveis pontos de entrada de dados do usuário até operações sensíveis de interfaces de programação de aplicações. Por exemplo, uma ferramenta SAST pode identificar se uma entrada do usuário em um campo de busca poderia acionar uma função relacionada ao banco de dados que executa uma consulta de forma não sanitizada, insegura e não prevista (ou seja, uma vulnerabilidade de segurança de injeção de SQL).

Ferramentas SAST convencionais e por que elas falharam

O teste estático de segurança de aplicações não é um conceito novo. Na verdade, muitas ferramentas e empresas começaram a atuar nessa área há décadas. Para entender como será o futuro da segurança de código, primeiro precisamos analisar como as ferramentas SAST convencionais funcionam e por que elas não são adotadas com a frequência que gostaríamos.

As ferramentas SAST tradicionais são lentas

Em equipes convencionais de segurança e DevOps, não é raro ouvir comentários como: “A ferramenta SAST está demorando demais” ou “Integração contínua? Mais parece uma espera sem fim até a ferramenta SAST terminar!”. Tornou-se comum as ferramentas SAST levarem horas — ou dias — para analisar repositórios de código-fonte durante a etapa de build ou de integração contínua (CI).

Foram feitos alguns ajustes para atender à necessidade de resultados mais rápidos, como trabalhar com diferenças no código-fonte ou programar a execução do job de CI da ferramenta SAST para a noite ou o fim de semana. No entanto, são soluções paliativas que mostram que a ferramenta é inadequada e não consegue acompanhar os processos e as expectativas do desenvolvimento moderno.

A segurança costuma ficar no lugar errado no SDLC

Para lidar com o ciclo de feedback demorado mencionado anteriormente, as ferramentas SAST eram implementadas como um processo de CI separado, para não bloquear os desenvolvedores com análises longas. Mas esse equívoco de integrar ferramentas SAST à CI vai totalmente contra a intenção original, pois as ferramentas SAST devem se concentrar no código-fonte. Isso significa que as ferramentas SAST devem ser usadas durante o desenvolvimento do software, e não apenas como uma etapa posterior, revisada somente na CI.

Integrar ferramentas de segurança aos processos de build e de integração contínua é uma ótima maneira de incorporar segurança. Mas, para não prejudicar a produtividade dos desenvolvedores, essas ferramentas precisam ser rápidas e oferecer feedback que ajude a agir.

Falsos positivos levam ao abandono das ferramentas SAST

Outro grande problema para quem adota ferramentas SAST é a precisão — ou, mais especificamente, a falta dela. As ferramentas SAST tradicionais tendem a gerar alertas falsos em excesso, provocando notificações desnecessárias. Alertas de segurança exigem atenção total dos desenvolvedores e, quando muitas dessas notificações são falsos positivos, o desenvolvimento de fato fica mais lento.

Os falsos positivos geram frustração e criam atritos com a equipe de segurança de aplicações. No fim, os desenvolvedores passam a ignorar todos os alertas de segurança e abandonam a ferramenta.

As ferramentas SAST tradicionais encontram problemas, mas não sabem corrigi-los

Por fim, mesmo quando as descobertas de uma ferramenta SAST são precisas, ela ainda não explica como corrigir o problema. Isso tem origem na forma como essas ferramentas foram projetadas. No início, as ferramentas SAST eram desenvolvidas pensando na equipe de segurança, em AppSec e áreas semelhantes. Com isso, as descobertas podiam não trazer contexto sobre o fluxo de execução ou simplesmente indicar o problema com um código CWE (sigla de Common Weakness Enumeration, uma descrição de uma possível vulnerabilidade). Mas, se você não fosse especialista em segurança, a ferramenta SAST não ajudaria a resolver o problema nem a corrigir a vulnerabilidade.

Quem conseguia resolver os problemas de segurança eram especialistas em segurança de aplicações e a comunidade da área, o que criava mais um gargalo para tratar dessas questões. Isso também aumentava a frustração dos desenvolvedores, que recebiam os resultados de uma análise SAST, mas não conseguiam agir para corrigir os problemas.

As ferramentas SAST modernas com foco no desenvolvedor precisam aumentar a produtividade

Em sua essência, uma ferramenta SAST tem foco na segurança de código. Ela encontra problemas como exposição de dados confidenciais, injeção de SQL, injeção de código e outros tipos de vulnerabilidade. Quem introduziu esses problemas de segurança? Desenvolvedores como você e eu. Então, quem deve corrigi-los? Isso mesmo: os próprios desenvolvedores.

O foco no desenvolvedor é o segredo das melhores ferramentas SAST, e é assim que a Snyk está revolucionando o setor de segurança de aplicações. A Snyk nasceu com essa mentalidade.

Vamos explorar o que uma ferramenta SAST precisa oferecer para criar uma experiência de segurança produtiva para os desenvolvedores

Segurança de código integrada aos fluxos de trabalho dos desenvolvedores

Se os desenvolvedores são essenciais para corrigir vulnerabilidades de segurança, um recurso fundamental de uma ferramenta SAST é se integrar da forma mais simples possível ao trabalho deles.

Onde os desenvolvedores passam a maior parte do tempo (além do Google e do StackOverflow)?

1. No ambiente de desenvolvimento integrado (IDE), como IntelliJ ou Visual Studio Code

2. Na interface de linha de comando (CLI), onde podem interagir com repositórios Git, executar comandos, depurar e gerenciar o código-fonte e as rotinas dos projetos

3. Nas atividades de revisão de código

Para serem adotadas, as ferramentas SAST precisam ajudar os desenvolvedores a encontrar e resolver problemas de segurança diretamente nas ferramentas que já usam. Os resultados também precisam trazer bastante contexto, para que os desenvolvedores possam encontrar e corrigir vulnerabilidades de segurança no código.

Para quem passa o dia em uma IDE, veja a Snyk Code em ação: a ferramenta SAST integrada perfeitamente ao fluxo de trabalho:

À esquerda, há uma lista de possíveis vulnerabilidades causadas por práticas de codificação inseguras. À direita, no painel inferior, há contexto linha a linha que mostra como um fluxo de dados vulnerável pode ocorrer e ser explorado.

Se você é um desenvolvedor que prefere passar a maior parte do tempo em interfaces de terminal, uma interface de linha de comando pode ser mais adequada. Nesse caso, você pode usar a CLI da Snyk Code exatamente para isso.

Na verdade, se você gosta de hooks do Git — para executar um linter, uma suíte de testes ou outras automações antes que os desenvolvedores façam commit ou push do código —, também pode usar a CLI da Snyk para isso.

Veja abaixo o resultado de um teste de segurança de código executado com a CLI da Snyk no mesmo projeto:

❯ snyk code test

Testing /Users/lirantal/projects/repos/goof ...

 ✗ [Medium] Cleartext Transmission of Sensitive Information
     Path: Users/lirantal/projects/repos/goof/app.js, line 12
     Info: http (used in require) is an insecure protocol and should not be used in new code.

 ✗ [Medium] Information Exposure
     Path: Users/lirantal/projects/repos/goof/app.js, line 27
     Info: Disable X-Powered-By header for your Express app (consider using Helmet middleware), because it exposes information about the used framework to potential attackers.

 ✗ [Medium] Allocation of Resources Without Limits or Throttling
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 77
     Info: This endpoint handler performs a system command execution and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.

 ✗ [Medium] Allocation of Resources Without Limits or Throttling
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 166
     Info: This endpoint handler performs a file system operation and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.

 ✗ [Medium] Allocation of Resources Without Limits or Throttling
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 223
     Info: This endpoint handler performs a file system operation and does not use a rate-limiting mechanism. It may enable the attackers to perform Denial-of-service attacks. Consider using a rate-limiting middleware such as express-limit.

 ✗ [High] SQL Injection
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 39
     Info: Unsanitized input from the HTTP request body flows into find, where it is used in an SQL query. This may result in an SQL Injection vulnerability.

 ✗ [High] Command Injection
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 86
     Info: Unsanitized input from the HTTP request body flows into child_process.exec, where it is used to build a shell command. This may result in a Command Injection vulnerability.

 ✗ [High] Cross-site Scripting (XSS)
     Path: Users/lirantal/projects/repos/goof/routes/index.js, line 109
     Info: Unsanitized input from the HTTP request body flows into send, where it is used to render an HTML page returned to the user. This may result in a Cross-Site Scripting attack (XSS).

✔ Test completed

Test type:         Static code analysis
Project path:      /Users/lirantal/projects/repos/goof

8 Code issues found
3 [High]  5 [Medium]

Resultados de análise de segurança em tempo real

Para que uma ferramenta SAST seja compatível com qualquer um dos fluxos de trabalho dos desenvolvedores mencionados acima, ela precisa ser rápida o bastante para fornecer resultados de análise de segurança em tempo real. A velocidade ajuda a adotar práticas de codificação segura desde o início. Assim, os desenvolvedores podem encontrar e corrigir problemas de segurança enquanto escrevem código, em vez de depender da equipe de segurança ou de uma integração de DevSecOps para encontrá-los somente depois do envio do código. Isso pode gerar ainda mais frustração, pois o código precisará ser refatorado, causando retrabalho desnecessário e atrasando a entrega das mudanças.

Nossa abordagem sem atritos para a codificação segura torna a Snyk Code única e ajuda a se destacar como ferramenta de análise estática de segurança de código. Qual é a velocidade da Snyk Code? Experimente e confira.

Alta precisão, poucos falsos positivos

Fluxos de trabalho integrados e ciclos de feedback rápidos são importantes, mas um aspecto essencial de uma boa experiência para desenvolvedores costuma passar despercebido: os próprios dados.

Para adotar e incorporar plenamente as ferramentas aos seus fluxos de trabalho, os desenvolvedores precisam confiar nelas. A qualidade dos dados de segurança apresentados por uma ferramenta SAST determina se os desenvolvedores vão integrá-la com confiança ou abandoná-la por causa do grande volume de falsos positivos.

Para alcançar uma precisão de ponta no setor, a Snyk Code conta com aprendizado de máquina treinado com problemas reais de segurança de código encontrados em todos os projetos de código aberto do GitHub. Assim, consegue aplicar esse conhecimento para identificar padrões no seu código. Para aprimorar ainda mais o treinamento desses modelos de aprendizado de máquina, o mecanismo de IA da Snyk Code usa o banco de dados de vulnerabilidades da própria Snyk, selecionado manualmente, e commits de referência como conjunto de treinamento. Tudo isso ajuda a reduzir significativamente os falsos positivos.

Capacitar os desenvolvedores a corrigir problemas de segurança de código

Uma discussão no StackOverflow é a melhor amiga de um desenvolvedor, certo? Estou brincando — só em parte. Os desenvolvedores valorizam exemplos úteis que mostram como outras pessoas resolvem problemas de código. Então, por que os problemas relacionados à segurança seriam diferentes?

Vamos ver um exemplo em que uma ferramenta SAST sinaliza uma possível vulnerabilidade de injeção de comandos, identificada muitas vezes como CWE-78: neutralização inadequada de elementos especiais usados em um comando do sistema operacional (injeção de comandos do sistema operacional). É um nome e tanto, não é? Em geral, os desenvolvedores não têm o conhecimento de segurança necessário para entender CVEs, CWEs, seu impacto ou até mesmo como corrigi-las seguindo práticas de codificação segura. A Snyk assumiu o desafio de resolver esse problema.

É bem possível que você, como desenvolvedor, não tenha experiência em segurança para corrigir o problema de injeção de comandos na linha 86, que usa uma API insegura do Node.js: exec(). Então, o que você faria ao receber um relatório de segurança como esse?

Aqui está mais um ponto em que a Snyk Code supera as ferramentas SAST convencionais: ela ajuda você a resolver os problemas de segurança de código que encontra. No canto inferior direito da captura de tela a seguir, feita na IDE IntelliJ, você pode ver que, neste projeto Node.js, a Snyk Code exibe diferenças de commits de vários projetos de código aberto que corrigem o problema de injeção de código identificado.

Com essas informações, os desenvolvedores podem ver como outras pessoas corrigiram problemas de segurança semelhantes. Esse contexto mais amplo sobre a correção sugerida ajuda a tomar uma decisão mais bem informada.

Resumo

Em resumo, os desenvolvedores precisam de uma ferramenta SAST que encontre problemas de segurança tanto no próprio código quanto nas dependências de código aberto que usam. Além disso, a ferramenta precisa recomendar correções práticas para as vulnerabilidades encontradas. Para garantir a adoção, ela também precisa ser rápida, precisa e integrada às ferramentas e aos fluxos de trabalho dos desenvolvedores. Pode parecer muita coisa, mas uma ferramenta SAST com foco no desenvolvedor precisa oferecer todos esses recursos para ser eficaz — e é exatamente isso que a Snyk Code oferece. Confira nosso guia de compra de ferramentas SAST para ajudar você a escolher a ferramenta certa para a sua organização.

Chegou até aqui e quer saber como os testes SAST e DAST se relacionam?

O que são testes SAST e DAST?

SAST é o teste estático de segurança de aplicações. Nele, uma ferramenta precisa apenas do código-fonte da aplicação para analisar o fluxo de dados da origem ao destino e identificar possíveis vulnerabilidades de segurança ou pontos fracos com base na forma como esses dados fluem. Já o DAST, por ser um procedimento dinâmico de teste de segurança de aplicações, exige que a aplicação esteja ativa e em execução em um ambiente adequado. Assim, uma ferramenta pode observar o tráfego, percorrer as páginas e, em geral, automatizar a interação com a aplicação para determinar se ela está vulnerável a problemas de segurança. Saiba mais sobre SAST e DAST: quais são as diferenças e como combinar os dois.