Desafios ao utilizar ferramentas Open Source em AppSec

Olá, pessoal. Tudo bem? 😊

Resolvi escrever esse artigo com base nas minhas experiências sobre ferramentas OpenSource na área de AppSec.

AppSec, especialmente no Brasil, é algo relativamente novo. Recordo de ver as primeiras vagas sobre o tema ali em 2019. Assim, muitas empresas ainda estão conhecendo esse conceito e com a pandemia, acelerou o processo da área de T.I. como um todo e não foi diferente com AppSec.

Muitas empresas iniciaram essa área e muitas vezes, ainda sem muito budget para mostrar os impactos e os riscos atrelados à área. Como por exemplo, impacto financeiro, credibilidade da empresa, entre outros.

Dessa maneira, quando essa área é iniciada, o ponto de partida é usar OWASP SAMM, para entender a maturidade da empresa frente a segurança, especialmente em AppSec. Após identificar os gaps, podemos pensar em contramedidas/controles para mitigar os problemas. Entre eles e um dos principais: adição de ferramentas na pipeline por tipos de vulnerabilidade.

No entanto, ferramentas de segurança são bem caras, principalmente por conta do dólar. Então, uma forma de acelerar e mostrar os impactos disso é usando ferramenta Open Source. Existem várias ferramentas Open Source e todas possuem os problemas que relatarei a seguir. Pode ser que não sejam exatamente todos, mas é por isso que há uma grande vantagem das ferramentas enterprise.

1# Ambiente

Com uma ferramenta OpenSource, você não sabe como ela irá se comportar em um ambiente, especificamente quando pensamos em escalabilidade. Cada ambiente é único, especialmente quando usamos container.

Um desafio que eu tive, foi justamente com GitHub Actions ao usar uma ferramenta de AppSec para múltiplos repositórios. Dependendo de como workflow está desenvolvido, você precisará alterar o registry da ferramenta e precisará estar atento as novas features daquela ferramenta (você pode criar um bot para enviar uma mensagem se houver uma nova release, por exemplo).

2# Falsos positivos

Ferramentas Open Sources tendem a ter muitos falsos positivos, especialmente por de tras dessas ferramentas usarem diferentes formas de RegEx para encontrar vulnerabilidades. Assim, nem todo apontamento de vulnerabilidade é exatamente uma vulnerabilidade.

Portanto, é necessário ter mecanismo para justificar se a vulnerabilidade é um falso positivo. Muitas ferramentas OpenSource não tem como justificar o que é um falso positivo. As vezes possuem flags para não observar aquela vulnerabilidade específica. No entanto, a nível de pipeline, ela não possui uma ação de travar (status exit=1). Para isso, é necessário criar abordagens de listas, mecanismos de auditoria e controle de quem pode acessar e alterar informações da lista.

Outro ponto também, as ferramentas Open Source tendem a olhar a vulnerabilidade por tipo de severidade e não por tipo de vulnerabilidade (o que ajuda a ter uma granularidade maior). Como falado no texto acima, começar com tipo de vulnerabilidade, após a identificação de gaps pelo OWASP SAMM, é muito melhor do que analisar tipos de severidade.

• Escopo é mais reduzido
• Isso dará tempo do desenvolvedor entender alguns tipos de vulnerabilidade e entender como corrigir diretamente no código

Exemplo de estratégia:

🛡 Quando o ambiente estiver bem maduro e as principais vulnerabilidades controladas, aí sim, poderemos seguir por tipo de severidade (crítica, alta, média e baixa).

3 # Criação específica de Report

Ferramentas enterprise, geralmente, não são muito flexíveis quanto à isso. Então, isso acaba sendo uma vantagem em ferramenta OpenSource.

Criar um report específico, durante a pipeline, ajuda o desenvolvedor entender as vulnerabilidades e prontamente corrigi-las.

• Desenvolva a melhor abordagem para que fique claro para o Dev. Assim, mais rapidamente, ele irá corrigir com autonomia. Status ajudam nessa rápida visualização
• Analise o melhor local possível para adicionar na pipeline. No GitHub Actions, funciona muito bem ao utilizar no Summary

Exemplo de abordagem:

Espero que gostem 👩‍💻💜