Por que os desenvolvedores assumirão o controle da segurança e dos testes em produção

Os desenvolvedores “comerão” a função de segurança de TI, previu Larry Maccherone, que trabalha como arquiteto de transformação Dev(Sec)Ops para a plataforma de automação de segurança Contrast Security e ganhou as manchetes como autor do Manifesto DevSecOps. É inevitável, argumentou ele. E como se isso não fosse suficientemente chocante, os testes em produção deveriam tornar-se a norma, acrescentou.

Pode parecer loucura, e o público do InfoBip, formado principalmente por novos programadores, parecia hesitante em abraçar a ideia. Mesmo assim, Maccherone expôs seu caso em um workshop do InfoBip Shift em Miami no mês passado.

Agile impulsiona o desenvolvimento para consumir outras funções

Será uma faceta de uma lista de funções que os desenvolvedores assumiram. O desenvolvimento já “devorou” a TI/Ops, graças aos ambientes nativos da nuvem, porque os desenvolvedores não precisam mais de TI/Ops para criar e manter um servidor, disse ele; eles podem ficar online e fazer isso sozinhos. Durante muito tempo, esse “Shadow IT” foi combatido por TI/Ops; agora é assim que as coisas funcionam, afirmou ele.

“Se você pensar nos primeiros dias da nuvem nativa e nos movimentos DevOps, o departamento de TI foi o primeiro departamento que você procurou quando precisou de um novo servidor para sustentar seu novo aplicativo. Você tinha que preencher um ticket e esperar seis meses até a máquina chegar, eles configuraram e entregaram para você”, disse ele. “Agora você pode entrar na AWS e, em três cliques, ter um novo servidor.”

Larry Maccherone defendeu o desenvolvimento da propriedade de segurança na conferência InfoBip da primavera.

O mesmo fenômeno vai acontecer com a segurança, graças à automação e à velocidade com que o desenvolvimento acontece agora, previu. E isso acontecerá quer os desenvolvedores queiram responsabilidade pela segurança ou não.

“O longo arco da história da engenharia de software é que a própria equipe de desenvolvimento assume cada vez mais responsabilidade por todas essas coisas que costumavam ser feitas pela segurança, por especialistas”, disse ele. “Você pensaria que você, como equipe de desenvolvimento, deveria assumir a responsabilidade por tudo o que está acontecendo em torno do aplicativo e que pode afetar sua capacidade de agregar valor aos seus clientes. Quando alguém controla arbitrariamente uma parte dele como um silo, então não é muito eficaz.”

A tendência começou com equipes ágeis assumindo a qualidade dos produtos que produzem. Antes disso, a garantia de qualidade era responsável por isso, mas em 10 anos os departamentos de controle de qualidade começaram a desaparecer.

“Há muito poucos departamentos de controle de qualidade dedicados na maioria das organizações atualmente”, disse ele. “Basicamente, as equipes multifuncionais no Agile, Scrum, fizeram com que o desenvolvimento assumisse a maior parte da responsabilidade… pela qualidade dos produtos que estão produzindo.”

Embora não seja absoluto – ainda existem verdadeiros departamentos de DevOps – hoje, quando as pessoas em muitas organizações dizem TI, elas se referem ao help desk, disse ele.

Por que o desenvolvimento deve possuir a segurança

A segurança como uma unidade autônoma é um pouco chata. Essencialmente, eles funcionam como guardiões que retardam os desenvolvedores, explicou ele. Eles definem políticas e talvez tenham páginas de listas de verificação para os desenvolvedores seguirem, mas a função não tem força. Não há consequências quando o desenvolvimento ignora a segurança, mas muitas vezes há consequências para o diretor de segurança da informação (CISO) quando ele tenta jogar duro.

“A razão pela qual não há consequências é porque a dinâmica de poder é que vocês, como desenvolvedores… (têm) mais poder do que o pessoal de segurança, de modo que o CISO foi espancado em reuniões com seu chefe e o vice-presidente de engenharia , onde disseram que a segurança simplesmente jogou essa porcaria em nós e não poderíamos enviar a tempo”, disse ele.

O desenvolvimento é enviado para a produção várias vezes ao dia, e isso criou um ritmo que impressiona a equipe de segurança, acrescentou. Eles não conseguem acompanhar.

Não só isso, mas é um trabalho desmoralizante, porque basicamente chamamos a aplicação de alguém de falha, e isso levou a uma grande rotatividade na segurança, observou ele.

