Segurança de código aberto com Guy Podjarny, autor da O’Reilly

Na semana passada, o cofundador da Snyk, Guy Podjarny, participou de uma conversa ao vivo sobre seu livro da O’Reilly, Securing Open Source Libraries. Esta publicação resume alguns dos principais aprendizados do webinar. Se ainda não teve a oportunidade de assistir, confira a gravação aqui. A Snyk também disponibiliza uma cópia do livro para você gratuitamente.

Por que investir na segurança de código aberto?

A conversa começou com uma pergunta muito importante: por que devemos nos preocupar com a segurança de código aberto? Guy explica que, na opinião dele, o mercado ainda subestima os riscos associados às bibliotecas de código aberto. A maior parte do código implantado por uma equipe de desenvolvimento não foi escrita por ela, mas vem de bibliotecas de código aberto. Isso é ótimo, porque evita que as equipes reinventem a roda. Por outro lado, também significa herdar os riscos presentes nesses componentes.

Em parte, esses riscos refletem o volume de bibliotecas de código aberto em comparação com o código original da sua aplicação. Eles também decorrem do fato de que componentes de código aberto são alvos especialmente atraentes para ataques. Os invasores costumam começar pelas oportunidades mais fáceis, e o código aberto oferece um alto retorno sobre o investimento: uma única vulnerabilidade pode ser explorada contra muitas vítimas.

Como o setor está lidando com esse problema hoje?

Uma parte do setor ainda não está lidando com esse problema. Às vezes, as pessoas ficam sabendo de uma exploração maliciosa específica e resolvem o caso pontualmente. Mas não têm uma lista de materiais de software de código aberto. Não acompanham quais componentes estão usando nem onde. Tampouco monitoram esses componentes com base no banco de dados de vulnerabilidades.

Outras pessoas levam a segurança em conta ao decidir quais bibliotecas de código aberto usar. Isso costuma acontecer antes de incluir uma biblioteca, mas nem sempre há monitoramento contínuo. Novas vulnerabilidades podem ser descobertas, ou uma versão atualizada pode trazer novas vulnerabilidades, sem que haja um processo para acompanhar essas mudanças.

Por fim, algumas empresas investem na descoberta e correção contínuas de vulnerabilidades de segurança em código aberto. Boa parte do livro explica como colocar isso em prática da melhor forma. Então, vamos começar falando sobre o que acontece quando uma nova vulnerabilidade é divulgada em uma biblioteca de código aberto.

Uma corrida contra o tempo

Ao analisar um projeto, devemos partir do princípio de que ele tem bugs. Não escrevemos código perfeito, nem escrevemos ou usamos código em condições ideais. Isso também vale para falhas de segurança. Por isso, é prudente presumir que qualquer projeto de código aberto que você adotar tenha uma vulnerabilidade de segurança. Talvez a comunidade ainda não a tenha encontrado.

Quando uma vulnerabilidade é descoberta e divulgada, começa uma corrida. A comunidade corre para lançar uma correção e fazer com que as pessoas apliquem. Agentes mal-intencionados correm para explorar a vulnerabilidade onde puderem. Como ela já é conhecida, eles nem precisam descobri-la: basta agir. Assim que a vulnerabilidade é divulgada, o risco de segurança associado a ela aumenta bastante. Os invasores se aproveitam da falta de boas práticas de segurança. As equipes precisam reduzir ao máximo o intervalo entre a divulgação de uma vulnerabilidade e sua correção. Nunca será possível eliminar totalmente essa diferença, mas há uma grande distância entre uma hora, um dia, uma semana, um mês e um ano.

Como as equipes podem reduzir esse intervalo? E qual é o papel de cada pessoa?

DevSecOps na prática

DevSecOps é um termo aspiracional bastante comum no setor. Na prática, trata-se de colaborar entre diferentes disciplinas em prol de um objetivo comum: um produto funcional e seguro. As ações de cada profissional para atingir esse objetivo variam de acordo com sua atuação em segurança ou desenvolvimento.

O trabalho de quem atua em segurança é manter a organização protegida, gerenciando os riscos potenciais de forma consciente e intencional. Para isso, é preciso entender a postura de risco atual da organização e saber quais riscos devem ser priorizados. Porém, esperar que um profissional de segurança faça as correções diretamente não é escalável e pode gerar problemas, já que essa pessoa não conhece a base de código tão bem quanto a equipe de desenvolvimento.

