Grandes organizações de engenharia gostam de acreditar que seus maiores problemas são técnicos. Se alguém aprovasse o orçamento para a ferramenta mais recente, tudo estaria resolvido. Ultimamente, a aposta predominante é que a bala de prata seja o vibe coding impulsionado pela sua versão favorita de LLM. Mas as patologias de grandes organizações raramente são de natureza técnica.
Na minha experiência, são problemas orientados a processos e podem se manifestar em duas extremidades diferentes do espectro. De um lado, você tem equipes presas na paralisia por análise, ciclando interminavelmente em reuniões, revisões e design baseado em consenso, com pouco a apresentar. Do outro lado, você tem as pessoas que agem impulsivamente, com um viés de execução que leva a muitas feridas autoinfligidas devido à falta de introspecção.
No momento em que uma organização ultrapassa 5.000 committers ativos, a natureza da transformação 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 esse porte, ela já possui uma postura de segurança funcional, uma tolerância a risco definida e uma organização de segurança estruturada aproximadamente com base em proporções de pessoal conhecidas. Um padrão comum é um profissional de segurança para cada 100 engenheiros, o que significa que uma empresa com 5.000 desenvolvedores provavelmente tem uma equipe de segurança de 50 pessoas tentando influenciar milhares de decisões de software por dia. A questão não é se a segurança existe. A questão é se ela escala.
Este artigo descreve as lições aprendidas com a implementação de programas de segurança para desenvolvedores em organizações dessa escala e por que o caminho para o sucesso é muito diferente do que a maioria dos CISOs espera.
Por que as implementações de segurança para desenvolvedores falham em escala empresarial
A maioria das implementações de segurança falha por uma razão surpreendentemente simples: elas são projetadas como implantações de software em vez de mudanças culturais. Líderes de segurança frequentemente partem do pressuposto de que a combinação certa de ferramentas (por exemplo, SAST, SCA, varredura de Container, detecção de Secrets) produzirá resultados aprimorados se implementada de forma suficientemente ampla. Mas a adoção de ferramentas é a parte fácil.
A parte difícil é a priorização dentro das organizações de engenharia. Os desenvolvedores já têm mais trabalho do que podem concluir em um sprint. Prazos de produtos dominam a priorização do backlog. A velocidade de recursos é visível e recompensada. Correções de segurança frequentemente parecem abstratas e impostas externamente. Quando um programa de segurança é implementado nesse ambiente, a resposta padrão é previsível: tickets de segurança são criados, entram no backlog e se acumulam silenciosamente.
Nada sobre a cobertura de varredura muda essa realidade. Na verdade, quanto mais descobertas você expõe sem uma propriedade clara, pior a situação se torna. Equipes de segurança frequentemente acreditam que estão reduzindo o risco ao aumentar a visibilidade, mas na prática, às vezes estão amplificando o risco não gerenciado. Porque todos sabem que os problemas existem, mas ninguém realmente os assume.
As restrições difíceis que toda organização com mais de 5.000 engenheiros enfrenta
Grandes organizações de engenharia operam sob um conjunto de restrições estruturais que empresas menores raramente encontram. Primeiro, há a fragmentação do SDLC. Uma empresa com milhares de engenheiros quase certamente executa múltiplos ciclos de vida de desenvolvimento simultaneamente. Algumas equipes fazem deploy diariamente. Outras fazem trimestralmente. Algumas dependem de sistemas legados construídos há uma década que todos têm medo de tocar, por receio de que parem de funcionar completamente e se tornem um problema pessoal. Segundo, há a heterogeneidade tecnológica. Um ambiente empresarial típico pode incluir dezenas de linguagens de programação, múltiplos sistemas CI/CD, várias plataformas de infraestrutura e uma mistura de fluxos de trabalho Cloud-native e legados.
Ferramentas de segurança que funcionam elegantemente em um ambiente podem ser quase impossíveis de implementar em outro. Terceiro, há um poder de aplicação central limitado e nenhum sistema único que capture todo o escopo da superfície de ataque de aplicações e da superfície de ataque na nuvem de uma organização.
Mesmo que o CISO se reporte tecnicamente ao CIO ou CTO, as equipes de segurança raramente controlam as prioridades do backlog dos grupos de engenharia de produto. Eles as influenciam, mas não as possuem. Isso cria uma tensão fundamental.
E os problemas de segurança mais perigosos são frequentemente aqueles que exigem mudança arquitetural, atualizações de dependência ou refatoração significativa. Os tipos de trabalho que os engenheiros evitam instintivamente porque não se encaixam perfeitamente no planejamento de sprints de duas semanas.
Tarefas estimadas acima de aproximadamente 13 story points frequentemente são adiadas indefinidamente. Estes são projetos disfarçados de tickets. O resultado é um backlog crescente de trabalho de segurança que todos entendem intelectualmente, mas ninguém se sente capacitado ou incentivado a priorizar.
O primeiro objetivo é a propriedade, não a cobertura
Um dos erros mais comuns que os líderes de segurança cometem é assumir que a cobertura de ferramentas equivale a progresso. Executar scanners em cada repositório pode gerar dashboards impressionantes, mas sem propriedade, esses dashboards se tornam pouco mais do que catálogos de risco. O progresso real começa com uma pergunta diferente:
Quem é responsável por corrigir o quê?
Programas de segurança que escalam começam identificando influenciadores dentro da organização de engenharia. Não os gerentes formais. Não os arquitetos no organograma. Mas os desenvolvedores cujas opiniões realmente moldam o comportamento da engenharia. Toda grande organização de engenharia os possui. São os engenheiros e desenvolvedores que carregam a cultura e que outros consultam antes de tomar decisões arquitetônicas. Uma abordagem surpreendentemente eficaz é um modelo de treinamento de treinadores:
- Identifique 10 desenvolvedores master respeitados em toda a organização
- Treine-os profundamente em práticas de desenvolvimento seguro
- Faça com que eles treinem 100 campeões de engenharia
- Esses campeões influenciam suas próprias equipes de 50 desenvolvedores cada
Em poucas semanas, as práticas de segurança se propagam por milhares de engenheiros sem exigir que a equipe de segurança treine diretamente a todos. Em escala, a influência se espalha pela credibilidade dos pares.
Como os CISOs escolhem equipes piloto (e por que a maioria dos pilotos engana)
A maioria dos programas de segurança corporativa começa com um piloto. Isso é sensato em teoria. Mas a forma como os pilotos são escolhidos frequentemente garante resultados enganosos.
Líderes de segurança frequentemente selecionam um de dois tipos de equipes:
- A equipe de engenharia mais madura
- A equipe mais ansiosa para participar
Ambos produzem resultados artificialmente positivos. Equipes de alto desempenho já mantêm uma forte higiene de engenharia. Suas atualizações de dependência estão em dia. Seus pipelines de CI/CD são modernos. Sua arquitetura é ativamente mantida. A implantação de ferramentas de segurança nesses locais produz métricas impressionantes, mas também uma perigosa ilusão de que as implementações escalarão sem problemas. A realidade aparece mais tarde. Quando a implementação atinge serviços legados, equipes com poucos recursos ou sistemas que não foram significativamente atualizados em anos.
Uma abordagem melhor para a seleção de pilotos inclui intencionalmente complexidade representativa:
- Um serviço legado
- Uma equipe moderna nativa da Cloud
- Um grupo de produto de alta velocidade
- Uma plataforma interna de movimento lento
O objetivo de um piloto é descobrir atritos precocemente.
O modelo de implementação em quatro fases que funciona em escala
Programas de segurança para desenvolvedores bem-sucedidos tendem a seguir um padrão de implementação consistente. Raramente acontece intencionalmente, mas CISOs experientes eventualmente convergem para o mesmo modelo.
Fase 1: Visibilidade sem imposição
A primeira fase foca na observabilidade. Ferramentas de segurança são executadas em repositórios e infraestrutura, mas não bloqueiam builds ou deployments. As descobertas são expostas, categorizadas e analisadas. Esta etapa ajuda as equipes de segurança a responder a perguntas críticas:
- Quais vulnerabilidades aparecem com mais frequência?
- Quais equipes respondem rapidamente?
- Quais tipos de correções criam mais atrito?
Trate isso como um exercício de aprendizado.
Fase 2: Loops de feedback do desenvolvedor
Em seguida, vem o engajamento do desenvolvedor. As descobertas são apresentadas de maneiras que os engenheiros podem realmente agir. Falsos positivos são agressivamente removidos. A documentação melhora. Exemplos de remediação são compartilhados. Esta fase também introduz a motivação intrínseca. Os desenvolvedores raramente respondem bem à imposição de cima para baixo. Mas eles respondem a desafios de resolução de problemas. Algumas organizações gamificam com sucesso o trabalho de remediação, permitindo que as equipes compitam com base no número de problemas de segurança resolvidos por sprint. Quando os engenheiros começam a corrigir problemas voluntariamente, você sabe que o programa está começando a funcionar.
{{falsos-positivos}}
Fase 3: Guardrails e Política
Somente depois que os desenvolvedores confiam no sistema é que os mecanismos de aplicação aparecem. Estes geralmente assumem a forma de guardrails. Exemplos incluem:
- Bloqueando vulnerabilidades críticas em novas dependências
- Evitando que Secrets entrem em repositórios
- Impondo níveis mínimos de patch para imagens base
A ênfase permanece na prevenção de novos riscos, em vez de punir a dívida histórica. O “porquê” precisa estar presente junto com o “o quê” para que não estejamos apenas jogando uma versão avançada ou acelerada de whack-a-mole com vulnerabilidades e configurações incorretas.
Fase 4: Responsabilidade executiva
A fase final introduz a visibilidade da liderança. Métricas aparecem nos dashboards de liderança de engenharia:
- Tempo para remediação
- Categorias de vulnerabilidades recorrentes
- Tendências do backlog de segurança
Neste ponto, a segurança se torna parte das discussões de desempenho de engenharia. E é aí que a mudança cultural se torna palpável e duradoura.
O que não impor cedo (e por quê)
A maneira mais rápida de descarrilar uma implementação de segurança é a aplicação prematura. Erros comuns no início incluem:
- Bloquear builds com base em limites de vulnerabilidade
- Impor prazos universais para patches
- Aplicar políticas de severidade globais
Essas ações parecem decisivas, mas frequentemente geram uma reação negativa. Quando os engenheiros de repente veem seus deployments bloqueados por ferramentas que não solicitaram, eles rapidamente descobrem soluções alternativas. Eles desativam scanners e fazem fork de pipelines. Eles ignoram os alertas. O resultado é uma segurança pior e um relacionamento danificado entre as equipes de engenharia e segurança. A adoção deve vir antes da aplicação. A confiança deve vir antes do controle.
As métricas que sinalizam a adoção real
Dashboards de segurança frequentemente se concentram nos números errados. Contagens de vulnerabilidades, scans concluídos ou repositórios analisados fornecem visibilidade, mas dizem pouco sobre a mudança de comportamento.
Indicadores mais significativos incluem:
- Taxa de correção: Os desenvolvedores estão realmente resolvendo os achados? Uma taxa de remediação crescente geralmente sinaliza um engajamento cada vez maior.
- Tempo para remediação: Com que rapidez os problemas de alta gravidade são corrigidos? Organizações com culturas de segurança de desenvolvedores saudáveis geralmente veem correções críticas resolvidas em dias, não semanas.
- Descobertas recorrentes: As mesmas vulnerabilidades estão aparecendo repetidamente? Se sim, o problema não é a remediação, mas sim a educação do desenvolvedor ou os padrões arquitetônicos.
- Sinais de desengajamento: O sinal de alerta mais precoce e importante de falha é quando os desenvolvedores ignoram o sistema, fecham tickets sem correções ou links para commits de código, reclamam de fadiga de alertas e há quedas repentinas na atividade de remediação.
Quando a implementação de um programa de segurança está falhando
Mesmo implementações bem projetadas encontram turbulência. Líderes de segurança experientes reconhecem os sinais de alerta precocemente:
- Backlogs crescendo mais rápido que as correções
- Engenheiros ignorando ferramentas de varredura
- Security champions perdendo influência
Quando isso acontece, o instinto é muitas vezes apertar a fiscalização, mas essa é quase sempre a jogada errada. Em vez disso, CISOs bem-sucedidos pausam e fazem três perguntas:
- Estamos expondo muitos problemas de uma vez?
- Os desenvolvedores recebem orientação clara para remediação?
- Estamos priorizando as vulnerabilidades que realmente importam?
A última pergunta leva a um dos princípios mais importantes em programas de segurança em larga escala:
O Princípio de Pareto se aplica aqui: na maioria dos ambientes, aproximadamente 20% das vulnerabilidades são responsáveis por 80% do risco organizacional real. Programas de segurança que se concentram nessas questões de alto impacto reduzem drasticamente o risco, minimizando o atrito com os desenvolvedores. Programas que tentam corrigir tudo simultaneamente colapsam sob seu próprio peso.
Incorporando o pensamento de segurança no SDLC
Um programa de segurança de desenvolvedores de longo prazo, em última análise, se move para o upstream. Em vez de reagir a relatórios de vulnerabilidade, as organizações começam a preveni-los durante o design e o desenvolvimento.
Uma das ferramentas mais eficazes para essa transformação é o threat modeling. Muitos desenvolvedores encontram a segurança apenas quando um scanner sinaliza um problema. Eles aprendem a regra, mas não o raciocínio. O threat modeling muda essa dinâmica.
Ajuda os desenvolvedores a entender:
- Por que as decisões de armazenamento de sessão importam
- Como os padrões de autenticação criam superfícies de ataque
- Por que os problemas do Top 10 OWASP aparecem repetidamente
Quando os engenheiros entendem o “porquê”, eles param de ver as correções de segurança como demandas externas e começam a projetar sistemas que evitam esses problemas por completo. Emparelhar desenvolvedores juniores com engenheiros experientes acelera ainda mais esse aprendizado. Desenvolvedores seniores naturalmente transmitem hábitos como disciplina de documentação, testes automatizados e configuração de infraestrutura segura. A segurança se torna menos sobre escanear código e mais sobre como os engenheiros pensam ao escrevê-lo.
A única regra que determina o sucesso em escala
Após observar dezenas de programas de segurança de desenvolvedores terem sucesso ou falharem, um princípio consistentemente determina o resultado: a segurança deve reduzir a carga cognitiva do desenvolvedor, não aumentá-la.
Se as ferramentas geram ruído excessivo, os engenheiros se desengajam. Se a orientação de remediação não é clara, os engenheiros adiam as correções. Se a fiscalização chega antes da confiança, os engenheiros ignoram os controles. Mas quando as ferramentas de segurança:
- expor descobertas acionáveis
- priorizar riscos significativos
- integrar em fluxos de trabalho existentes
os desenvolvedores respondem da maneira que sempre fazem e resolvem o problema.
E quando um número suficiente deles começa a resolvê-lo, algo notável acontece. A segurança se torna um hábito.
E em uma organização com 5.000 committers, os hábitos são o que, em última análise, determinam a postura de segurança de toda a empresa.
Essas lições influenciaram fortemente a filosofia de design por trás de plataformas modernas de segurança para desenvolvedores como Aikido. Um sistema construído para expor riscos significativos enquanto minimiza a carga cognitiva sobre os desenvolvedores.
{{walkthrough}}
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebPage",
"@id": "https://www.aikido.dev/blog/rolling-out-developer-security-5000-engineer-organization#webpage",
"url": "https://www.aikido.dev/blog/rolling-out-developer-security-5000-engineer-organization",
"name": "Rolling Out Developer Security in a 5,000+ Engineer Organization",
"description": "A practitioner's guide by enterprise CISO Mike Wilkes on why developer security rollouts fail at scale and how to fix them. Covers the structural constraints of large engineering organizations, a four-phase rollout model, pilot team selection, security ownership strategy, metrics that signal real adoption, and how to embed security thinking into the SDLC through threat modeling and training-of-trainers programs.",
"inLanguage": "en-US",
"isPartOf": {
"@type": "WebSite",
"@id": "https://www.aikido.dev#website",
"url": "https://www.aikido.dev",
"name": "Aikido Security",
"publisher": {
"@id": "https://www.aikido.dev#organization"
}
},
"breadcrumb": {
"@id": "https://www.aikido.dev/blog/rolling-out-developer-security-5000-engineer-organization#breadcrumb"
},
"mainEntity": {
"@id": "https://www.aikido.dev/blog/rolling-out-developer-security-5000-engineer-organization#article"
},
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": ["h1", "h2", ".article-intro"]
}
},
{
"@type": "BreadcrumbList",
"@id": "https://www.aikido.dev/blog/rolling-out-developer-security-5000-engineer-organization#breadcrumb",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://www.aikido.dev"
},
{
"@type": "ListItem",
"position": 2,
"name": "Blog",
"item": "https://www.aikido.dev/blog"
},
{
"@type": "ListItem",
"position": 3,
"name": "Rolling Out Developer Security in a 5,000+ Engineer Organization",
"item": "https://www.aikido.dev/blog/rolling-out-developer-security-5000-engineer-organization"
}
]
},
{
"@type": "TechArticle",
"@id": "https://www.aikido.dev/blog/rolling-out-developer-security-5000-engineer-organization#article",
"mainEntityOfPage": {
"@id": "https://www.aikido.dev/blog/rolling-out-developer-security-5000-engineer-organization#webpage"
},
"headline": "Rolling Out Developer Security in a 5,000+ Engineer Organization",
"alternativeHeadline": "Why Developer Security Rollouts Fail at Enterprise Scale and How to Fix Them",
"description": "Enterprise CISO Mike Wilkes argues that developer security rollouts fail not because of tooling gaps but because they are designed like software deployments instead of cultural changes. At organizations with 5,000 or more active committers, the limiting factor is alignment, not budget or talent. This guide covers the structural constraints unique to large engineering organizations — including SDLC fragmentation, technology heterogeneity, and the absence of central enforcement power — and presents a four-phase rollout model moving from visibility without enforcement, through developer feedback loops and guardrails, to executive accountability. It introduces a training-of-trainers approach to propagating security culture through peer credibility rather than mandates, explains how pilot team selection typically misleads security leaders, and outlines the metrics that distinguish genuine behavioral adoption from dashboard noise. The article closes with guidance on embedding threat modeling into the SDLC to shift security upstream from reactive scanning to proactive design.",
"url": "https://www.aikido.dev/blog/rolling-out-developer-security-5000-engineer-organization",
"datePublished": "2026-05-06T00:00:00+00:00",
"dateModified": "2026-05-06T00:00:00+00:00",
"inLanguage": "en-US",
"author": {
"@id": "https://www.aikido.dev/authors/nicholas-thomson#person"
},
"publisher": {
"@id": "https://www.aikido.dev#organization"
},
"image": {
"@type": "ImageObject",
"@id": "https://www.aikido.dev/blog/rolling-out-developer-security-5000-engineer-organization#image",
"url": "https://www.aikido.dev/images/blog/rolling-out-developer-security-5000-engineer-organization.png",
"width": 1200,
"height": 630
},
"articleSection": "Developer Security",
"timeRequired": "PT12M",
"proficiencyLevel": "Expert",
"keywords": [
"developer security rollout",
"enterprise AppSec",
"CISO strategy",
"security program at scale",
"SDLC security",
"security culture",
"DevSecOps",
"security ownership",
"training-of-trainers security",
"security champions program",
"vulnerability prioritization",
"Pareto principle security",
"threat modeling SDLC",
"developer cognitive load",
"security backlog management",
"SAST SCA deployment",
"secrets detection",
"container scanning enterprise",
"security pilot teams",
"premature enforcement anti-pattern"
],
"about": [
{
"@type": "Thing",
"name": "Developer Security Programs",
"description": "Structured organizational initiatives that embed security practices, tooling, and accountability into engineering workflows at scale.",
"sameAs": "https://www.wikidata.org/wiki/Q25263461"
},
{
"@type": "Thing",
"name": "Security Culture in Engineering Organizations",
"description": "The set of shared values, behaviors, and incentives that determine how software engineers perceive and respond to security requirements in their daily work."
},
{
"@type": "Thing",
"name": "SDLC Fragmentation",
"description": "The condition in large engineering organizations where multiple software development lifecycles operate simultaneously, ranging from daily deployments to quarterly release cycles, making uniform security tooling deployment difficult."
},
{
"@type": "Thing",
"name": "Security Ownership",
"description": "The organizational principle that specific teams or individuals are accountable for remediating identified vulnerabilities, as distinct from teams that merely have visibility into them."
},
{
"@type": "Thing",
"name": "Training-of-Trainers Security Model",
"description": "A peer-credibility approach to scaling security education in large organizations by training a small group of respected senior developers who then train a broader group of engineering champions."
},
{
"@type": "Thing",
"name": "Threat Modeling",
"description": "A structured approach to identifying security risks during the design phase of software development, helping engineers understand attack surfaces before code is written.",
"sameAs": "https://en.wikipedia.org/wiki/Threat_model"
},
{
"@type": "Thing",
"name": "Vulnerability Prioritization",
"description": "The practice of ranking security findings by organizational risk impact rather than raw severity score, often applying the Pareto principle to focus remediation effort on the 20% of vulnerabilities that represent 80% of real risk."
},
{
"@type": "Thing",
"name": "Premature Enforcement Anti-Pattern",
"description": "The common mistake of introducing blocking enforcement mechanisms before developers trust security tooling, leading to workarounds, scanner disablement, and damaged relationships between security and engineering teams."
},
{
"@type": "Thing",
"name": "Application Security",
"sameAs": "https://en.wikipedia.org/wiki/Application_security"
},
{
"@type": "Thing",
"name": "DevSecOps",
"sameAs": "https://en.wikipedia.org/wiki/DevOps#DevSecOps"
}
],
"mentions": [
{
"@type": "Thing",
"name": "SAST",
"description": "Static Application Security Testing — automated analysis of source code to identify security vulnerabilities before deployment."
},
{
"@type": "Thing",
"name": "SCA",
"description": "Software Composition Analysis — scanning of open source dependencies and third-party libraries for known vulnerabilities."
},
{
"@type": "Thing",
"name": "Secrets Detection",
"description": "Automated scanning of repositories and pipelines to identify exposed credentials, API keys, and other secrets before they reach production."
},
{
"@type": "Thing",
"name": "Container Scanning",
"description": "Security analysis of container images to identify vulnerabilities in base images, dependencies, and configurations."
},
{
"@type": "Thing",
"name": "OWASP Top 10",
"description": "The Open Worldwide Application Security Project's ranked list of the most critical web application security risks.",
"sameAs": "https://owasp.org/www-project-top-ten/"
},
{
"@type": "Thing",
"name": "CI/CD Pipeline Security",
"description": "Security controls and scanning integrated into continuous integration and continuous deployment pipelines to catch vulnerabilities before code reaches production."
},
{
"@type": "Thing",
"name": "Security Champions Program",
"description": "A distributed model where embedded developers within engineering teams serve as security advocates and points of contact, bridging the gap between central security teams and product engineering groups."
},
{
"@type": "Thing",
"name": "Sprint Backlog Prioritization",
"description": "The process by which engineering teams rank and schedule work within two-week development cycles, where security tasks frequently compete with and lose to feature delivery deadlines."
},
{
"@type": "Thing",
"name": "Pareto Principle in Security",
"description": "The application of the 80/20 rule to vulnerability management, where roughly 20% of identified vulnerabilities typically account for 80% of real organizational risk."
},
{
"@type": "SoftwareApplication",
"name": "Aikido Security",
"description": "A developer security platform designed to surface meaningful risk while minimizing cognitive burden on engineering teams, supporting SAST, SCA, secrets detection, container scanning, and cloud security.",
"url": "https://www.aikido.dev",
"applicationCategory": "SecurityApplication"
}
],
"hasPart": [
{
"@type": "HowTo",
"name": "Four-Phase Developer Security Rollout Model for Enterprise Organizations",
"description": "A proven phased framework for rolling out developer security programs in organizations with 5,000 or more engineers, designed to build trust before enforcement and prioritize cultural adoption over tool deployment.",
"step": [
{
"@type": "HowToStep",
"position": 1,
"name": "Phase 1: Visibility Without Enforcement",
"text": "Deploy security tools across repositories and infrastructure in observation-only mode. Do not block builds or deployments. Surface, categorize, and analyze findings to identify which vulnerabilities appear most frequently, which teams respond quickly, and which types of fixes create the most resistance. The goal at this stage is learning, not control."
},
{
"@type": "HowToStep",
"position": 2,
"name": "Phase 2: Developer Feedback Loops",
"text": "Present findings in ways engineers can act on directly. Aggressively remove false positives, improve remediation documentation, and share concrete fix examples. Introduce intrinsic motivation by framing security as a problem-solving challenge. Some organizations gamify remediation by letting teams compete on issues resolved per sprint. When engineers begin fixing issues voluntarily, the program is gaining genuine traction."
},
{
"@type": "HowToStep",
"position": 3,
"name": "Phase 3: Guardrails and Policy",
"text": "Only after developers trust the tooling should enforcement mechanisms be introduced. These should take the form of guardrails rather than hard gates — blocking critical vulnerabilities in new dependencies, preventing secrets from entering repositories, enforcing minimum patch levels for base images. The emphasis is on preventing new risk, not punishing historical debt. Always pair the enforcement rule with the reasoning behind it."
},
{
"@type": "HowToStep",
"position": 4,
"name": "Phase 4: Executive Accountability",
"text": "Surface security metrics inside engineering leadership dashboards, including time-to-remediation, recurring vulnerability categories, and security backlog trends. When security becomes part of engineering performance discussions rather than isolated security team reports, the cultural shift becomes durable."
}
]
},
{
"@type": "HowTo",
"name": "Training-of-Trainers Model for Security Culture Propagation",
"description": "A peer-credibility approach that scales security knowledge across thousands of engineers without requiring the central security team to train everyone directly.",
"step": [
{
"@type": "HowToStep",
"position": 1,
"name": "Identify master developers",
"text": "Identify 10 senior developers who are widely respected across the engineering organization — not necessarily formal managers or architects, but the people others consult before making architectural decisions."
},
{
"@type": "HowToStep",
"position": 2,
"name": "Train master developers deeply",
"text": "Train this group deeply in secure development practices, threat modeling, and the reasoning behind security requirements, not just the rules themselves."
},
{
"@type": "HowToStep",
"position": 3,
"name": "Expand to 100 engineering champions",
"text": "Have the master developers train 100 engineering champions drawn from teams across the organization, creating a distributed network of security advocates embedded in product engineering."
},
{
"@type": "HowToStep",
"position": 4,
"name": "Propagate to teams at scale",
"text": "Each champion influences their own team of roughly 50 developers. Within weeks, security practices propagate across thousands of engineers through peer credibility rather than central mandates."
}
]
}
]
},
{
"@type": "Person",
"@id": "https://www.aikido.dev/authors/nicholas-thomson#person",
"name": "Nicholas Thomson",
"url": "https://www.aikido.dev/authors/nicholas-thomson",
"jobTitle": "Senior SEO & Growth Lead",
"worksFor": {
"@id": "https://www.aikido.dev#organization"
},
"sameAs": [
"https://www.linkedin.com/",
"https://x.com/"
]
},
{
"@type": "Organization",
"@id": "https://www.aikido.dev#organization",
"name": "Aikido Security",
"description": "Aikido Security is a developer security platform that surfaces meaningful risk while minimizing cognitive burden on engineering teams, combining SAST, SCA, secrets detection, container scanning, and cloud security in a single developer-friendly interface.",
"url": "https://www.aikido.dev",
"logo": {
"@type": "ImageObject",
"url": "https://www.aikido.dev/logo.png"
},
"sameAs": [
"https://www.linkedin.com/company/aikido-security",
"https://twitter.com/aikido_security"
]
}
]
}
</script>
