🎅 🧠 🧕 (S) SDLC ou Como tornar o desenvolvimento mais seguro. Parte 1 👨‍👨‍👦 🤦🏽 🚹

A cada ano, a cultura de desenvolvimento cresce, novas ferramentas para garantir a qualidade do código e novas idéias sobre como usar essas ferramentas aparecem. Já escrevemos sobre o dispositivo de análise estática , sobre quais aspectos dos analisadores você precisa prestar atenção e, finalmente, sobre como, do ponto de vista organizacional, você pode criar um processo baseado na análise estática .

Com base nos problemas que frequentemente encontramos, descrevemos todo o processo de introdução de um scanner de código em um processo de desenvolvimento seguro. Hoje falaremos sobre como escolher o analisador mais adequado para você.

De uma forma ou de outra, todos os desenvolvedores são confrontados com a análise estática (análise de código sem execução). Por exemplo, quando o compilador gera alguns erros ou avisos com base nos resultados da montagem, esses são os resultados da análise estática. Costumamos usar linters - essa também é uma análise estática, embora geralmente muito simples. Existem exemplos mais interessantes - spotbugs (anteriormente findbugs), que permitem encontrar vulnerabilidades bastante interessantes no bytecode Java ou no conhecido SonarQube - uma plataforma para monitorar a qualidade do código.

No entanto, ferramentas SAST completas ainda são raramente encontradas. Primeiro, estamos falando de ferramentas que podem encontrar vulnerabilidades complexas. Como se vê na prática, ferramentas abertas conhecidas não conseguem lidar com essa tarefa, pelo menos porque se concentram em outra área (bugs e vulnerabilidades simples). Uma boa ferramenta SAST implementa análise interprocedural do fluxo de dados. A análise não deve ocorrer no texto do programa, mas na apresentação interna - CFG, AST, etc. Leia mais sobre isso no artigo anterior .

SAST

Aqui está um exemplo - a bem conhecida injeção SQL. Neste exemplo, os dados do usuário se enquadram na função concluída da consulta, passada para a função injectableQuery, e já lá se enquadram na consulta SQL, tornando o aplicativo vulnerável à injeção de SQL.

Para encontrar essa vulnerabilidade, é preciso entender de onde os dados "ruins" podem vir, como esses dados podem ser validados, onde não podem ser usados. E o mais importante - você precisa monitorar a transferência de dados em todo o aplicativo, essa é a análise do fluxo de dados. O exemplo é muito simples: em uma aplicação real, os dados podem passar por muitas funções e módulos, atribuições e sinônimos.

É claro que a pesquisa de texto não encontrará essa vulnerabilidade. A análise intraprocedural também não será encontrada e, em algumas ferramentas abertas, apenas ela é implementada. Para encontrar essas vulnerabilidades (e essas geralmente são as vulnerabilidades mais críticas, ou seja, o principal objetivo da ferramenta SAST), precisamos de algoritmos bem desenvolvidos para análise entre procedimentos do fluxo de dados com grandes bases de regras.

É com base na complexidade algorítmica que surgem vários problemas técnicos que distinguem a implementação da ferramenta SAST de outros analisadores estáticos, por exemplo, o SonarQube. Discutiremos essas questões em uma série de artigos. Spoiler: consumo de recursos, duração da análise, falsos positivos.

Deve-se notar que, além dos algoritmos, uma boa ferramenta envolve toda a matemática em um shell de interface conveniente, permitindo que você use o SAST sem preparação séria. Essas ferramentas também são incorporadas ao IC / CD usando plug-ins e APIs, automatizando a pesquisa de vulnerabilidades e permitindo a criação de processos de desenvolvimento seguros.

No primeiro artigo, tentamos classificar os principais problemas que surgem durante o estudo do SAST, bem como após a decisão de implementar a ferramenta. Falaremos sobre alguns problemas aqui, alguns irão para os seguintes artigos.

Vamos começar

Por que a SAST se você já possui analisadores estáticos gratuitos?

