Integrando segurança ao processo de desenvolvimento

Com a crescente participação do software em nossas vidas, precisamos ter um cuidado ainda maior com a segurança no desenvolvimento e quanto mais cedo adicionarmos essa preocupação em nosso projeto, mais cedo teremos resultados melhores e custos menores.

A segurança precisa ser um tema inicial do projeto, e não apenas uma etapa validação no fim do ciclo. Quando nosso projeto nasce com uma visão de segurança, o seu ciclo de vida lidará melhor com isso e permitira um gerenciamento menos conflituoso.

DevSecOps
Normalmente utilizamos esse termo para enaltecer o papel da segurança no conceito de DevOps, mas pessoalmente não gosto muito dessa abordagem uma vez que em DevOps já deveríamos considerar a segurança. De qualquer forma, o que queremos dizer com DevOps?

De uma forma simples, essa ideia busca a união entre as duas grandes áreas de tecnologia, DEV e OPS.

DEV
Ou desenvolvimento, é a área responsável pela criação dos produtos e suas atualizações. Gosto de pensar como um lado que sempre vai buscar a inovação e o aprimoramento, o que representa também um maior risco para os sistema já existentes e estáveis.

OPS
É o lado menos glamoroso (estamos em um blog chamado DEV afinal), que une as equipes responsáveis pela operação, ou seja, por manter os sistema operando e funcionando conforme o esperado. Podemos pensar nesse lado como sendo o que deseja a estabilidade e a previsibilidade.

DEV vs OPS
Um lado quer uma liberdade maior, enquanto o outro preza pela estabilidade, naturalmente isso geraria um conflito entre as áreas. Mas não podemos nos esquecer que esses lados não são concorrentes, na verdade eles tem que trabalhar junto para o objetivo final da tecnologia que é resolver problemas.
Quando temos um projeto de software, não temos uma competição sobre quem melhor utiliza uma linguagem ou sobre quem mantem melhor servidores, temos um problema a ser resolvido por meio da tecnologia.

É importante ter isso em mente, pois as equipes por mais que tenham orientações e vontades conflitantes, devem trabalhar juntos nesse objetivo. DevOps é um conceito que busca o consenso, é preciso que a equipe de desenvolvimento entenda a importância da estabilidade e que a equipe de operações entenda o da evolução do projeto, já que sem um dos lados, a empresa não poderá concluir seus projetos.

Uma empresa que fica parada no tempo sem inovar falha, assim como uma que não consegue se manter operando, por mais revolucionaria que seja.

As 3 maneiras
Citando os clássicos Manual de DevOps e O Projeto Fênix, que recomendo fortemente a leitura, precisamos entender o fluxo de trabalho, trabalhar os feedbacks e repetir.
De uma forma muito simples, essas são as famosas três maneiras:

1. Controlar nosso fluxo de trabalho
2. Feedbacks contínuos
3. Ciclo continuo de aprendizagem e experimentação

Mas como isso se encaixa no nosso dilema anterior?
Se as equipes trabalham juntas desde o inicio e convivem, as chances dos problemas acontecerem diminuem, pois com esse contato desde o começo, elas podem juntas trabalhar as questões relacionadas ao projeto. Fora isso, é preciso que os dois lados se ajudem de forma a não fugirem de seus princípios, mas sem ferirem fatalmente os do outro lado.

A equipe de desenvolvimento não deve matar a operação, e nem o contrario.

Onde entra a segurança?
A equipe deve desde o começo agregar valores de segurança em seu projeto sem ver isso como um impeditivo, uma etapa menor ou algo que apenas vai barrar o projeto. Uma falha de segurança pode acabar com o projeto inteiro caso ocorra num estagio mais avançado, seja fazendo-o regressar a uma etapa muito inicial do desenvolvimento ou acabando com a credibilidade junto aos clientes.

Existem diversas formas de se agregar segurança no projeto, mas o caminho mais fácil é no planejamento utilizar padrões de segurança recomendados junto com ferramentas que nos permitem validar erros de forma pratica e rápida.

Hoje felizmente a tecnologia evoluiu muito, inclusive a relacionada ao desenvolvimento de tecnologia. Temos soluções para verificar nossos códigos assim que são escritos, para encontrar falhas de segurança no projeto e até para simular o comportamento de invasores.

Temos que ter em mente, que quanto mais rápido encontramos os erros, mais cedo podemos corrigi-los. Não tem problema maior do que não encontrar os problemas em nossos projetos, e também não é preciso ter medo dos problemas e sim aprender a lidar com eles.

Uma falha diagnosticada no começo, nos permite pensar em como resolve-la, seja com uma alteração no código, na abordagem ou na tecnologia utilizada. Descobrir a falha apenas no final do ciclo de desenvolvimento ou quando este já está em produção é muito pior pois muda a logica para correr atrás do prejuízo.

Unindo as maneiras com a segurança
Precisamos primeiro entender qual o fluxo do nosso trabalho, o que fazemos, como fazemos e o porque fazemos. Sem isso, não temos como planejar e otimizar.

Depois de entendermos nosso fluxo, precisamos pensar sobre ele, tentar melhora-lo, sempre se mantendo atento as respostas dessa mudança, é isso que consideramos como um feedback.

A ultima maneira é um ciclo continuo das duas primeiras, quando criamos uma cultura que permita a analise e aprimoramento constante de nossos fluxos, sempre atentos as respostas, pois é com base nelas que novas mudanças serão feitas.

A segurança tem que fazer parte desse processo desde o começo, temos que pensar se nossos fluxos lidam com segurança, se pensam e aplicam isso. Ao adiciona-la logo no começo em nossos fluxos, tornamos pensar em segurança algo natural e totalmente integrado ao processo.

Não é preciso uma equipe totalmente dedicada, uma etapa ou algo assim. O ideal é que todos pensem nisso e que se torne algo natural ao processo.