“Ninguém quer fazer isso. Ninguém quer ser alvo disso”, disse ele. “Mas aqui está a parte realmente assustadora. E as pessoas que ficam? São aqueles que gostam de chamar o bebê de alguém de feio o dia todo. Eles não serão muito bons em construir relacionamentos e mover pessoas, eles apenas ficarão irritados e bravos e tentarão impor as coisas e o desenvolvedor continuará ignorando-os.”

Muitas vezes, quando os trabalhadores da segurança tentam fazer cumprir as políticas, encontram-se no lado perdedor, sem quaisquer consequências, porque o custo de fazer cumprir a segurança é uma compensação em termos de velocidade.

Um caminho para uma mudança de segurança à esquerda

Mudar para a esquerda significa transferir as responsabilidades de segurança para a equipe de desenvolvimento. Isso também é o que DevSecOps quis dizer, mas o significado mudou desde que ele escreveu seu livro, disse Maccherone. Ele agora prefere a frase segurança de aplicativos centrada no desenvolvedor.

“É por isso que me afastei da expressão DevSecOps. Muitas pessoas pensam que o DevSecOps está colocando o batom do DevOps na segurança tradicional”, disse ele. “Essa não é minha definição.”

A engenharia de plataforma é fundamental para essa mudança porque permite que os engenheiros de software assumam a responsabilidade e façam o trabalho sozinhos. As equipes de DevOps e de segurança precisam mudar seu pensamento para apoiar os desenvolvedores, em vez de tentar controlá-los.

“O que eles precisam é passar a ser ferreiros para que a equipe de desenvolvimento assuma essa função”, disse ele.

Ele prevê que a engenharia de plataforma desempenhará um papel nesta próxima evolução da segurança de aplicativos. Basicamente, os engenheiros da plataforma fornecerão a “capacidade de autoatendimento fácil que as equipes de desenvolvimento podem consumir sem interação humana”, disse ele. É uma abordagem que ele usou quando trabalhou na Comcast. Ele também teve treinadores que apoiaram os desenvolvedores no seguimento das melhores práticas de segurança.

A responsabilidade também passa para a equipe de desenvolvimento, acrescentou. Após a palestra, perguntei a ele como isso poderia acontecer, e ele sugeriu um sistema onde os desenvolvedores são realmente avaliados em sua postura de segurança e eventualmente penalizados se não tomarem medidas para proteger seus aplicativos.

“Se os desenvolvedores escrevem as vulnerabilidades no software, mas o pessoal de segurança é quem é chamado e talvez até vá para a prisão, potencialmente, se for hackeado… não é uma coisa muito eficaz”, disse ele ao público. . “Você precisa que o feedback chegue às pessoas responsáveis ​​por causar a dor.”

Teste em produção

Uma maneira de fazer com que os desenvolvedores levem a segurança mais a sério é mover os testes e corrigir vulnerabilidades para corresponder à solicitação pull, acrescentou. Isso significará testes em produção, que, segundo ele, são mais eficazes e eficientes de qualquer maneira.

A melhor maneira de fazer com que os desenvolvedores levem a segurança a sério é mover os testes e corrigir vulnerabilidades para a solicitação pull, argumentou Maccherone.

“Basicamente, estou apenas argumentando que a solicitação pull é o lugar ideal para colocá-la”, disse ele ao público de desenvolvedores. “Por que? A solicitação pull é muito imediata e muito importante para o desenvolvedor que a envia. Você está balançando a cabeça! Você é apaixonado pelo código que escreveu naquela manhã.”

Mesmo assim, ele estimou que 90% dos clientes com os quais trabalha levam esses testes de segurança a um ponto que realmente não faz sentido quando se considera o fluxo de trabalho do desenvolvedor. A maioria do pessoal de segurança nem sabe o que é um pull request, acrescentou.

Ferramentas de testes automatizados serão fundamentais para tornar isso possível, acrescentou Maccherone.

”Se uma ferramenta automatizada lhe dá uma mensagem que diz: ‘Isso tem esse problema de vulnerabilidade, isso tem esse problema de linting’, então você vai consertar isso imediatamente porque você definitivamente não quer o cara em sua equipe ou a garota na sua equipe responsável por revisar isso diga: ‘Ei, você não passou no teste automatizado, não vou aprovar seu código para ser mesclado’”, disse Maccherone. “Portanto, os desenvolvedores estão altamente motivados para fazer isso neste momento.”

A postagem Por que os desenvolvedores assumirão o controle da segurança e dos testes em produção apareceu pela primeira vez em The New Stack.