Abordamos parcialmente essa questão na parte anterior. Obviamente, não diminuímos de maneira alguma os méritos das ferramentas abertas. Todo mundo sabe que o SonarQube é uma ótima ferramenta para automatizar a avaliação da qualidade do código, com um grande número de idiomas, integrações e plugins suportados. O SonarQube é bom para incorporar no processo de desenvolvimento, mas se destina mais à contagem de várias métricas de código e à busca de erros ou vulnerabilidades bastante simples. Ele não implementa a análise interprocedural do fluxo de dados; portanto, não pode ser usado para procurar vulnerabilidades complexas. Normalmente, recomendamos o uso do SonarQube e de uma boa ferramenta SAST (pode ser útil aqui se a ferramenta SAST puder se integrar ao SonarQube).

Existem outros bons analisadores estáticos abertos. Você pode chamar spotbugs (findbugs) para o bytecode da JVM com o plug-in find-sec-bugs, que implementa a análise em andamento do fluxo de dados com um pequeno conjunto de regras. Existe um analisador de bandidos conhecido para Python. Não se pode deixar de mencionar o analisador estático incorporado no clang, que possui um bom mecanismo de análise e uma boa base de regras.

Os problemas de tais ferramentas são que eles geralmente são especializados de maneira bastante restrita (por exemplo, adequados para um idioma), implementam algoritmos simples (isto é, não permitem encontrar vulnerabilidades complexas) e têm bases de regras muito menores que as ferramentas comerciais. Além disso, eles têm um conjunto menor de funcionalidades, interface e integração. Bem, podemos mencionar a falta de apoio.

Por outro lado, boas ferramentas comerciais do SAST (e também existem ruins) implementam algoritmos específicos complexos e possuem extensas bases de regras que podem incluir milhares de registros. Geralmente, eles suportam muitas linguagens de programação, possuem recursos avançados de interface e integração (plugins, APIs). Abaixo, dou um exemplo de que tipo de integrações estamos falando.

E ainda mais, veja um exemplo de um esquema de integração que pode ser construído com base em uma ferramenta SAST. Em geral, o esquema não difere da introdução de outros meios de controle de qualidade do código. Os desenvolvedores escrevem código e podem executar imediatamente uma verificação SAST. O código entra no repositório e, a partir daí, vários gatilhos usando CI / CD entram no SAST. Os resultados da verificação podem ser visualizados na interface SAST ou podem acabar em ferramentas que suportam o processo de desenvolvimento (rastreador de erros, correio etc.).

Qual ferramenta SAST escolher?

Vou me debruçar um pouco sobre a escolha de uma ferramenta. Existem muitas ferramentas SAST, geralmente várias peças são apresentadas no mercado (3-4). Surge a pergunta: como escolher a ferramenta certa, o que procurar? Aqui não vou surpreender, vou me concentrar em três pontos: comparação funcional, comparação de qualidade e licenciamento. É importante levar a ferramenta de teste (piloto) em seu circuito local e verificar seu código em sua infraestrutura.

Seria bom tentar todos os recursos da interface, entender como eles são aplicáveis ao seu caso e como eles são convenientes de usar. Refiro-me a um dos artigos anteriores . Aqui estão alguns recursos úteis:

o lançamento mais automatizado da verificação (idealmente, sem configurações desnecessárias em dois botões, você pode executar uma verificação);
— , , ;
;
;
;
(, );
;
, “”;
“ , ”;
;
.

Os recursos de integração são muito importantes - com CI / CD, gerenciadores de erros, repositórios, Active Directory. Seria bom tentar automatizar uma ação simples usando a API, se houver.

Para verificar a qualidade, você precisa digitalizar seu código. É bom escolher vários exemplos diferentes em idiomas diferentes para que a amostra seja representativa. Do ponto de vista da qualidade, você precisa olhar para falsos positivos (onde claramente não há vulnerabilidade, mas a ferramenta mostra) e omissões (idealmente, você precisa saber onde estão as vulnerabilidades, bem, ou comparar as vulnerabilidades encontradas em diferentes ferramentas). Eu prestaria um pouco menos de atenção aos falsos positivos, pois geralmente é suficiente analisar os resultados da verificação uma vez, marcar os falsos e eles não o incomodarão.

Vou me concentrar em dois pontos importantes. Primeiro de tudo, é muito importante analisar tudo isso em aplicação à sua situação. Verifique exatamente seu código (o SAST pode funcionar de maneira diferente em diferentes tipos de aplicativos). Procure os recursos necessários para incorporar a ferramenta no processo de desenvolvimento. Verifique a integração com os sistemas que você possui.

