Todos os artigos

Blog

Formação em desenvolvimento seguro: a pontuação não mede a vigilância

Formação em desenvolvimento seguro: PortSwigger, Juice Shop, Secure Code Warrior, presencial. O que cada opção mede e o que não vê na code review.

  • Por Azziz ERRIME
  • 11 min de leitura
Desenvolvimento seguro: mesa de revisão vista de cima, uma única pilha de folhas iluminada por um candeeiro

TL;DR

  • Uma formação em desenvolvimento seguro avalia-se pelo que os programadores fazem sem instruções, e nenhuma das opções comparadas o mede numa revisão real.
  • Numa experiência publicada em 2022, pedir aos revisores que se concentrassem na segurança multiplicava por oito a deteção de vulnerabilidades.
  • Eu escolheria a plataforma pelo que ensina à equipa e mediria também a vigilância, nas revisões de código reais.

Numa experiência publicada em 2022, um grupo de investigadores pede a 150 programadores que revejam uma alteração de código vulnerável e só a alguns deles pede que pensem na segurança. Estes detetam as falhas oito vezes mais. Qualquer formação em desenvolvimento seguro esbarra neste resultado: mede o que os programadores sabem fazer quando alguém lho pede.

Larissa Braz, Christian Aeberhard, Gül Çalikli e Alberto Bacchelli recrutam 150 programadores, 71 % dos quais declaram pelo menos três anos de experiência profissional. Cada um recebe uma alteração de código para rever, como as que passam todos os dias por um pull request, e essa alteração contém vulnerabilidades. Alguns participantes leem uma instrução adicional, concentrar-se na segurança, e outros recebem também uma lista de verificação. Depois, cada um decide sozinho, perante o código, o que assinala.

O resultado é apresentado na conferência ICSE em 2022. O artigo dos autores resume-o assim: «simply asking reviewers to focus on security during the code review increases eight times the probability of vulnerability detection». A lista de verificação, mesmo adaptada à alteração em revisão, não acrescenta nada de significativo. Os autores lembram, de passagem, que os programadores «often miss even popular and easy-to-detect vulnerabilities during code review».

Os revisores sem instrução não tinham motivo nenhum para ser menos competentes do que os outros. Estavam simplesmente a olhar para outro lado, uma situação que as formações comparadas mais abaixo não reproduzem.

A atenção do revisor pesa mais do que aquilo que sabe

Os autores falam da hipótese da «atitude mental»: o revisor encontra o que procura, e procura o que lhe pediram para procurar. A revisão de código, o momento em que um programador revê a alteração de um colega antes de esta entrar no código comum, incide primeiro na lógica, nos nomes, nos testes. A segurança só entra quando alguém a põe em cima da mesa.

Na prática, uma falha de injeção num pull request parece uma linha banal. Uma variável passa de um formulário para uma consulta sem qualquer filtragem, e nada a denuncia aos olhos de quem confirma que a funcionalidade faz o que deve. O revisor que sabe reconhecer uma injeção deixa-a passar se não estiver à procura dela. O atacante só procura isso: identifica os campos que aceitam dados introduzidos e segue esses dados até à base de dados.

Ora, as plataformas comparadas mais abaixo fazem a pergunta no lugar do revisor: eis o código, encontre a falha. Foi exatamente essa a instrução dada a uma parte dos revisores da experiência. Uma formação em desenvolvimento seguro pode, portanto, fazer progredir o conhecimento sem dizer nada sobre a atenção.

As plataformas de formação em desenvolvimento seguro medem sobretudo um desempenho a pedido

Neste quadro das opções de formação em segurança de aplicações, só incluo o que os fornecedores ou a imprensa especializada publicam. A linha «presencial» descreve a prática corrente, não um fornecedor.

Opção O que se faz O que é medido e reportado O programador sabe que está a ser avaliado?
PortSwigger Web Security Academy Labs de ataque a aplicações web, por exemplo 30 sobre cross-site scripting Labs resolvidos, progressão, ranking Hall of Fame; a Academy é gratuita Sim
OWASP Juice Shop Desafios numa aplicação deliberadamente vulnerável, gratuita e open source Quadro de pontuação dos desafios Sim
Snyk Learn Lições e percursos, gratuitos Percentagem de conclusão Sim
Security Journey Percursos de formação em código seguro, com preço sob consulta Avaliações, relatórios para o LMS (SCORM, xAPI) Sim
Secure Code Warrior Desafios sobre código Trust Score por programador; o Trust Agent: AI liga os commits reais às ferramentas de IA utilizadas Sim na formação, em parte nos commits acompanhados
Immersive (Developer AI Ranges) Pull requests e triagem de um backlog perante agentes de código O que foi detetado ou falhado, com um veredicto de referência Sim, o exercício é anunciado
Formação presencial Aulas e trabalhos práticos com um formador Folha de presenças, avaliação no fim da sessão Sim

