Implementação de medidas de segurança para programadores numa organização com mais de 5 000 engenheiros

As grandes empresas de engenharia gostam de acreditar que os seus maiores problemas são de natureza técnica. Se ao menos alguém aprovasse o orçamento para a ferramenta mais recente, tudo ficaria resolvido. Ultimamente, a aposta predominante é que a solução milagrosa reside na programação intuitiva, impulsionada pela sua versão preferida de LLM. Mas as patologias das grandes organizações raramente são de natureza técnica. 

Na minha experiência, trata-se de problemas relacionados com os processos e que podem manifestar-se em dois extremos opostos. Num extremo, temos equipas presas numa paralisia de análise, num ciclo interminável de reuniões, revisões e conceção orientada para o consenso, com poucos resultados concretos. No outro extremo, temos as pessoas que «saltam antes de olhar», com uma tendência para a execução precipitada que leva a muitos erros autoinfligidos devido à falta de introspecção.

Por volta do momento em que uma organização ultrapassa os 5 000 colaboradores ativos, a natureza da transformação em matéria de segurança muda completamente. As ferramentas deixam de ser o fator limitante. O orçamento deixa de ser o fator limitante. Até mesmo o talento deixa de ser o fator limitante. O que se torna escasso é o alinhamento.

A realidade é que, quando uma empresa atinge esta dimensão, já dispõe de uma estrutura de segurança em funcionamento, de uma tolerância ao risco definida e de uma organização de segurança estruturada, em linhas gerais, de acordo com rácios de pessoal já conhecidos. Um padrão comum é um profissional de segurança por cada 100 engenheiros, o que significa que uma empresa com 5 000 programadores tem provavelmente uma equipa de segurança de 50 pessoas que procura influenciar milhares de decisões relacionadas com software por dia. A questão não é se a segurança existe. A questão é se esta é capaz de se adaptar à escala.

Este artigo descreve as lições aprendidas com a implementação de programas de segurança para programadores em organizações desta dimensão e explica por que razão o caminho para o sucesso é muito diferente do que a maioria dos CISOs espera.

Por que razão as implementações de segurança por parte dos programadores falham à escala empresarial

A maioria das implementações de segurança falha por uma razão surpreendentemente simples: são concebidas como implementações de software, em vez de mudanças culturais. Os responsáveis pela segurança partem frequentemente do pressuposto de que a combinação certa de ferramentas (por exemplo, SAST, SCA, container , secrets ) produzirá melhores resultados se for implementada em escala suficientemente ampla. Mas a adoção de ferramentas é a parte fácil.

O mais difícil é definir prioridades nas equipas de engenharia. Os programadores já têm mais trabalho do que aquele que conseguem concluir num sprint. Os prazos dos produtos dominam a definição de prioridades do backlog. A velocidade na implementação de funcionalidades é visível e recompensada. As correções de segurança parecem, muitas vezes, abstratas e impostas de fora. Quando um programa de segurança é implementado nesse ambiente, a reação padrão é previsível: criam-se tickets de segurança, estes entram no backlog e vão-se acumulando silenciosamente.

A ampliação da cobertura das análises não altera esta realidade. Na verdade, quanto mais problemas forem identificados sem que haja uma responsabilidade clara, pior se torna a situação. As equipas de segurança acreditam frequentemente que estão a reduzir o risco ao aumentar a visibilidade, mas, na prática, acabam por amplificar riscos não geridos. Isto porque todos sabem que os problemas existem, mas ninguém assume realmente a responsabilidade por eles.

‍

Os desafios incontornáveis que todas as organizações com mais de 5 000 engenheiros enfrentam

As grandes organizações de engenharia operam sob um conjunto de restrições estruturais com as quais as empresas mais pequenas raramente se deparam. Em primeiro lugar, existe a fragmentação do SDLC. Uma empresa com milhares de engenheiros executa, quase certamente, vários ciclos de vida de desenvolvimento em simultâneo. Algumas equipas fazem implementações diariamente. Outras, trimestralmente. Algumas dependem de sistemas legados criados há uma década, que todos têm receio de tocar por medo de que deixem de funcionar completamente e se tornem um problema pessoal. Em segundo lugar, há a heterogeneidade tecnológica. Um ambiente empresarial típico pode incluir dezenas de linguagens de programação, múltiplos sistemas de CI/CD, várias plataformas de infraestrutura e uma mistura de fluxos de trabalho nativos da nuvem e legados.

