SAST e SCA: juntos são melhores com a Snyk

À medida que as aplicações ficam mais complexas, protegê-las também se torna uma tarefa mais complexa.

Embora o código-fonte das aplicações inclua código proprietário, uma grande parte também é composta por código de terceiros e de código aberto. Por isso, as equipes de desenvolvimento e segurança que querem lançar código seguro sem perder o ritmo acelerado de desenvolvimento precisam combinar o teste estático de segurança de aplicações (SAST) e a análise de composição de software (SCA) como parte de uma estratégia abrangente de segurança de software.

Mas é mais fácil falar do que fazer.

Por ser uma estratégia de teste mais antiga e consolidada, o SAST tradicionalmente tem sido a abordagem lógica para começar a proteger aplicações. Há dezenas de ferramentas de SAST disponíveis, acompanhadas de metodologias bem documentadas e práticas recomendadas. No entanto, as soluções de SAST têm uma reputação ruim em relação à velocidade, à precisão e à facilidade de uso. Esses pontos negativos podem desestimular as equipes a usar SAST ou levá-las a optar por SCA.

As soluções tradicionais de SCA não são muito diferentes: têm um histórico de integração difícil e uma alta taxa de falsos positivos. Embora as vulnerabilidades em pacotes de código aberto tenham ajudado a chamar atenção para SCA, sua adoção ainda é limitada: apenas 38% das organizações confirmam usar controles de segurança para código aberto. E, embora analisem suas dependências (e as dependências delas), as ferramentas de SCA não conseguem detectar vulnerabilidades no código que você escreve.

Mas usar SAST e SCA de forma independente vai contra a preferência crescente das organizações por reduzir a proliferação de ferramentas e consolidar as soluções de segurança de aplicações. Por isso, muitas vezes a escolha é pensada como SAST ou SCA, em vez de considerar SAST e SCA como parte de uma abordagem conjunta.

Nesta publicação, vamos explicar por que SAST e SCA são a abordagem certa e como implementar ambos sem aumentar a proliferação de ferramentas.

Qual é a diferença entre SAST e SCA?

Entender a diferença entre SAST e SCA é essencial para adotar uma abordagem conjunta.

Para que serve o SAST?

SAST é uma metodologia de teste estrutural de segurança de aplicações que analisa o código-fonte ou o bytecode da aplicação em busca de vulnerabilidades, como as do Top 10 da OWASP e as CWEs. Além do código-fonte ou bytecode, também pode avaliar outros materiais, como documentação e especificações. As ferramentas modernas de SAST transformam o código original em uma representação intermediária e realizam vários tipos de teste usando um conjunto de regras que geralmente é executado em um solver lógico.

A vantagem do SAST é analisar todos os caminhos e estados possíveis de uma aplicação e até encontrar bugs que os desenvolvedores não estavam procurando. Quando detectados, esses problemas devem ser indicados com sua localização ou caminho exato na aplicação, incluindo nomes de arquivos e números de linha, além de informações adicionais sobre o problema.

Uma desvantagem das ferramentas tradicionais de SAST é que o fornecedor precisa equilibrar três fatores: identificar problemas reais, encontrar todos os problemas possíveis e os recursos computacionais utilizados. Por isso, essas ferramentas fazem concessões: superestimam o comportamento das aplicações e aceitam certa taxa de falsos alertas e problemas não detectados para reduzir o tempo de processamento. Ainda assim, a análise de projetos maiores com ferramentas tradicionais de SAST pode levar dias ou até semanas.

Para que serve o SCA?

As aplicações modernas dependem de dezenas, ou até centenas, de pacotes de código aberto, geralmente chamados de dependências. Na verdade, 98% das aplicações contêm software de código aberto. Essas dependências, por sua vez, dependem de outros pacotes de código aberto, chamados de dependências transitivas. Os pacotes de código aberto abrangem tarefas variadas, desde tarefas simples, como formatar texto, até frameworks e ambientes de execução mais complexos.