Na relação com DevSecOps, os profissionais de segurança têm um papel semelhante ao dos engenheiros de confiabilidade de sistemas (SREs) em DevOps. Eles têm uma visão geral da integridade do sistema e definem políticas. Além das responsabilidades de governança, os profissionais de segurança da equipe educam e capacitam os desenvolvedores com quem trabalham para que assumam a responsabilidade pelo trabalho do dia a dia. De atividades de governança à automação, o trabalho deles permite que os desenvolvedores tomem as decisões certas sobre segurança e ajam de acordo com elas.

Quando o fluxo de trabalho é bem estruturado, a maior parte disso pode acontecer sem a intervenção da equipe de segurança. Se o profissional de segurança definiu boas políticas e ofereceu ferramentas e treinamento adequados aos desenvolvedores, o trabalho diário pode seguir com pouca ou nenhuma interferência da área de segurança.

O objetivo é corrigir

E qual é o objetivo de uma equipe DevSecOps? Corrigir vulnerabilidades.

Saber que você tem vulnerabilidades e onde elas estão é útil, mas queremos trabalhar para ter sistemas mais seguros como um todo — e isso significa corrigir os problemas. Se quem desenvolve não tem as ferramentas necessárias nem o suporte adequado da equipe de segurança ou da gestão, às vezes acabamos apenas encontrando a vulnerabilidade, sem corrigi-la.

Como manter o ritmo e não apenas encontrar, mas também corrigir um problema? Em muitas organizações, a correção só acontece depois da triagem, que por sua vez ocorre antes de envolver a equipe de desenvolvimento. Na triagem, avaliamos a gravidade e o risco da vulnerabilidade, mas nem sempre a facilidade de corrigi-la. Depois da triagem, a equipe de desenvolvimento percebe que algumas dessas questões podem ser resolvidas com facilidade, enquanto outras são sistêmicas e difíceis de corrigir.

Para muitas vulnerabilidades, corrigir é mais fácil do que fazer a triagem. A triagem é necessária quando a correção não é simples. Mas, se for fácil corrigir, vá direto ao ponto. Se você investiu em tornar a correção mais simples, poderá resolver muitas dessas vulnerabilidades sem nem sequer fazer a triagem.

A escala é outro obstáculo para corrigir vulnerabilidades. Em geral, as equipes usam muitos componentes, e vários deles têm vulnerabilidades. Por isso, pode ser difícil lidar com elas em grande escala. Um bom plano de governança pode ajudar, pois facilita determinar quando a equipe precisa interromper tudo para lidar com um problema emergente e quando a correção de vulnerabilidades pode entrar na rotina habitual.

Guy resume o objetivo: encontrar e corrigir os problemas que já existem no seu projeto e, depois, prevenir e responder a problemas futuros. Encontrar. Corrigir. Prevenir. Responder. Em grande escala, tudo se resume a essas quatro ações.

Estanque o sangramento

Vamos começar. Mas por onde começar?

A palavra triagem costuma ser associada ao atendimento de emergência. Imagine um paciente que chega ao hospital depois de sofrer um grave acidente de carro. Ele pode ter vários problemas — talvez esteja resfriado há uma semana, tenha alergias sazonais ou até uma doença crônica mais grave. Todos esses problemas merecem atenção médica, mas nenhum deles importa nos primeiros momentos após a chegada do paciente, logo depois do acidente. O que importa é estancar o sangramento. Os médicos fazem o possível para impedir que o quadro piore e, depois que o paciente está estabilizado, podem cuidar dos outros problemas.

Quando uma equipe começa a lidar com a segurança de código aberto, a situação pode parecer avassaladora. Seu projeto talvez já tenha vários problemas. Nesse caso, é bom lembrar que a prioridade é estancar o sangramento. Você pode lidar com os problemas atuais depois de impedir que a situação piore. Concentre-se nas mudanças. Se você sabe que seu projeto tem sete vulnerabilidades, abre um PR com novas alterações e ele volta com oito, basta impedir ou corrigir essa vulnerabilidade adicional para estabilizar o projeto. Corrija os problemas de segurança que surgirem nas diferenças entre o código antigo e o novo. Quando esse fluxo de trabalho estiver implementado, você poderá começar a resolver as questões de segurança legadas.

Estanque o sangramento, mas não pare por aí. Previna e responda. Encontre e corrija. Lide continuamente com os desafios de segurança do código aberto e evite que novos problemas apareçam. Use código aberto com confiança, responsabilidade e segurança.

Assista à entrevista completa aqui.

Receba gratuitamente seu exemplar de Securing Open Source Libraries