Ciclo de vida do desenvolvimento de software e DevSecOps

O Ciclo de vida do desenvolvimento de software (Software Development Lifecycle – SDLC) é um processo sistemático de produção de software que garante a qualidade e corretude do que foi construído. 

 O SDLC visa produzir softwares de alta qualidade que atendam necessidades do cliente. Esse ciclo de vida é constituído por diversas fases, e cada fase tem seus próprios processos e gera seus próprios artefatos. 

Existem diferentes abordagens e visões sobre quais as fases do SDLC, porém o núcleo de todas essas abordagens é geralmente composto pelos seguintes estágios: 

• Análise de Requisitos: Entender quais são os requisitos do cliente para o sistema, o que o sistema precisa fazer.
• Modelagem: Definir qual será a solução técnica com base nos requisitos e como será feito .
• Desenvolvimento: Construir o sistema com base na solução técnica definida 
• Homologação: Validar se o que foi construído está cumprindo a necessidade do cliente 
• Disponibilização do software para o usuário: Como o próprio nome sugere, disponibilizar a solução construída para que o cliente possa usá-la 

Metodologias de desenvolvimento

Com o passar dos anos, diferentes metodologias de desenvolvimento surgiram, entre as primeiras amplamente aceitas está o Modelo Cascata. Esse modelo tem a particularidade de que uma fase só começa no momento em que a fase imediatamente anterior a essa termina, o que traz alguns problemas, entre os quais: 

1. O Modelo Cascata tem iterações (execução de todas as fases do ciclo de desenvolvimento) de longa duração, o cliente só terá contato com o sistema quando o projeto estiver próximo ao final; 
2. Como reflexo do problema citado anteriormente, o cliente só irá detectar divergências entre o que ele tinha como requisito, e o que foi construído, quando o projeto já estiver quase terminado. 

 

Esses problemas, por si só já podem arruinar o projeto, o usuário do sistema construído irá demorar para receber a solução em mãos, podendo ficar insatisfeito ao recebê-la, em uma situação extrema, a solução construída pode não atender às necessidades do cliente, resultando em um fracasso total. 

Modelos de desenvolvimento que vieram após o Cascata, como o Modelo Incremental e o Modelo Espiral, surgiram com o objetivo de sanar essa deficiência, com eles começou-se a ter um foco maior no que o cliente deseja para o sistema, com ciclos de desenvolvimento mais curtos e entregas menores. 

 Entre as principais vantagens que esses modelos trouxeram estão: 

1. Fazer entregas menores é menos arriscado do que fazer entregas maiores, pois caso existam divergências entre o que o cliente deseja e o que foi construído, essas são detectadas mais cedo, gerando uma maior responsividade no processo de desenvolvimento;
2. Com a realização de um número maior de iterações em menos tempo, se um grande erro é cometido, apenas a última iteração é descartada, resultando em uma menor perda de tempo. 

Os benefícios de se ter iterações mais rápidas e flexíveis foram logo notados e outras melhorias começaram a ser aplicadas no processo de desenvolvimento, como a realização dos processos de análise, desenvolvimento e homologação “em paralelo”, o que começou a ser a base do desenvolvimento ágil de software. 

O Manifesto Ágil

No ano de 2001 alguns membros da comunidade de desenvolvimento de software se reuniram para discutir métodos leves que, à época, era a denominação dada a métodos de desenvolvimento de software que começavam a surgir.

Essa reunião teve como resultado um manifesto, o qual foi assinado pelos 17 participantes da reunião e que posteriormente foi reconhecido como o Manifesto Ágil. 

O Manifesto Ágil é uma declaração de valores e princípios que os participantes da reunião entendiam como essenciais para o desenvolvimento de software. Entre esses princípios e valores está o foco cada vez maior em satisfazer o cliente através da entrega rápida e contínua de software, adaptação a mudanças e também maior ênfase na comunicação entre os stakeholders do projeto. 

Entrega Contínua 

O primeiro princípio do Manifesto Ágil é um dos pontos mais presentes no dia a dia das empresas de desenvolvimento de software, e norteia todo o modelo de entrega de software que conhecemos: 

A entrega contínua de software pode ser definida como uma abordagem de engenharia de software que se destina a criar, testar e liberar softwares mais rapidamente e com maior frequência.

“Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.” 

Os especialistas em criar e testar fazem parte da equipe de desenvolvimento, e os especialistas em liberar software normalmente fazem parte da equipe de operações.

A equipe de desenvolvimento tem como foco aumentar o valor do negócio, criando novas funcionalidades deixando da maneira que o cliente deseja. 

 A equipe de operações, que geralmente é responsável pela manutenção dos servidores, tem foco em manter os ambientes estáveis e intactos, para que o cliente possa acessar o sistema quando desejar. 

Com focos diferentes, a segmentação entre as equipes se tornou algo natural, pois cada equipe tinha os seus próprios objetivos. Mesmo com o objetivo final sendo satisfazer o cliente através da entrega contínua de software de valor, compartilhado, os objetivos-meio de cada equipe frequentemente tinham suas diferenças, algumas vezes eram até concorrentes. 

Através da cultura DevOps, e dos pilares CALMS, se tornou possível alcançar diversos benefícios, entre os quais: 

