Mudar a segurança no DevOps significa mudar mentalidades

Há muito tempo, quando eu era um jovem e tolo administrador de sistemas UNIX (sou apenas uma dessas coisas agora), cometi um erro de segurança muito sério em um dos servidores que executavam nossos sistemas de backup. Não vou entrar em detalhes, mas tinha a ver com o comando sudo, um editor de texto e ignorância.

Felizmente, um dos administradores de sistemas mais experientes (e, francamente, mais inteligentes) me apoiou. Eles notaram meu novo procedimento, investigaram-no... e então educadamente me levaram de lado para explicar o erro dos meus métodos. Eles então passaram um tempo me ajudando a encontrar uma solução que ainda oferecesse às pessoas o recurso de autoatendimento de que precisavam, mas com menos chances de catástrofe. Na minha memória autoeditada e pouco confiável, fiquei grato pelas melhorias, tanto para mim quanto para minha configuração.

Esse comportamento de compartilhamento, colaboração e solução de problemas sem culpa permaneceu comigo ao longo dos anos e espero ter conseguido ajudar alguém com seus deslizes de segurança.  

Nesse sentido, não foi nenhuma surpresa ao ler o Puppet State of DevOps Report descobrir que, quando você integra a segurança mais cedo no ciclo de vida de entrega do software, o resultado é — espere só — melhor segurança.

Olhando para o relatório, fica claro que as vantagens de transferir a segurança para o ciclo de vida do software dependem da transferência desses princípios de comportamento do DevOps para as equipes de segurança tanto quanto, se não mais, do que mover ferramentas de segurança para os pipelines.

Enquanto as práticas operacionais de segurança mais tradicionais se concentram em testes e controles (a maioria das equipes de aplicativos já deve ter recebido um relatório de segurança gerado por uma ferramenta mostrando vários problemas que precisam ser resolvidos), uma abordagem baseada nos princípios do DevOps incentiva a colaboração antecipada, o compartilhamento e a responsabilidade conjunta.

Olhando para a seção “Melhorando a postura de segurança” do relatório (começando na página 31), é importante avaliar o quanto depende da injeção sem atrito do pensamento de segurança no design e na construção de software e infraestrutura, em oposição a apenas colocar os controles e a tecnologia certos em prática.

Se os benefícios dependerem do compartilhamento e da integração das habilidades e da mentalidade dos profissionais de segurança no cerne do pipeline de entrega de software, algumas das mudanças mais significativas serão comportamentais.

A inclusão de uma equipe de segurança no início do ciclo de vida do desenvolvimento de software certamente exigirá que ela se adapte, mas essas mudanças terão que ocorrer em ambas as direções. Embora os profissionais de segurança tenham que adotar novas formas de trabalhar — e provavelmente aprender a falar mais "dev" do que falam atualmente — a equipe de desenvolvimento pode muito bem ter que adotar o Tao do cabo Andon .

Se você ainda não investigou o cabo Andon e seu lugar no processo de fabricação de controle de qualidade pioneiro da Toyota, então vale a pena investir seu tempo. Há artigos, trabalhos acadêmicos, livros inteiros e até cursos de ensino superior abordando o assunto. Mas antes de abandonar sua carreira em tecnologia para fazer o MBA que você sempre prometeu a si mesmo, termine este artigo, porque acredito que o fato mais significativo sobre o cabo Andon é o mais simples e o mais difícil de alcançar.

Quando um trabalhador em uma linha de produção puxa seu cabo Andon para interromper a produção devido a um defeito, a primeira coisa que seus colegas de trabalho e a equipe de gerência fazem é correr até ele e agradecer. E eles têm que falar sério. Puxar o cordão Andon é visto como algo positivo, pois é um passo em direção à melhoria da qualidade. Gerentes e colegas de trabalho ficam gratos pelo fato de a linha de produção estar parada devido a um problema, porque essa é uma oportunidade de melhorar.

Sua equipe de desenvolvimento consegue acolher com gratidão a equipe de segurança que encontra defeitos e puxa o cabo (virtual)? Uma equipe de DevOps pode aprender a valorizar compilações ou implantações que falham nos testes de segurança tanto quanto aquelas que passam?

Os futuros empresários podem aprender que, para criar um ótimo software, devemos procurar falhas de teste mais frequentes à medida que criamos testes cada vez melhores que identificam problemas antes que eles se tornem aparentes em uma implantação?

Isso pode ser uma adaptação mental difícil.

Embora eu seja grato pelas inevitáveis correções de edição que serão aplicadas a este artigo quando você o ler, nem sempre é fácil ver o que você criou ser dissecado por outros. Seu cérebro racional sabe que entrega um produto melhor, mas seu chimpanzé interior só quer mostrar os braços.

Portanto, embora possa ser uma mentalidade difícil de adotar, é essencial para o sucesso na integração da segurança no início do ciclo de vida do software, e muito melhor do que as revisões posteriores e as correções apressadas existentes.

Mudar atitudes é uma área de estudo totalmente diferente, mas é algo em que os líderes e profissionais de TI precisam se tornar proficientes, especialmente nesta época de revolução nas formas de trabalhar. Muitas vezes é (muito) mais difícil do que simplesmente adotar uma nova tecnologia. Se você pretende "mudar para a esquerda" com sucesso na segurança — e os dados deste relatório dizem que você deve fazê-lo — então dedique tanto tempo aos elementos humanos quanto aos técnicos.