As ferramentas de segurança que funcionam de forma eficaz num ambiente podem ser praticamente impossíveis de implementar noutro. Em terceiro lugar, o poder de aplicação centralizada é limitado e não existe um sistema único que abranja todo o âmbito das aplicações e superfície de ataque na nuvem de uma organização superfície de ataque na nuvem. 

Mesmo que, tecnicamente, o CISO responda perante o CIO ou o CTO, as equipas de segurança raramente controlam as prioridades da lista de tarefas pendentes dos grupos de engenharia de produto. Elas influenciam-nas, mas não têm controlo sobre elas. Isto cria uma tensão fundamental.

E os problemas de segurança mais perigosos são, muitas vezes, aqueles que exigem alterações na arquitetura, atualizações de dependências ou uma refatoração profunda. O tipo de trabalho que os engenheiros evitam instintivamente, porque não se enquadra perfeitamente no planeamento de sprints de duas semanas.

As tarefas cuja estimativa ultrapassa os 13 pontos de história são frequentemente adiadas indefinidamente. Trata-se de projetos disfarçados de tickets. O resultado é uma acumulação crescente de trabalho relacionado com a segurança que todos compreendem a nível intelectual, mas que ninguém se sente com autonomia ou motivado para priorizar.

‍

O primeiro objetivo é a apropriação, não a cobertura

Um dos erros mais comuns cometidos pelos responsáveis pela segurança é partir do princípio de que a cobertura das ferramentas equivale a progresso. A execução de scanners em todos os repositórios pode gerar painéis impressionantes, mas sem um sentido de responsabilidade, esses painéis tornam-se pouco mais do que catálogos de riscos. O verdadeiro progresso começa com uma pergunta diferente:

Quem é responsável por resolver o quê?

Os programas de segurança escaláveis começam por identificar os influenciadores dentro da organização de engenharia. Não os gestores formais. Não os arquitetos que constam no organograma. Mas sim os programadores cujas opiniões moldam efetivamente o comportamento da engenharia. Todas as grandes organizações de engenharia os têm. São os engenheiros e programadores que transmitem a cultura e a quem os outros recorrem antes de tomarem decisões arquitetónicas. Uma abordagem surpreendentemente eficaz é o modelo de formação de formadores:

1. Identifique 10 programadores experientes que gozam de prestígio em toda a organização
2. Formá-los exaustivamente em práticas de desenvolvimento seguro
3. Peça-lhes que formem 100 especialistas em engenharia
4. Esses campeões influenciam as suas próprias equipas, compostas por 50 programadores cada

Em poucas semanas, as práticas de segurança disseminam-se entre milhares de engenheiros sem que a equipa de segurança tenha de dar formação diretamente a todos. Em grande escala, a influência espalha-se através da credibilidade entre pares.

Como os CISOs escolhem as equipas-piloto (e por que razão a maioria dos projetos-piloto induz em erro)

A maioria dos programas de segurança empresarial começa com um projeto-piloto. Em teoria, isso faz sentido. No entanto, a forma como os projetos-piloto são selecionados muitas vezes leva a resultados enganadores.

Os responsáveis pela segurança costumam escolher um de dois tipos de equipas:

1. A equipa de engenharia mais experiente
2. A equipa mais ansiosa por participar

Ambas as abordagens produzem resultados artificialmente positivos. As equipas de alto desempenho já mantêm boas práticas de engenharia. As suas atualizações de dependências estão em dia. Os seus pipelines de CI/CD são modernos. A sua arquitetura é mantida ativamente. A implementação de ferramentas de segurança nessas equipas produz métricas impressionantes, mas também uma ilusão perigosa de que as implementações serão escaladas sem problemas. A realidade só se revela mais tarde. Quando a implementação chega a serviços legados, equipas com falta de pessoal ou sistemas que não são atualizados de forma significativa há anos.

Uma abordagem mais eficaz para a seleção de pilotos inclui, de forma intencional, uma complexidade representativa:

• Um serviço antigo
• Uma equipa moderna e nativa da nuvem
• Um grupo de produtos de alta rotatividade
• Uma plataforma interna de movimento lento

O objetivo de um projeto-piloto é identificar os obstáculos numa fase inicial.

O modelo de implementação em quatro fases que funciona em grande escala