Cada uma tem o seu ponto forte: a PortSwigger ensina a mecânica dos ataques web sem custar um euro. O OWASP Juice Shop, gratuito e open source, serve de terreno para workshops. O Snyk Learn propõe lições e percursos, também gratuitos. A Security Journey liga os seus resultados à ferramenta de gestão da formação da empresa. A Secure Code Warrior põe os programadores a resolver desafios sobre código. A formação presencial permite fazer perguntas a um formador durante os trabalhos práticos.

A Immersive vai mais longe na aproximação ao real. Desde 29 de julho de 2026, os seus Developer AI Ranges colocam os programadores perante pull requests e agentes de código. Cada exercício termina com um veredicto de referência sobre «what was caught or missed». De todas as abordagens públicas que encontrei, é a mais próxima de uma revisão verdadeira. Mesmo assim, o programador sabe que está num exercício. Na Secure Code Warrior, só o Trust Agent: AI olha para commits reais. Cruza o Trust Score e o uso de IA com vulnerabilidades, mas não diz o que a revisão deixou passar.

Se nenhuma destas medições observa a própria revisão, para onde olha o auditor quando verifica a formação em segurança dos programadores?

Barraca de tiro ao alvo numa feira, com os alvos atingidos no centro e um alvo tombado na sombra

Os alvos anunciados são atingidos em cheio. O do quotidiano espera na sombra.

A auditoria valida a formação sem ver a revisão de segunda-feira

Veja-se o PCI DSS, a norma de segurança dos cartões de pagamento. O requisito 6.2.2 exige que os programadores de software à medida recebam formação em segurança pelo menos uma vez a cada 12 meses. Para o verificar, o avaliador segue um procedimento preciso, o 6.2.2.b: «Examine training records and interview personnel». Lê os registos e entrevista as equipas.

O registo diz quem fez que formação, em que data, com que pontuação. É precisamente isso que as plataformas do quadro reportam, no caso da Security Journey, por exemplo, diretamente na ferramenta de gestão da formação. Nada, neste circuito, olha para o destino do último pull request que mexia numa consulta à base de dados.

Não tenho nada a apontar a este circuito: prova que houve formação, que é o que se lhe pede. O risco está no que se conclui a partir dele: uma taxa de conclusão de 100 % tranquiliza a administração quanto a uma competência que ninguém viu em ação. A distância aumenta com a IA, que faz crescer o volume de código a rever, como expliquei num artigo anterior sobre code review.

Falta a objeção mais sólida: algumas plataformas afirmam precisamente medir um efeito nas vulnerabilidades, e não apenas uma presença.

Uma descida das vulnerabilidades após uma formação em desenvolvimento seguro não diz de onde vem a vigilância

A 15 de outubro de 2024, a Secure Code Warrior publicou um estudo, apresentado pela CyberScoop, assente nos dados de 600 clientes empresariais. Nas organizações com mais de 7 000 programadores que seguem um mesmo programa, o fornecedor mede menos 47 a 53 % de vulnerabilidades.

Levo-o a sério, porque mede um resultado, as vulnerabilidades, quando muitos estudos sobre formação não passam da satisfação. É também um estudo do próprio fornecedor, feito com os dados da sua plataforma, e os documentos públicos que consegui ler não detalham como as vulnerabilidades foram contadas. Pode estar certo e, mesmo assim, não responder à pergunta deste artigo.

Numa grande organização que passou pela formação, a descida das falhas no código mistura várias causas: melhores reflexos ao escrever, ferramentas de análise mais bem afinadas, revisões mais atentas. O estudo não permite dizer qual delas pesou. Acontece que a vigilância na revisão é justamente a parte que nenhuma linha do quadro observa na própria revisão.