Uma prática recomendada comum é tratar os pacotes de código aberto como unidades. É possível aplicar patches ou alterar o código, desde que as mudanças sejam enviadas de volta ao pacote e incorporadas a ele. Alterações locais comprometem o versionamento do pacote e podem ser sobrescritas quando uma nova versão é baixada.

SCA é uma metodologia de segurança de aplicações que analisa as dependências de código aberto usadas direta ou indiretamente e correlaciona essa análise com dados de vulnerabilidades para rastrear problemas de segurança conhecidos que essas dependências possam conter. Quando detectadas, as vulnerabilidades são sinalizadas com informações sobre o problema e, em alguns casos, com a correção recomendada. Além disso, SCA ajuda a mapear os riscos legais do uso de código aberto, identificando as licenças incluídas nos pacotes.

Por que usar SAST e SCA juntos

Considerando as diferenças funcionais entre as duas metodologias de teste, fica claro que compará-las diretamente não faz sentido.

Embora tenham alguns pontos em comum, como a implementação nas primeiras etapas do desenvolvimento e a análise do código-fonte, elas abrangem dois tipos distintos de código que compõem uma aplicação: SAST ajuda a reduzir o risco introduzido pelo código escrito internamente, enquanto SCA ajuda a reduzir o risco do código criado fora da organização.

Uma abordagem eficaz de segurança de aplicações deve incluir ferramentas de teste de segurança capazes de gerenciar e reduzir os dois tipos de risco. Essa abordagem oferece visibilidade abrangente do código proprietário e dos componentes de código aberto, além de permitir identificar e corrigir problemas mais cedo e ao longo de todo o ciclo de vida do desenvolvimento, reduzindo o risco geral.

Principais requisitos de uma abordagem conjunta

Optar por uma abordagem conjunta não é uma decisão simples. Implementar SAST e SCA como parte de um programa de segurança de aplicações pode ser um desafio cultural e técnico.

O modelo DevSecOps propõe que os desenvolvedores assumam mais responsabilidade pela segurança. No entanto, experiências passadas e atuais com soluções tradicionais dificultam a adoção de uma metodologia de teste pelos desenvolvedores, quanto mais de duas. Algumas equipes podem resistir ainda mais à inclusão de outra ferramenta de segurança entre as que já usam.

A solução mais simples pode parecer integrar as ferramentas de SAST e SCA ao pipeline de CI/CD e devolver os resultados aos desenvolvedores. Mas isso separa as etapas do processo e faz com que os deploys aguardem as análises e a aplicação das correções. No mundo ágil do DevOps, adiar um lançamento por semanas simplesmente não é viável.

Para que um programa conjunto de segurança de aplicações tenha sucesso, as soluções precisam ser, antes de tudo, fáceis de usar para os desenvolvedores. É mais provável que eles usem ferramentas de SAST e SCA que se integrem de forma rápida e fácil aos fluxos de trabalho que já utilizam, desde o início, do que soluções lentas, difíceis de usar e disponíveis apenas nas etapas finais do desenvolvimento.

Além disso, um fluxo de trabalho consolidado, em que as análises de SAST e SCA acontecem ao mesmo tempo ou são realizadas na mesma ferramenta, reduz a complexidade para os desenvolvedores e os custos gerais para a equipe de segurança.

A abordagem da Snyk: Snyk Code e Snyk Open Source

A plataforma Snyk oferece uma abordagem conjunta de segurança de aplicações com SAST e SCA, permitindo desenvolver com rapidez e segurança todas as diferentes partes que compõem uma aplicação hoje.

Usados em conjunto, Snyk Code para SAST e Snyk Open Source para SCA oferecem testes rápidos, precisos, fáceis de usar e com correção assistida. Assim, desenvolvedores e equipes de segurança encontram, priorizam e corrigem facilmente problemas de segurança no próprio código proprietário e vulnerabilidades conhecidas nas dependências de código aberto, reduzindo riscos e acelerando o desenvolvimento seguro.