Os programas de segurança para programadores bem-sucedidos tendem a seguir um padrão de implementação consistente. Raramente isso acontece de forma intencional, mas os CISOs experientes acabam por adotar o mesmo modelo.

Fase 1: Visibilidade sem aplicação de medidas coercivas

A primeira fase centra-se na observabilidade. As ferramentas de segurança são executadas em repositórios e na infraestrutura, mas não bloqueiam compilações nem implementações. As detecções são identificadas, categorizadas e analisadas. Esta fase ajuda as equipas de segurança a responder a questões críticas:

• Quais são as vulnerabilidades que ocorrem com maior frequência?
• Quais são as equipas que respondem rapidamente?
• Que tipos de correções causam mais atrito?

Encarem isto como um exercício de aprendizagem.

‍

Fase 2: Ciclos de feedback dos programadores

Segue-se o envolvimento dos programadores. As conclusões são apresentadas de forma a que os engenheiros possam realmente agir em conformidade. Os falsos positivos são eliminados de forma rigorosa. A documentação melhora. São partilhados exemplos de correção. Esta fase também introduz a motivação intrínseca. Os programadores raramente reagem bem a medidas impostas de cima para baixo. Mas reagem aos desafios de resolução de problemas. Algumas organizações gamificam com sucesso o trabalho de correção, permitindo que as equipas competam com base no número de problemas de segurança resolvidos por sprint. Quando os engenheiros começam a corrigir problemas voluntariamente, sabe-se que o programa está a começar a funcionar.

{{falsos positivos}}

Fase 3: Medidas de proteção e políticas

Só depois de os programadores confiarem no sistema é que surgem os mecanismos de aplicação. Estes assumem geralmente a forma de medidas de proteção. Entre os exemplos contam-se:

• Corrigir vulnerabilidades críticas em novas dependências
• Evitar secrets sejam introduzidos nos repositórios
• Aplicar níveis mínimos de atualizações para imagens base

A ênfase continua a ser colocada na prevenção de novos riscos, em vez de punir falhas passadas. O «porquê» tem de estar presente a par do «o quê», para que não estejamos apenas a jogar uma versão avançada ou acelerada do «bate na toupeira» com vulnerabilidades e configurações incorretas.

‍

Fase 4: Responsabilização dos executivos

A fase final introduz a visibilidade da liderança. As métricas aparecem nos painéis de controlo da liderança de engenharia:

• Tempo até à correção
• Categorias de vulnerabilidades recorrentes
• Tendências do volume de trabalho pendente em matéria de segurança

Nesta fase, a segurança passa a fazer parte das discussões sobre o desempenho da engenharia. E é aí que a mudança cultural se torna palpável e duradoura.

O que não se deve impor logo no início (e porquê)

A forma mais rápida de comprometer a implementação de medidas de segurança é a sua aplicação prematura. Entre os erros mais comuns cometidos numa fase inicial, destacam-se:

• O bloqueio baseia-se em limiares de vulnerabilidade
• Estabelecer prazos obrigatórios para a aplicação de correções
• Aplicação de políticas globais de gravidade

Estas medidas parecem decisivas, mas muitas vezes provocam uma reação contrária. Quando os engenheiros se deparam de repente com as suas implementações bloqueadas por ferramentas que não solicitaram, rapidamente encontram formas de contornar a situação. Desativam os scanners e criam ramificações nos pipelines. Ignoram os alertas. O resultado é uma segurança mais fraca e uma relação prejudicada entre as equipas de engenharia e de segurança. A adoção deve preceder a imposição. A confiança deve preceder o controlo.

Os indicadores que revelam a adoção efetiva

dashboards de segurança centrar-se nos números errados. O número de vulnerabilidades, de análises concluídas ou de repositórios analisados proporciona visibilidade, mas pouco diz sobre a mudança de comportamento.

Entre os indicadores mais significativos, destacam-se:

• Taxa de correção: os programadores estão realmente a resolver as falhas detetadas? Uma taxa de correção crescente costuma indicar um maior envolvimento.
• Tempo de resolução: com que rapidez são resolvidos os problemas de gravidade elevada? As organizações com uma cultura de segurança sólida entre os programadores costumam ver as correções críticas resolvidas em poucos dias, e não em semanas.
• Constataciones recorrentes: Estão as mesmas vulnerabilidades a surgir repetidamente? Se for esse o caso, o problema não reside na correção. Reside na formação dos programadores ou nos padrões arquitetónicos.
• Sinais de desinteresse: O sinal de alerta mais precoce e mais importante de uma falha é o facto de os programadores ignorarem o sistema, encerrarem tickets sem correções ou ligações para alterações no código, queixas relacionadas com a fadiga de alertas e quedas repentinas na atividade de resolução de problemas.

