Ajudando desenvolvedores a priorizar o backlog de segurança

Hoje, cada vez mais desenvolvedores estão assumindo a responsabilidade de corrigir as vulnerabilidades em seus aplicativos, o que é ótimo. No entanto, quando fazem isso, se deparam com um longo backlog de vulnerabilidades. Decidir qual problema resolver primeiro é difícil e exige tempo e conhecimento especializado em segurança que muitas vezes não têm. É aí que as ferramentas certas podem fazer a diferença: oferecendo a expertise necessária para saber quais perguntas de segurança fazer ao priorizar e a tecnologia para respondê-las rapidamente.

Como lidar com o excesso de vulnerabilidades

O número de vulnerabilidades em componentes de código aberto não para de crescer, com milhares de novas vulnerabilidades divulgadas todos os anos. Para ter uma ideia, a Snyk Vulnerability Database registrou um aumento total de 394% nos últimos quatro anos. Esse crescimento contínuo se reflete, em última análise, nos backlogs de vulnerabilidades que as organizações enfrentam hoje.

Com recursos já limitados e sob pressão constante para entregar código funcional e seguro com rapidez e frequência, ajudando a empresa a se manter competitiva, a única maneira de os desenvolvedores dar conta desses backlogs é priorizando bem. Como não é realista corrigir todas as vulnerabilidades da lista, as equipes de desenvolvimento precisam decidir quais oferecem o melhor retorno pelo tempo investido.

Essas decisões podem ter um grande impacto nos esforços de uma organização para gerenciar e reduzir riscos. Uma priorização inadequada pode direcionar o tempo de desenvolvimento para vulnerabilidades que acabam sendo falsos positivos, gerando atritos e reduzindo a confiança dos desenvolvedores. Priorizar uma vulnerabilidade de alta severidade sem exploração conhecida em vez de uma vulnerabilidade de baixa severidade com uma exploração ativa pode enfraquecer a postura geral de segurança da organização.

Fazer as perguntas certas

Uma priorização eficaz exige conhecimento especializado em segurança, que garanta uma avaliação precisa e aprofundada da ameaça que a vulnerabilidade representa para a organização. Em geral, desenvolvedores não têm esse conhecimento, o que dificulta a priorização adequada dos riscos.

Por isso, as ferramentas de segurança eficazes precisam oferecer esse conhecimento que está faltando, trazendo as perguntas certas à tona no momento certo. Especialistas em segurança podem ajustar essas perguntas, que também podem ser incorporadas ao produto.

Definindo as prioridades

A primeira pergunta que os desenvolvedores precisam poder fazer parece simples: qual problema do backlog deve ser resolvido em seguida?

O CVSS foi criado exatamente para esse fim, mas apresenta alguns desafios. Calcular uma pontuação baseada no CVSS exige conhecimento especializado em segurança. Mesmo quando a pontuação é fornecida pronta, entender como ela foi calculada exige conhecimento e, às vezes, pesquisa adicional. Além disso, a severidade de uma vulnerabilidade não é o único fator a considerar na hora de decidir qual problema resolver primeiro.

Em geral, desenvolvedores não têm o conhecimento especializado em segurança necessário para entender as nuances do CVSS. Também não podem se dar ao luxo de gastar tempo investigando por que uma vulnerabilidade recebeu determinada classificação de severidade. Para ajudar os desenvolvedores a definir prioridades, a pontuação precisa ser explícita e fácil de usar. A Snyk, por exemplo, considera a severidade, a disponibilidade de uma correção, a maturidade da exploração e a idade da vulnerabilidade para calcular sua pontuação de prioridade. A pontuação é apresentada de um jeito fácil de entender e usar.

A diferença entre importante e urgente

Depois de definir as prioridades, é preciso fazer outra pergunta: quais problemas são mais urgentes que os demais?

Vulnerabilidades com explorações ativas, por exemplo, devem receber alta prioridade e ser consideradas urgentes o bastante para exigir atenção imediata. A notória violação de dados da Equifax teve origem em uma vulnerabilidade conhecida, para a qual explorações ativas haviam sido publicadas poucos dias antes do ataque. 

Saber se uma vulnerabilidade pode ser explorada é parte da solução. Sim, isso indica a probabilidade de exploração, mas, assim como as vulnerabilidades em geral, nem toda exploração é igual. Algumas são apenas teóricas e nunca foram transformadas em armas. Outras são muito mais maduras e têm código de exploração publicado.  Explorações maduras facilitam a ação dos atacantes, levando mais deles a experimentá-las. Mais importante ainda, elas são rapidamente incorporadas a botnets automatizadas, que vasculham a web constantemente em busca de brechas fáceis de explorar, independentemente de quem seja a vítima. Se você deixar uma brecha assim aberta, é provável que essas botnets a encontrem rapidamente.

Diante de um enorme backlog de vulnerabilidades, os desenvolvedores precisam identificar rapidamente aquelas cujas explorações podem ser encontradas e transformadas em armas com facilidade. Com esse conhecimento, fica muito mais fácil decidir se uma vulnerabilidade deve ser priorizada.

Corrigir com o contexto certo

Uma vulnerabilidade conhecida pode ter uma exploração, mas isso não significa que ela possa ser explorada no seu aplicativo. A possibilidade de exploração no seu aplicativo depende de como seu código — e as outras bibliotecas que você usa — interage com o componente vulnerável.

Obter esse contexto exige não apenas conhecimento especializado em segurança, mas também recursos de análise. Raramente os desenvolvedores têm acesso a esses dois recursos ou tempo para desenvolvê-los por conta própria.  Ferramentas com esses recursos integrados ajudam os desenvolvedores a avaliar se um método vulnerável realmente faz parte do caminho de execução de um aplicativo e a priorizar de acordo.

A Snyk, por exemplo, analisa previamente cada componente no ambiente do usuário e pode monitorar o aplicativo em execução para informar aos desenvolvedores se a vulnerabilidade pode ser alcançada pelo aplicativo.

Menos barreiras. Mais proteções.

Cada vez mais, espera-se que os desenvolvedores assumam responsabilidades de segurança, mas isso só é possível se souberem que estão dedicando tempo e recursos às vulnerabilidades certas. Uma boa priorização também ajuda a reduzir os atritos entre as equipes de desenvolvimento e de segurança: quanto menos falsos positivos entrarem na lista de correções urgentes, maior será a confiança dos desenvolvedores no processo.

Por sua vez, as equipes de segurança precisam garantir que os desenvolvedores possam priorizar com segurança. Ao estabelecer proteções para eles, as equipes de segurança podem ter a tranquilidade de saber que as decisões estão sendo tomadas dentro de limites seguros. Essas proteções devem ser definidas pelas equipes de segurança com o apoio de políticas suficientemente granulares para viabilizar a governança em escala. Quanto mais automatizadas forem essas políticas, melhor.  

Para ajudar os desenvolvedores a fazer as perguntas certas e priorizar com eficácia, a Snyk oferece recursos de priorização pensados para desenvolvedores, que sugerem as perguntas, encontram as respostas e simplificam as etapas seguintes da correção. Saiba mais aqui ou comece agora mesmo, de graça.