A aplicação é corrigida antes de entrar no pipeline de CI/CD, eliminando atrasos nas análises e o trabalho de classificar e registrar relatórios de problemas. Assim, a equipe de segurança de aplicações fica livre para se concentrar na postura de segurança geral da organização.

Os testes consolidados da Snyk acontecem desde as primeiras etapas e ao longo de todo o ciclo de vida do desenvolvimento, começando, por exemplo, no IDE:

Uma ferramenta, duas metodologias de análise: o plugin da Snyk para a IDE JetBrains em ação.

As análises são rápidas e os resultados aparecem no ambiente de trabalho do desenvolvedor, com explicações claras e fáceis de entender. O fluxo de dados pela aplicação é exibido sobre o código original, com navegação entre diferentes arquivos. Exemplos de projetos de código aberto mostram como outras pessoas resolveram problemas semelhantes em contextos parecidos. E o melhor: como as análises são rápidas e ilimitadas, os desenvolvedores podem verificar pequenas alterações com frequência e corrigir problemas antes que elas cheguem ao sistema de controle de versões do código-fonte.

A Snyk também realiza automaticamente análises consolidadas nas etapas seguintes do desenvolvimento. Por exemplo, ao importar um novo projeto do GitHub, a Snyk executa automaticamente testes de SAST (1) e SCA (2) no código-fonte do repositório:

Um projeto importado para o Snyk. Resultados de análises SAST e SCA em uma única visualização consolidada.

É importante destacar que a plataforma Snyk se baseia no Snyk Intel Vulnerability Database, que reúne diversas fontes públicas, contribuições da ampla comunidade de desenvolvimento da Snyk e o trabalho da equipe dedicada de pesquisa da Snyk. Assim, oferece os dados de vulnerabilidades mais abrangentes, atualizados e práticos do mercado, garantindo a precisão dos resultados das análises e das orientações de correção.

A interface da Snyk permite que equipes de desenvolvimento e segurança monitorem regularmente sua base de código em busca de vulnerabilidades recém-descobertas. No caso da recente vulnerabilidade Log4shell, por exemplo, o Snyk Open Source permitiu que usuários da Snyk analisassem de forma fácil e rápida toda a base de código de suas aplicações, identificassem repositórios vulneráveis e tomassem as medidas necessárias. Com verificações de PR ou a integração da Snyk a um pipeline de CI/CD, esses testes também podem ser automatizados e se tornar obrigatórios.

A Snyk não cobra por análise, linha de código ou projeto. Por isso, as equipes de segurança de aplicações não precisam limitar as análises a projetos essenciais nem definir uma frequência fixa para controlar os custos da licença. Elas podem analisar quanto código quiserem, sempre que precisarem.

Por fim, a plataforma Snyk também analisa vulnerabilidades em contêineres e infraestrutura como código (como você pode ter notado em uma captura de tela anterior), oferecendo uma visão holística de todas as diferentes partes de código que compõem uma aplicação.

E a vencedora é… a combinação das duas

Combinar SAST e SCA é melhor: assim, as organizações têm uma visão completa de todo o software utilizado.

A proteção de aplicações modernas precisa acompanhar a agilidade dos processos usados para desenvolvê-las. Hoje, usar as duas ferramentas é um padrão de fato para a segurança de aplicações e cada vez mais um requisito para cumprir diferentes normas, como o PCI DSS, e iniciativas governamentais pelo mundo que tratam da segurança de aplicações e do aumento dos ataques à cadeia de suprimentos de software.

Organizações que querem entregar aplicações seguras não deveriam ter que escolher uma metodologia em detrimento da outra por causa de experiências anteriores, preferência por uma delas ou até mesmo orçamentos limitados. SAST e SCA oferecem visibilidade abrangente e indispensável de TODO o código-fonte que compõe uma aplicação e, por isso, devem ser elementos essenciais de qualquer programa de segurança de aplicações.

Não sabe por onde começar com SAST e SCA? Experimente a Snyk grátis!