Vulnerabilidades de código aberto e segurança com Jeff McAffer, da Microsoft

Com a chegada do fim de 2019, vamos relembrar alguns episódios incríveis do nosso podcast The Secure Developer. Confira a primeira publicação aqui.

O podcast The Secure Developer faz parte da nossa comunidade MyDevSecOps, dedicada à educação em segurança e independente de fornecedores. A comunidade, também conhecida anteriormente como The Secure Developer, se reúne virtualmente pelo nosso grupo no Slack e em eventos online, além de participar presencialmente de eventos DevSecCon ao redor do mundo.

Sobre nosso convidado

Jeff McAffer é diretor do Open Source Programs Office da Microsoft. Nessa função, ele lidera o escritório de programas de código aberto, ajudando a promover mudanças em políticas, processos, ferramentas e cultura em toda a empresa, em um momento em que a Microsoft está mudando sua visão sobre o código aberto. Recentemente, ele participou do podcast The Secure Developer para conversar sobre:

• Como simplificar os processos de segurança

• Gerenciamento de vulnerabilidades

• Boas práticas no uso de código aberto e muito mais

Hoje, queremos compartilhar os destaques da nossa conversa com Jeff.

Simplificando o processo

A equipe de Jeff, formada por cerca de doze pessoas, trabalhou para simplificar o processo de código aberto na Microsoft, seguindo o lema "eliminar, automatizar, delegar". Veja o que isso significa:

• Eliminar: Sempre que possível, a equipe elimina políticas, dúvidas ou obstáculos que possam ser identificados e resolvidos.

• Automatizar: A equipe cria políticas altamente automatizadas, capazes de receber dados e contexto e apresentar uma resposta.

• Delegar: Quando identifica um risco que exige a contribuição de alguém de fora, a equipe delega a tarefa a terceiros com a experiência necessária, como um advogado ou alguém da equipe com foco nos negócios.

Segundo Jeff, ao aplicar esse fluxo de trabalho, deixando para trás o modelo de solicitação e aprovação e adotando um modelo de registro e revisão, “chegamos a um ponto em que, com integrações aos nossos sistemas de build, políticas automatizadas e bons dados, cerca de 99% do uso de código aberto é detectado automaticamente e passa pelos nossos mecanismos de políticas sem qualquer intervenção humana.”

Apesar dos esforços para automatizar os sistemas ao máximo, as ferramentas não são perfeitas. Como ele diz, pessoas são pessoas e ferramentas são ferramentas. Por isso, é importante ter um plano de segurança pronto para lidar com as vulnerabilidades que possam surgir.

Como lidar com vulnerabilidades

Na abordagem da Microsoft à segurança, há dois níveis diferentes:

• Desenvolvimento ativo: O primeiro conjunto de componentes de segurança tem como foco o desenvolvimento ativo. Quando um componente com algum problema de segurança ou licença é adicionado, ele é sinalizado, a equipe recebe uma notificação e pode agir.

• Resposta a incidentes: Quando uma vulnerabilidade de alta gravidade é divulgada, ela é encaminhada à equipe de resposta a incidentes de segurança, que toma uma decisão com base nas informações disponíveis. A decisão de emitir ou não um alerta depende da definição do SLA.

Esses níveis atendem à maioria dos casos de uso. No entanto, segundo Jeff, ainda vale a pena perguntar: “Que informações melhores para avaliação podemos ter? Como posso saber, como usuário, se estou vulnerável?” Na Snyk, concordamos com essas perguntas — e nossas ferramentas permitem identificar vulnerabilidades nas suas dependências a qualquer momento. Essa abordagem permite que as empresas sejam totalmente transparentes ao gerenciar suas vulnerabilidades e ao demonstrar que estão fazendo isso com sucesso.

Relatar proativamente suas vulnerabilidades, seja por meio dos CDEs padrão ou de outros canais, é uma atitude responsável e respeitosa com a comunidade mais ampla de código aberto. Isso faz parte de assumir a responsabilidade como mantenedor de projetos de código aberto. Se você optar por usar componentes de código aberto, Jeff recomenda assumir a responsabilidade por eles, monitorando e relatando as vulnerabilidades relacionadas à medida que distribui esse código.

Boas práticas no uso de código aberto

Na mesma linha, assim como as empresas buscam maneiras de ajudar a identificar vulnerabilidades, a Microsoft lançou o ClearlyDefined.io para ajudar a reunir dados sobre licenças de forma colaborativa. Nessa comunidade, as pessoas podem adicionar informações sobre licenças e detentores de direitos autorais difíceis de rastrear, garantindo que os dados estejam o mais atualizados possível.

O ClearlyDefined passa por revisão como qualquer contribuição de código aberto e, em seguida, é integrado às definições dos componentes de código aberto. Idealmente, as alterações são incorporadas aos componentes originais para que as versões futuras tenham definições mais claras.

Como Jeff explicou: “Muita gente ainda pensa: ‘É código aberto. Vou pegar, usar e pronto.’ Mas, na verdade, você precisa tratá-lo como se fosse seu código. Mesmo que não vá escrever nada, mesmo que não conheça a linguagem, precisa tratá-lo como parte do seu sistema, se preocupar com a segurança dele e se envolver com as equipes que o produzem e mantêm o projeto. Pergunte: ‘Como podemos construir isso juntos? Como podemos tornar este projeto seguro para que todos possamos usá-lo com segurança?’” Estamos totalmente alinhados com essa visão sobre boas práticas no uso de código aberto.

O MyDevSecOps tem o compromisso de trazer palestrantes excelentes, como Jeff McAffer, para nossos encontros virtuais e para o podcast The Secure Developer. Se você tem interesse em aprender mais sobre todos os aspectos da segurança, considere participar da comunidade.