Em segundo lugar, é muito importante durante o piloto se comunicar com o fornecedor. SAST não é a coisa mais fácil e, muitas vezes, é suficiente para obter os conselhos usuais do fornecedor para apreciar totalmente o poder da ferramenta.

Em que ponto você começa a digitalizar?

Quanto mais cedo uma vulnerabilidade é encontrada, mais barata é. Existem agendas hackneyed que variam de apresentação em apresentação, eu nem as adicionarei aqui. Mas a afirmação é bastante óbvia. Uma coisa é corrigir a vulnerabilidade no dia seguinte à sua criação; outra é fazer uma alteração no servidor de combate quando ele já tiver sido hackeado. Portanto, é necessário transferir o uso do SAST para os estágios iniciais de desenvolvimento. Aqui, pode-se argumentar que a introdução do SAST no desenvolvimento é, por si só, um evento caro e que pode não render. Aqui discutirei: normalmente, encontrar várias vulnerabilidades críticas cobre toda a implementação (você pode até fazer uma avaliação dentro do piloto).

Com essa abordagem, também ganhamos um bônus: os desenvolvedores, quando veem os resultados do SAST "todos os dias", avançam no conhecimento de programação segura, portanto, em geral, a cultura do desenvolvimento seguro é aprimorada e o código fica melhor.

Obviamente, ao implementar o SAST no processo de desenvolvimento, é necessário implementar no CI / CD, criando o DevSecOps. A tendência de transferir o SAST das verificações de controle antes da liberação para o processo de desenvolvimento é visível há muito tempo e, nos últimos 2-3 anos, ela alcançou nosso mercado. Agora, nenhum piloto passa sem testar os recursos de integração.

Ao mesmo tempo, eu deixaria verificações de controle antes do lançamento, idealmente, para montagens binárias (isso também é possível). Portanto, você pode garantir que nenhuma nova vulnerabilidade tenha sido adicionada durante a montagem e transferência do aplicativo para o produto.

Problemas técnicos

E então eu lhe darei 4 perguntas imediatamente.

Conecte o SAST como SonarQube, qual é a dificuldade?
O SAST funciona por um longo tempo, como configurar o DevSecOps?
SAST dá falsos positivos, como configurar o Quality Gate?
E sem falsos positivos no relatório, vários milhares de vulnerabilidades, o que fazer com elas?

Estes são os principais problemas técnicos que surgem ao implementar o SAST. Eles surgem pelos seguintes motivos.

Devido à natureza exponencial dos algoritmos, o SAST pode ser executado por um longo tempo e consumir muitos recursos - muito mais do que um linter ou SonarQube.
Pelo mesmo motivo, o SAST pode fornecer muitos falsos positivos - é improvável que os desenvolvedores desejem analisar várias quedas todos os dias após a próxima verificação.
Geralmente, o SAST é iniciado na base de código pela primeira vez e a primeira execução pode mostrar muitas operações, especialmente se houver muito código e o banco de dados não for muito novo.

Todas as questões são solucionáveis. No próximo artigo da série, examinaremos, usando um exemplo concreto de nossa experiência, como implementar o SAST de maneira a nivelar todos os seus recursos técnicos e fazer todos felizes.

Questões organizacionais

Eu não esqueceria as questões organizacionais. Nas grandes empresas, muitas delas surgem, do próprio processo de implementação, da alocação de recursos para a criação de regulamentações e a replicação de processos.

As questões organizacionais são geradas pelos mesmos recursos técnicos que discutimos no parágrafo anterior. Além disso, a divisão e o confronto historicamente estabelecidos entre desenvolvimento e segurança ainda não desapareceram. Também me refiro ao nosso artigo anterior.

Continua

Implementar SAST - é necessário, geralmente é justificado. Mas, começando a implementar, seria bom se familiarizar com todas as armadilhas que surgem no seu caminho. Neste artigo, começamos a desmontá-los, continuaremos com os aspectos técnicos a seguir.

(S) SDLC ou Como tornar o desenvolvimento mais seguro. Parte 1