‍

Quando a implementação de um programa de segurança está a falhar

Mesmo as implementações bem planeadas podem enfrentar dificuldades. Os responsáveis pela segurança com experiência reconhecem os sinais de alerta numa fase inicial:

• A lista de pendências está a crescer mais rapidamente do que as soluções
• Engenheiros que contornam as ferramentas de análise
• Os defensores da segurança estão a perder influência

Quando isto acontece, o instinto é muitas vezes o de reforçar a fiscalização, mas essa é quase sempre a decisão errada. Em vez disso, os CISOs bem-sucedidos fazem uma pausa e colocam três perguntas:

1. Será que estamos a levantar demasiadas questões ao mesmo tempo?
2. Os programadores recebem orientações claras sobre como corrigir os problemas?
3. Estamos a dar prioridade às vulnerabilidades que realmente importam?

A última pergunta leva-nos a um dos princípios mais importantes dos programas de segurança em grande escala:

O Princípio de Pareto aplica-se aqui: na maioria dos ambientes, cerca de 20 % das vulnerabilidades são responsáveis por 80 % do risco real para a organização. Os programas de segurança que se concentram nessas questões de alto impacto reduzem drasticamente o risco, minimizando simultaneamente os obstáculos para os programadores. Os programas que tentam resolver tudo ao mesmo tempo acabam por sucumbir ao seu próprio peso.

Incorporar a abordagem de segurança no ciclo de vida do desenvolvimento de software (SDLC)

Um programa de segurança para programadores a longo prazo acaba por avançar para as fases iniciais do processo. Em vez de reagirem aos relatórios de vulnerabilidades, as organizações começam a preveni-las já na fase de conceção e desenvolvimento.

Uma das ferramentas mais eficazes para esta transformação é a modelagem de ameaças. Muitos programadores só se deparam com a questão da segurança quando um scanner deteta um problema. Aprendem a regra, mas não o raciocínio subjacente. A modelagem de ameaças altera essa dinâmica.

Ajuda os programadores a compreender:

• Por que é que as decisões relativas ao armazenamento de sessão são importantes
• Como os padrões de autenticação criam superfícies de ataque
• Porquê Top 10 OWASP aparecem repetidamente

Quando os engenheiros compreendem o «porquê», deixam de encarar as correções de segurança como exigências externas e começam a conceber sistemas que evitam esses problemas por completo. A parceria entre programadores juniores e engenheiros experientes acelera ainda mais esta aprendizagem. Os programadores seniores transmitem naturalmente hábitos como a disciplina na documentação, os testes automatizados e a configuração segura da infraestrutura. A segurança passa a ser menos uma questão de analisar o código e mais uma questão de como os engenheiros pensam enquanto o escrevem.

A única regra que determina o sucesso em grande escala

Depois de observar dezenas de programas de segurança para programadores a terem sucesso ou a falharem, há um princípio que determina consistentemente o resultado: a segurança deve reduzir a carga cognitiva dos programadores, e não aumentá-la.

Se as ferramentas gerarem um ruído excessivo, os engenheiros desligam-se. Se as orientações de correção não forem claras, os engenheiros adiam as correções. Se a imposição de regras vier antes da confiança, os engenheiros contornam os controlos. Mas quando as ferramentas de segurança:

• apresentar conclusões passíveis de ação
• dar prioridade aos riscos significativos
• integrar nos fluxos de trabalho existentes

Os programadores reagem como sempre e resolvem o problema.

E quando um número suficiente de pessoas começa a resolver o problema, acontece algo extraordinário. A segurança torna-se um hábito.

E numa organização com 5 000 colaboradores, são os hábitos que, em última análise, determinam o nível de segurança de toda a empresa.

‍

Essas lições influenciaram profundamente a filosofia de design subjacente às plataformas modernas de segurança para programadores, como Aikido. Um sistema concebido para identificar riscos significativos, minimizando simultaneamente a carga cognitiva sobre os programadores.

{{walkthrough}}