• Maior integração e empatia entre as áreas: Existindo uma maior integração, as barreiras entre as equipes de desenvolvimento e operações são quebradas, possibilitando uma maior comunicação e sinergia entre os times; 
• Simplificação, automação e racionalização de processos: Com o objetivo de transformar o desenvolvimento de software em uma tarefa menos burocrática, busca-se simplificar e automatizar quantos processos for possível, diminuindo a chance de erros acontecerem, e também aumentando a velocidade da entrega do software. 

Shifting left 

Porém, para que o DevOps tenha sucesso, alguns elementos chave precisam existir, e o principal deles é o conceito de shift left.

O shift left nada mais é que realizar testes, só que testes cada vez mais cedo no ciclo de vida de um produto. 

 Mas por que o shift left é tão importante assim? 

 Um artigo do Slashdot, posteriormente citado aqui, trouxe a informação que um erro encontrado nos últimos estágios do desenvolvimento pode ser até 100x mais caro que um erro encontrado em estágios iniciais. 

Um erro, além de ser sinal que o software não foi construído da melhor maneira, é um gasto a mais para o projeto. Um projeto que custe muito mais que a estimativa inicial é um problema e pode gerar conflitos com os stakeholders. 

 Se os erros são detectados, a capacidade de solucioná-los antes de chegarem ao cliente é habilitada, o que ajuda a cumprir o propósito inicial, produzir software de alta qualidade, e que atenda as necessidades do cliente, ainda reduzindo custos de desenvolvimento e manutenção. 

 Porém, testes que cubram a aplicação inteira costumam ser trabalhosos, então como realizar o shift left sem perder desempenho e continuando a entregar software de maneira rápida?

Testes automatizados. 

Testes automatizados são um componente chave para o shift left ser possível, pois eles reduzem consideravelmente o tempo e esforço gasto para validar que a aplicação está se comportando da maneira que deveria no ambiente, e é aqui que o termo integração contínua começa a ser definido. 

CI/CD 

A integração contínua (Continuous Integration – CI) é uma prática do DevOps que os desenvolvedores juntam suas alterações de código em um repositório central e, após essa junção, testes automatizados são executados.

É importante notar que, o ideal é que não só testes no código sejam executados, mas também testes na aplicação em funcionamento em um ambiente semelhante ao de produção, ou até mesmo no ambiente de produção, para que o sistema seja validado em condições que se assemelhem às condições em que o cliente fará uso da solução, o que abrange também o conceito de entrega contínua (Continuous Delivery – CD). 

Por ser um componente importante, soluções foram construídas para auxiliar na realização da integração entrega contínua, como o estabelecimento de pipelines de integração contínua e de entrega contínua (Pipelines CI/CD), além de ferramentas que gerenciam esses pipelines, como o Jenkins , que tornaram a realização do shift left mais fácil. 

Dev(Sec)Ops 

Mas e o Sec, como se relaciona com o Dev e o Ops?

De maneira semelhante às equipes de desenvolvimento e de operações, a equipe de segurança também possuía sua parte na entrega do software, que normalmente ficava relegada aos estágios finais do desenvolvimento.

Com a popularização da integração e da entrega contínua, percebeu-se que a área de segurança também deveria evoluir, e fazer parte do movimento de shift left.

O modelo tradicional de aplicar segurança da informação ao desenvolvimento era principalmente através da realização de pentests.

Com o aumento da velocidade do desenvolvimento e da quantidade de entregas, os pentests e a frequência com que estes eram realizados, tornaram-se insuficientes para garantir que o sistema e os ambientes estão de acordo com o padrão de segurança desejado. 

Quando se fala em padrão de segurança, é importante que exista tanto para o código quanto para a infraestrutura. O DevOps introduziu ao modelo de desenvolvimento ágil ferramentas e tecnologias que se tornaram essenciais, como os containers.

O uso de containers gerou um maior dinamismo e escalabilidade para a infraestrutura, mas caso se tenha uma utilização ou configuração de maneira indevida, essa tecnologia pode se tornar uma faca de dois gumes. A maneira de realizar o shift left na segurança é, pasmem, automatizando os testes. 

A automatização de testes de segurança pode ser alcançada através da utilização de ferramentas que validem dependências de código (Checkmarx), a segurança da infraestrutura (Nessus e OpenVas ), de ferramentas de análise estática de código (SonarQube acompanhado de plugins de segurança), ferramentas de análise dinâmica de código (OWASP ZAP ) e também através da realização de testes unitários que, não só validem que a aplicação está funcionando mas também que princípios básicos como autenticação e autorização estejam garantidos. 

Conclusão 

Com o passar dos anos processos de desenvolvimento de software sofreram grandes transformações, mas o objetivo final sempre foi o mesmo: entregar softwares de qualidade da maneira mais rápida possível.

Muito do que temos hoje como maneira ideal de entrega de software existe devido ao Manifesto Ágil, que foi um marco na história do desenvolvimento e levou ao nascimento do DevOps, o qual trouxe uma maior integração entre os times de desenvolvimento e operação.

Os times de segurança, percebendo que estavam ficando para trás, também se adaptaram à essa nova realidade e desenvolveram soluções para fazer parte do movimento shift left, possibilitando que o objetivo de produzir software de qualidade de maneira mais eficiente pudesse ser alcançado. 

Sobre o Autor

Marcelo Yuri Benesciutti é Analista de Segurança da Informação na DB1, com background em Governança, Riscos e Compliance (GRC) utilizando a ISO/IEC 27001:2013, Pentests e AppSec.