Medir o desempenho dos desenvolvedores na segurança do código é uma parte importante da introdução ao DevSecOps, mas muito foco nas métricas do desenvolvedor pode dificultar a mitigação do risco comercial, de acordo com os profissionais da empresa.
DevSecOps refere-se à prática de incorporar a segurança do aplicativo nos estágios iniciais do processo de desenvolvimento de software, no qual os desenvolvedores desempenham um papel crítico. A prática tornou-se comum entre as organizações empresariais preocupadas com uma maré crescente de ataques cibernéticos e vulnerabilidades de segurança de alto perfil, especialmente nos últimos dois anos. Dado o ritmo de lançamentos de software exigido pelo Agile e DevOps e a escala da computação distribuída nativa da nuvem, os aplicativos modernos exigem que a segurança seja incorporada desde o início para ter alguma esperança de ficar à frente das ameaçasmuitos especialistas acreditam.
À medida que organizações empresariais como a Komatsu Australia, uma empresa de manufatura com sede em New South Wales, fazem essa transição para o DevSecOps, elas contam com métricas como tempo médio para detectar (MTTD) e tempo médio para resolver (MTTR) vulnerabilidades e incidentes de segurança. Essas métricas podem ajudar a estabelecer uma base para a prática ágil de melhoria continua nos estágios iniciais do DevSecOps.
Eric Cheng
“Obviamente precisamos começar com uma linha de base e ver onde estamos agora, e então o que faz sentido melhorarmos”, disse Eric Cheng, arquiteto digital da Komatsu. “As métricas lhe dirão: ‘Você está indo na direção certa?'”
Essa medição de linha de base incorporará o modelo de maturidade DevSecOps da organização de padrões Open Web Application Security Project (OWASP), que estabelece um processo de três níveis por adotar práticas de DevSecOps em diversas áreas de desenvolvimento de aplicativos e operações de TI.
“Eles são um corpo bem conhecido”, disse Cheng sobre a OWASP. “Para nós, onde estamos em termos de jornada, acho que é um bom ponto de partida.”
Para feedback específico do desenvolvedor, a Komatsu usa teste de segurança de aplicativo estático e análise de composição de software painéis da empresa de segurança cibernética Snyk. Além de MTTD e MTTR, Cheng mostra as tendências dos desenvolvedores em uma métrica Snyk chamada janela de exposição para cada aplicativo, uma medida do tempo total decorrido entre quando um problema foi detectado e quando foi resolvido.
“Nós olhamos para ‘OK, você tem alguns problemas começando a surgir em termos de janela de exposição’ ou ‘Você corrigiu esses problemas em um curto período de tempo, continue com o ótimo trabalho'”, Cheng disse.
Esta não é a única ferramenta na caixa de ferramentas DevSecOps da Komatsu — treinamento para desenvolvedores, em parte via serviços profissionais Snyk; colaboração contínua com os gerentes de segurança cibernética da empresa na fase de design de aplicativos; e automação de segurança dentro de pipelines de CI/CD também são componentes importantes, disse Cheng. Mas as métricas e os benchmarks funcionarão como um guia geral para um compromisso plurianual de mudar a segurança para a esquerdana Komatsu.
‘Isso levou ao comportamento errado’
Para equipes mais avançadas no caminho da maturidade, as métricas de DevSecOps serviram inicialmente para um propósito semelhante. Mas, em última análise, as organizações de TI devem olhar além do feedback orientado por métricas para motivar os desenvolvedores a se preocuparem com a segurança.
Os limites da eficácia das métricas de DevSecOps como incentivo ao desenvolvedor foram refletidos nos resultados de uma pesquisa DevSecOps de maio de 2022 com 5.000 tomadores de decisão de TI conduzida pelo fornecedor da plataforma DevOps GitLab. A segurança foi considerada uma métrica de desempenho para desenvolvedores por 57% das organizações dos entrevistados, mas 56% disseram que ainda era difícil fazer com que os desenvolvedores priorizassem a correção de vulnerabilidades de código e 59% disseram que vulnerabilidades de aplicativos ainda eram mais prováveis de serem encontradas por equipes de segurança em Produção.
Para a varejista Target Corp., uma ênfase inicial nas métricas de DevSecOps acabou levando a consequências não intencionais, disse Jennifer Czaplewski, diretora sênior de segurança cibernética, em uma apresentação em um DevOps Connect evento co-localizado com o deste ano Conferência RSA.
A Target calcula uma pontuação de inteligência de produto (PI) para cada um de seus 7.000 aplicativos. Essa pontuação leva em consideração as métricas de DevSecOps, como a porcentagem de vulnerabilidades de endpoint resolvidas de acordo com as políticas de MTTR da empresa, uso do desenvolvedor de serviços de segurança internos e se um aplicativo ou serviço foi a causa de um evento de segurança.
Em 2019, o primeiro painel DevSecOps da Target mostrou se a pontuação de PI de cada aplicativo estava entre os 10% principais dos aplicativos e serviços da Target – ou os 20% inferiores.
Queremos ter certeza de que não estamos levando as equipes à perfeição. Não estamos procurando pontuações perfeitas, estamos procurando uma boa saúde de segurança.
Jennifer CzaplewskiDiretor sênior de segurança cibernética, Target
“Isso gerou muita competição amistosa, mas nossas equipes ficaram tão boas em entender como garantir suas inscrições que mais de 10% de todas as equipes tiveram uma pontuação perfeita, então, se você tivesse uma pontuação perfeita, ainda não chegaria ao topo. 10%”, disse Czaplewski em sua apresentação. “As pessoas ficaram frustradas e isso levou ao comportamento errado.”
As equipes agora são solicitadas a atingir um PI Score mínimo, mas as informações comparativas não fazem mais parte da interface DevSecOps da Target, disse Czaplewski.
“Queremos ter certeza de que não estamos levando as equipes à perfeição”, disse Czaplewski. “Não estamos procurando pontuações perfeitas, estamos procurando uma boa saúde de segurança.”
De métricas de DevSecOps a uma cultura segura
A Target ainda espera conscientização de segurança entre os engenheiros de software, mas começou a cultivar o que chama de Security Ninjas, desenvolvedores que se tornaram especialistas em assuntos de segurança incorporados às equipes de desenvolvimento de aplicativos. Esses especialistas, que representam aproximadamente 5% da força de trabalho de 5.000 desenvolvedores da Target, atuam como tradutores entre segurança e desenvolvedores. Security Ninjas também são encarregados de construir dois ou três modelos de ameaças a cada ano para criar uma visão estratégica do risco do negócio, em vez de focar em métricas específicas de DevSecOps.
“Aprendemos nos últimos três ou quatro anos que realmente queremos nos concentrar no que devemos fazer para construir uma cultura segura em uma equipe, não o que você deve saber que, esperançosamente, se transforme em algo”, disse Czaplewski em seu apresentação. “Se você é um Ninja de Segurança, a primeira responsabilidade é pelo menos ter alguns conhecimentos básicos de segurança… mas também tomar medidas para identificar e resolver problemas de segurança.”
Idealmente, uma transformação DevSecOps deve trazer consigo uma cultura de aprendizado contínuo que ajude os profissionais de TI a identificar e priorizar riscos estratégicos, mesmo em meio a mudanças rápidas na segurança de aplicativos nativos da nuvem, disse Robert Slaughter, CEO da empresa de defesa de TI Defense Unicorns.
As métricas podem ser úteis, mas podem facilitar a perda de foco, disse Slaughter.
“O que enfatizamos são os hábitos diários e o foco nos resultados”, disse ele. “Perguntando: ‘Você está se tornando mais seguro?’ e incutir isso no indivíduo se torna uma maneira muito melhor de gerar o resultado certo em comparação a qualquer métrica específica que pode ser ocultada, ofuscada ou escondida debaixo do tapete.”
Uma cultura segura é o ideal para a Cheng da Komatsu, mas levará tempo.
“As equipes de negócios e os desenvolvedores com quem trabalham – e eles podem ser fornecedores – têm suas próprias prioridades”, disse ele. “Eles têm esse aplicativo que precisam desenvolver e precisam lançá-lo em uma determinada data, e eles têm essa mentalidade e maneira de trabalhar há muito tempo”.
Isso está começando a mudar, disse Cheng, começando com as equipes de produtos adotando ferramentas como o Snyk e pedindo aos fornecedores com os quais trabalham que também apliquem verificações de segurança em seus produtos.
Enquanto isso, em meio a uma escassez generalizada de desenvolvedores e habilidades de segurança cibernética, muitas organizações começaram a usar a automação de TI por meio de plataformas DevOps de autoatendimento para reforçar a segurança do aplicativo sem atrasar os desenvolvedores. O uso de ferramentas de teste automatizadas da Snyk pela Komatsu faz parte de um esforço para automatizar os fluxos de trabalho do DevSecOps em nome dos desenvolvedores.
Educar os desenvolvedores sobre como a conscientização de segurança pode economizar tempo corrigindo vulnerabilidades na produção é um primeiro passo importante no processo DevSecOps, mas “a segunda parte é torná-lo o mais simples e fácil possível”, disse Cheng.
“Ele se torna parte do ambiente de desenvolvimento, seja Eclipse ou Visual Studio, e também podemos incorporar [security] em nosso CI/CD”, disse ele. “Para eles, agora é apenas mais uma ferramenta que eles incorporaram.”
Beth Pariseau, redatora sênior de notícias da TechTarget Editorial, é uma premiada veterana do jornalismo de TI. Ela pode ser alcançada em [email protected] ou no Twitter @PariseauTT.
Contrate mais fácil, mais rápido e mais eficiente.
Nosso sistema testa e avalia a lógica de programação e o código fonte dos seus candidatos e retorna automaticamente para você com o perfil do profissional e o dashboard dos resultados.
Eric Cheng