Se as DevOps combinam o desenvolvimento com operações de TI, as DevSecOps introduzem uma relação triangular em que a segurança desempenha um papel significativo. É bom, mas não justifica tanto hype. As DevSecOps parecem um novo objetivo a perseguir: o ilustre sucessor das DevOps. Mas se levar a segurança a sério é o novo objetivo da moda, o que raio andam as equipas de DevOps a fazer hoje em dia?

1. Quebrar os silos

Em retrospetiva, parece uma ideia óbvia: deixar que os programadores que criam aplicações conheçam os especialistas de TI que mantêm a app em produção. E, ainda assim, as DevOps eram (e são) uma forma revolucionária de trabalhar. As companhias em geral, e o sector das TI em particular, gostam, tradicionalmente, de trabalhar em silos. Um departamento desenvolve, o outro implementa e gere. Simples no papel, mas é meio caminho para mal-entendidos e ineficiências na prática. Combinar os dois nas DevOps era uma ideia espetacularmente boa.

Então o que devemos pensar das DevSecOps? Na prática, a segurança das TI continua a estar num silo separado. As DevOps constroem, a segurança das TI assegura que não entram hackers na nova app através de uma porta escondida para aceder a informação de clientes de toda a empresa. Mas como? Todos sabemos que a segurança do perímetro já tem direito a uma sala de exposição própria no Museu das TI. Toda a infraestrutura de TI de uma empresa tem de estar permeada pela segurança.

2. Segurança integrada

Por outras palavras: se contróis uma aplicação com um portal de início de sessão, tens de te certificar que o portal não é um queijo suíço, certo? Os programadores querem muitas vezes um salto eficiente e rápido de uma lógica de negócio para uma aplicação funcional. Na prática, a segurança raramente passa de um pensamento posterior, não sendo decerto uma prioridade.

Esse é um problema das DevOps. Não podes envolver-te na integração e na entrega contínuas sem as verificações de segurança necessárias. Se estas não fizerem parte do fluxo de trabalho das DevOps, então elas perdem muita dinâmica. A ideia inicial era livrar-nos destes silos irritantes. Se a segurança continuar a ser um silo, então as DevOps não alcançaram o seu objetivo.

3. Rumo a um pleonasmo

Um automóvel tem airbags, travões e ABS. Dizemos que um automóvel com estas funções é apenas um automóvel, não o chamamos de ‘automóvel seguro’. O mesmo deve ser aplicado às DevOps. A segurança tem de ser parte do fluxo de trabalho das DevOps, pelo que o termo DevSecOps se torna um pleonasmo.

Isso é algo que podes aplicar na prática. Como programador é útil sentires o pulso às tendências de segurança, mas ter a mentalidade certa é ainda mais importante. A segurança tem de estar presente no pipeline CI/CD como prioridade. Constrói tendo a segurança sempre presente. Leva em conta a adaptabilidade e as mudanças nas necessidades de segurança, para que os teus elementos de segurança essenciais possam ser facilmente atualizados quando a necessidade surgir. Não testes apenas a funcionalidade e a estabilidade, testa também a segurança, dando-lhe a mesma importância. Depois, implementa uma aplicação que seja, ao mesmo tempo, segura e útil.

Não te esqueças que hoje há ferramentas que te podem ajudar a ficar de olho nas coisas. Depois da implementação do novo código, podes confirmar de forma automática se há ou não novas vulnerabilidades conhecidas na aplicação, de modo a poderes ajustá-las de imediato. Para os containers, a ferramenta de open source Clair é um excelente exemplo.

Por isso, não tenhas problemas em torcer o nariz às DevSecOps enquanto hype. Não é que estas sejam uma má ideia, mas porque um bom programador tem de estar, desde sempre, preocupado com a segurança num contexto de DevOps.