A formação em desenvolvimento seguro continua, portanto, a ser necessária: sem ela, ninguém sabe como é uma injeção no meio de um pull request. Falta completá-la com uma medição do que acontece fora do exercício.

A linha de segurança no template de pull request é o gesto mais barato

Aprende-se na plataforma que melhor se ajusta à stack técnica da equipa. Mede-se noutro lado, no trabalho real, aquilo que a revisão deixa passar. Numa equipa, eu faria isto, por esta ordem:

  • começar pelos recursos gratuitos, PortSwigger, Juice Shop e Snyk Learn, para ver o que prende a equipa antes de assinar um contrato;
  • escolher a plataforma paga em função das linguagens e frameworks da sua equipa, não do tamanho do catálogo;
  • perguntar ao fornecedor o que se pode exportar: uma taxa de conclusão, ou resultados por competência que possa cruzar com as suas revisões;
  • acompanhar à parte o que a revisão deixa passar, ligando cada falha encontrada mais tarde, num teste ou em produção, à revisão por onde passou;
  • acrescentar ao template de pull request uma linha que pergunte se a segurança foi revista.

Esta última linha é o gesto mais barato, e o mais próximo da instrução testada em 2022. Ainda não sei se mantém o efeito quando se torna rotina.

Esclareço: eu dou formações e meço este tipo de desvio, aquilo que os programadores deixam passar quando reveem código escrito por uma IA. A formação dá-lhes o vocabulário. Quero perceber em que momento o usam sem que ninguém lho peça.

Posto de sinalização ferroviária vazio, com uma alavanca marcada por uma fita vermelha

O gesto que conta faz-se no posto, no momento em que o comboio passa.

O revisor sem instrução é a sua equipa numa segunda-feira de manhã

Volto aos 150 programadores da experiência. Os que não receberam instrução são o retrato fiel das suas equipas numa segunda-feira de manhã, com uma fila de pull requests para despachar antes da reunião. Talvez tenham aprendido a reconhecer uma falha, mas ninguém lhes pediu que a procurassem naquele momento.

Uma formação em desenvolvimento seguro bem escolhida ensina-lhes o que procurar. Nenhuma garante que vão procurar. Por isso, eu não escolheria uma plataforma pelo catálogo nem pela pontuação média que apresenta. Por cada euro gasto em formação, poria uma medição do que passa incólume pela revisão real.

Há um ponto em que mantenho uma dúvida: assim que um programador sabe que alguém olha para as suas revisões, revê melhor. O código ganha com isso, e a medição perde, porque volta a ser uma instrução. Ainda não descobri como observar a vigilância sem a alterar.

Perguntas frequentes sobre formação em desenvolvimento seguro

O que é secure coding?

O secure coding, ou desenvolvimento seguro, reúne as práticas que evitam introduzir falhas ao escrever o código: validar as entradas, controlar os acessos, escolher dependências seguras. A norma PCI DSS torna-o tema de formação obrigatória para os programadores de software à medida. O requisito 6.2.2 exige formação pelo menos a cada 12 meses, que abranja nomeadamente as «secure coding techniques».

Que curso de desenvolvimento seguro escolher?

Para uma primeira formação em desenvolvimento seguro sem orçamento, a Web Security Academy da PortSwigger é totalmente gratuita, tal como o OWASP Juice Shop e o Snyk Learn. As plataformas pagas acrescentam, entre outras coisas, avaliações e relatórios para o acompanhamento da formação. Em qualquer caso, meça à parte o que passa nas suas revisões de código, onde uma simples instrução de segurança muda claramente a deteção, segundo Braz e os colegas.

Existe formação OWASP gratuita?

Sim, o OWASP Juice Shop, projeto da fundação OWASP publicado sob licença MIT, é uma aplicação deliberadamente vulnerável cujos desafios se acompanham num quadro de pontuação. Para um percurso mais guiado, a Web Security Academy da PortSwigger, também gratuita, cobre as grandes famílias de falhas web.

O que é a Secure Code Warrior?

A Secure Code Warrior é uma plataforma de formação em código seguro que atribui a cada programador um Trust Score. Desde março de 2026, o seu módulo Trust Agent: AI liga os commits às ferramentas de IA que os influenciaram, segundo a Help Net Security. Um estudo do próprio fornecedor, publicado em outubro de 2024, reivindica menos 47 a 53 % de vulnerabilidades nas grandes organizações que receberam formação.

Fontes