Todas as equipas concordam que o desenvolvimento seguro é importante. Mas quando se trata de propriedade? De repente, toda a gente está a olhar para outra pessoa. Os programadores pensam que é o trabalho da segurança. As equipas de segurança esperam que os programadores escrevam código mais seguro. O DevOps só quer manter o pipeline vivo. E os gerentes? Eles querem segurança sem atrasar o envio.

A verdade é que o desenvolvimento seguro de software não é tarefa de uma só pessoa - é tarefa de todos. Isso significa definir claramente as funções, as responsabilidades e, o mais importante: as expectativas. Se você não acertar essa parte, todo o esforço do SSDLC se tornará um jogo de culpas em câmera lenta. Vamos analisar quem está na arena, o que os mantém acordados à noite e o que eles realmente estão procurando às 2 da manhã.

Imagem de marcador de posição: Descrição da imagem: Diagrama de funções da equipa de desenvolvimento multifuncional com setas que mapeiam as responsabilidades de codificação segura, testes, ferramentas e entrega.

O alinhamento: Quem é quem na arena do desenvolvimento seguro

Programadores: Nas trincheiras, a escavar código, a evitar CVEs

Os programadores são os mais próximos do código e, muitas vezes, os primeiros a serem responsabilizados quando algo falha. Espera-se que escrevam código seguro, mesmo que nunca tenham sido ensinados a fazê-lo. Enfrentam a fadiga do alerta devido a ferramentas ruidosas e conselhos contraditórios. O que eles precisam é de orientação de segurança integrada no seu fluxo de trabalho, e não de orientação a posteriori.

Engenheiros DevOps: Mestres do pipeline, ferramentas de malabarismo e configurações Cloud

O DevOps mantém o pipeline a funcionar e as implementações a fluir. Gerem secrets, infra-as-code, configurações container e integração CI/CD. Muitas vezes, espera-se que eles "simplesmente façam a segurança funcionar" em toda a pilha - sem interromper a construção. O que eles precisam: segurança que se encaixe na automação existente, não mais etapas manuais.

Engenheiros de segurança (AppSec/Segurança de produtos): Os guias, os guardiões e, por vezes, os estrangulamentos

As equipas de segurança escrevem políticas, escolhem ferramentas e tentam escalar a sua influência em dezenas (ou centenas) de programadores. Elas precisam de ferramentas que reduzam o ruído, destaquem o que realmente importa e ajudem os desenvolvedores a corrigir os problemas sem precisar ficar trocando bilhetes.

Gestores técnicos: pastoreando gatos, equilibrando recursos com sanidade

Os gestores andam na corda bamba entre a velocidade e o risco. São avaliados pelas funcionalidades fornecidas, mas também pelo tempo de inatividade, incidentes e conformidade. Não são especialistas em segurança, mas espera-se que tomem decisões que mantenham a empresa longe de problemas. Precisam de visibilidade, métricas e adesão de todas as equipas.

O que os mantém acordados à noite

Para desenvolvedores: "Segurança vs. velocidade", inferno das ferramentas (tantos alertas), síndrome do "não é meu trabalho"

Os desenvolvedores temem ferramentas que bloqueiam implantações e os inundam com problemas de baixa prioridade. Eles querem feedback rápido e acionável - de preferência em seu IDE ou PRs. Eles odeiam qualquer coisa que pareça culpa sem suporte.

Para DevOps: estrangulamentos de condutas, pesadelos de configuração, manter Secrets em segredo

Os DevOps querem menos passos manuais e menos surpresas. Eles se preocupam com o envio acidental de dados confidenciais ou com a abertura de um bucket S3 para o mundo. Eles precisam de políticas e ferramentas claras que não atrapalhem a automação.

Para o pessoal da segurança: Demasiado ruído, poucos recursos, sempre a tentar recuperar o atraso

As equipas de segurança ficam sobrecarregadas com alertas, falsos positivos e proliferação de ferramentas. Estão cansadas de serem reactivas. O que elas desejam é contexto, priorização e maneiras de se antecipar aos riscos - sem tomar conta de cada implantação.

Para gestores: Justificar os custos, gerir o risco, encontrar pessoas que percebam do assunto

Os gestores preocupam-se com o ROI. Será que esta ferramenta de segurança vale a pena? A equipa está sequer a utilizá-la? Também estão presos à tentativa de contratar engenheiros "unicórnio" que entendam tanto de código como de segurança. Querem ganhos práticos e não mais um painel de controlo para gerir.

O que estão realmente a pesquisar no Google (e o que este hub vai responder)

Consultas de desenvolvimento

• "codificação segura [minha língua]"
• "como parar a injeção de SQL rapidamente"
• "OWASP Top 10 explicado para humanos"

Os programadores querem respostas claras e práticas. Não estão à procura de PDFs de 80 páginas - querem soluções que possam ser copiadas e conselhos de codificação segura específicos para cada linguagem.

Consultas DevOps

• "Automatize a segurança em CI/CD sem quebrar tudo" 
• "Ferramentas de verificação de segurança do Terraform" 
• "Práticas recomendadas de segurança do Docker que não são de 2015"

O DevOps está à procura de formas de ligar a segurança às ferramentas que já utilizam - sem interromper as implementações ou atrasar as compilações.

Consultas de segurança:

• "Guia de implementação do SSDLC para agile"
• "modelação de ameaças que os programadores não odeiam"
• "Comparação de ferramentas SAST"

Os engenheiros de segurança querem escalar. Estão à procura de ferramentas e manuais que se integrem no Agile e que ajudem realmente a mudar para a esquerda - sem serem constantemente vigiados.

Consultas do gestor: 

• "custo da violação de dados vs. investimento em segurança"
• "ROI da formação em segurança para programadores"
• "como construir uma cultura de segurança que não envolva quedas de confiança"

Os gestores procuram números concretos, investimentos justificáveis e formas leves de impulsionar o desenvolvimento seguro - sem prejudicar a velocidade ou a moral da equipa.

Toda a gente quer software seguro. Ninguém quer mais trabalho. A chave é compreender os pontos problemáticos de cada função e fornecer-lhes ferramentas e processos que funcionem com o seu fluxo - e não contra ele. 

Está na altura de desvendar o que realmente motiva as equipas a adoptarem práticas seguras - e o que normalmente as impede de o fazer.