Como estruturar a responsabilidade pela segurança em escala: a perspectiva da Twilio

À medida que as organizações adotam práticas de DevSecOps para entregar software seguro, definir as responsabilidades pela segurança se torna cada vez mais essencial. Recentemente, a Snyk realizou uma mesa-redonda com a Twilio para discutir como distribuir essas responsabilidades em 2021.

Nesta publicação, recapitulamos a conversa entre Guy Podjarny, presidente e cofundador da Snyk, e Yashvier Kosaraju, gerente sênior de Segurança de Produto na Twilio. As equipes de Segurança de Produto da Twilio usam o Snyk Open Source para garantir que o código esteja seguro em todas as etapas, do design à implantação.

Como decidir quem (Desenvolvimento ou Segurança) é responsável por cada coisa

Quando as empresas adotam uma abordagem de DevSecOps, precisam responder a uma pergunta essencial: do ponto de vista de práticas e processos, pelo que devem ser responsáveis as equipes de desenvolvimento e de segurança?

As equipes de segurança devem ser responsáveis por todas as funções de segurança, como análises, modelos de ameaças e testes de invasão, além dos processos relacionados ao ciclo de vida de desenvolvimento seguro de software (SSDLC) e à segurança corporativa. Já as equipes de desenvolvimento devem assumir a responsabilidade pelos riscos e garantir que as vulnerabilidades sejam corrigidas em tempo hábil.

Ainda assim, Kosaraju acredita que a equipe de segurança deve oferecer ferramentas fáceis de usar para facilitar a obtenção de resultados.

“Ao contratar desenvolvedores, você procura características como saber programar, projetar e trabalhar com algoritmos”, diz Kosaraju. “Isso não é um ponto negativo, mas a experiência em segurança raramente é prioridade no processo de contratação. Por isso, é fundamental ter uma equipe central focada em segurança para tomar essas decisões pela empresa.”

No fim das contas, cabe à liderança executiva tomar a decisão final sobre quem é responsável por cada coisa. Mas a equipe de segurança deve atuar como um “centro de excelência” para os desenvolvedores, já que as práticas e os controles precisam ser incorporados diretamente às aplicações.

Também é essencial atribuir processos específicos a uma estrutura organizacional. Caso contrário, as empresas terão um painel de riscos que aponta inúmeras vulnerabilidades, sem envolver nenhuma unidade de negócios para corrigi-las. Definir claramente as responsabilidades pela segurança desde o início leva a ações concretas.

Quebrando a mentalidade de “somos desenvolvedores, não profissionais de segurança”

Incentivar a adoção de segurança pelos desenvolvedores pode ser difícil para as organizações. Muitas vezes, há dois grandes obstáculos para começar: visibilidade e facilidade de uso.

Para começar, a segurança não tem um ciclo de feedback natural. Isso significa que as vulnerabilidades costumam se acumular sem serem resolvidas até que sejam tantas que comecem a afetar os negócios. As empresas precisam ser muito claras e tornar os requisitos de segurança visíveis para todos os desenvolvedores.

A realidade é que a segurança é complicada demais. Para que os desenvolvedores a adotem, é preciso simplificá-la. Um erro comum das empresas é tentar fazer demais logo de início. Ao começar, busque uma conquista rápida, como implementar segurança de código aberto e análise de composição de software (SCA).

“Acho importante mostrar o que você tem hoje e aonde precisa chegar como parte de uma jornada de melhoria contínua. Por isso, ter visibilidade é importante”, diz Kosaraju. “Também acho importante definir limites. Por exemplo, quando você diz que a equipe de segurança vai proteger a empresa, isso significa que ela vai encontrar problemas de segurança para serem corrigidos ou que vai corrigi-los? É fundamental estabelecer uma divisão clara das responsabilidades e definir quem faz o quê.”

No nível do código, a Twilio criou um modelo de responsabilidades pedindo que todos os desenvolvedores adicionassem um arquivo YAML a cada repositório de código. Cada arquivo contém as informações necessárias para identificar os responsáveis pelos repositórios. Assim, a equipe de segurança pode abrir chamados na fila correta e entrar em contato com a pessoa responsável sempre que houver um incidente ou uma vulnerabilidade. Isso ajudou a empresa a deixar de procurar responsáveis manualmente e passar a localizar a equipe certa instantaneamente, além de automatizar o gerenciamento de vulnerabilidades.

Como medir a segurança, um desenvolvedor de cada vez

Começar com um programa de recompensa por bugs é uma ótima maneira de entender o retorno sobre o investimento em ferramentas de segurança. Depois que o programa estiver em funcionamento, é possível conectar ferramentas a diferentes partes do ciclo de vida de desenvolvimento de software (SDLC) e reduzir o número de relatos de bugs. Com a queda no número de relatos, as equipes podem começar a se concentrar em práticas de segurança antecipada no ciclo de desenvolvimento.

“É importante ter em mente que, quando uma nova ferramenta é introduzida, o número de bugs sempre aumenta”, diz Kosaraju. “Uma distinção importante é apontar as deficiências das ferramentas e dos recursos de segurança. As equipes de segurança não são perfeitas, mas reconhecer essa realidade mostra que todos estão trabalhando juntos para tornar a empresa mais segura e adotar uma mentalidade de segurança.”

Para que os desenvolvedores entendam as vulnerabilidades no contexto da visibilidade geral, o melhor é observar por quanto tempo as vulnerabilidades críticas permanecem abertas em uma fila. Essa é uma métrica ideal para avaliar a agilidade das equipes na correção de vulnerabilidades. Por exemplo, se a equipe de segurança implantar a Ferramenta X, que aponta 30 vulnerabilidades críticas, e uma equipe de engenharia corrigir 29 delas em duas semanas, esse é um excelente indicador para acompanhar ao longo do tempo.

Como a definição das responsabilidades pela segurança continua evoluindo a cada ano, a Snyk realiza webinars regularmente para conhecer diferentes perspectivas de profissionais de segurança do setor. Essas mesas-redondas são uma oportunidade para a Snyk entender as necessidades das equipes de segurança de aplicações e dos desenvolvedores, ajudando as empresas a continuar alinhando seus produtos às necessidades de segurança de organizações como a Twilio.