O que é DevSecOps e qual seu papel no CD?
DevSecOps enfatiza a importância de incorporar a segurança ao ciclo de vida de desenvolvimento de software (SDLC). Integrar a segurança na cultura, no processo e nas ferramentas da sua equipe evita silos e garante que a entrega rápida não ocorra às custas - ou fique à mercê - das vulnerabilidades de segurança.
Entendendo o DevOps
Antes de mergulharmos no aspecto da segurança, vamos reservar um breve momento para falar sobre DevOps.
Estreitamente vinculado ao desenvolvimento ágil de software, o DevOps visa a criação de uma cultura de colaboração entre o desenvolvimento de software e as operações, onde todos compartilham o objetivo comum de distribuir para seus usuários, de uma forma eficiente, um software de valor que seja funcional. Para colocar essa filosofia em prática, o DevOps promove o uso de processos robustos e automatizados que reduzem os tempos de entrega e promovem feedback rápido, criando um ciclo de melhoria contínua.
Até aqui tudo bem, mas assim como quando você está correndo para pegar um trem, ao acelerar o processo de entrega do software, é importante verificar se você não deixou nada de importante para trás. Infelizmente, esse sempre tem sido o caso com segurança, e é essa a questão que o DevSecOps visa solucionar.
Segurança DevOps
O impacto potencial das vulnerabilidades de segurança no seu software não pode ser exagerado.
Não estamos falando apenas de danos financeiros e de reputação. Violações na segurança de software resultaram no vazamento de grandes quantidades de dados confidenciais, desde documentos internos a produtos ainda não lançados e informações pessoais de clientes, inclusive senhas. Dependendo da jurisdição, o vazamento de dados do usuário pode resultar em graves penalidades financeiras, assim como em responsabilidade legal.
Apesar de tudo isso, a segurança é frequentemente considerada pelas equipes de desenvolvimento como um estorvo, em vez de um ativo. Auditorias e relatórios de segurança atrasam o desenvolvimento, impedindo que você entregue suas mais recentes e brilhantes funcionalidades aos seus usuários. Mas aceitar essa mentalidade é cair na armadilha dos bandidos; se escolhermos ignorar a importância da segurança no SDLC, corremos o risco de desencadear o próximo Wannacry ou Heartbleed.
Embora esses ataques tenham se tornado manchetes, suas origens foram muito mais triviais. Vulnerabilidades existem porque humanos escrevem códigos e cometem erros. Às vezes, esses erros já foram cometidos por outras pessoas e são mais fáceis de reconhecer (se você souber onde procurar) e às vezes são erros novos, talvez resultantes de uma combinação de fatores que antes não aconteciam em conjunto.
Para aumentar a complexidade, quase todos os softwares incorporam dependências, sejam elas de código aberto ou proprietário, não havendo garantia que o código de terceiros também esteja livre de vulnerabilidades.
Então, como a segurança deve ser trazida para o SDLC? A abordagem DevSecOps tem como objetivo aplicar às práticas de segurança os mesmos princípios de colaboração, responsabilidade compartilhada e automação de tudo o que puder ser automatizado e que permitiu lançamentos mais rápidos e estáveis.
Afastando a segurança para a esquerda
O processo de desenvolvimento em cascata segue uma abordagem linear, iniciando com a coleta de requisitos, seguida pelas fases de design, construção, integração e teste e, finalmente, geralmente meses ou anos após o início, o lançamento.
A fase de testes geralmente consistia de longos processos manuais para garantia de qualidade, auditoria de segurança e testes de aceitação. Em um processo jocosamente conhecido como “atirar coisas por cima do muro”, o produto era transferido de uma função para a outra, na qual cada equipe escrevia um longo relatório.
Uma dessas etapas pertencia à equipe de segurança da informação, ou infosec, que produziria um relatório de segurança e uma lista detalhada de descobertas e recomendações. Com frequência, isto exigia alterações na base de código, depois das quais o software passaria novamente por todas as etapas para confirmar se tudo havia sido implementado conforme o esperado (ou não). Com um processo tão demorado, não é de se admirar que um lançamento fosse motivo de grande comemoração!
Tudo isso mudou com o surgimento do desenvolvimento ágil de software, o movimento DevOps e a ascensão da computação em nuvem. A competição é acirrada e velocidade é fundamental. Se você não estiver atendendo às necessidades de seus usuários e corrigindo bugs imediatamente, eles logo encontrarão outro provedor que faça isso. Entregar valor com regularidade e ser capaz de implementar correções rapidamente se tornou a norma para muitas organizações, tendo um pipeline de CI/CD como a base de suas operações.
Embora o termo DevSecOps possa sugerir o contrário, o DevOps nunca teve a intenção de excluir a segurança.
Infelizmente, porém, a realidade é que à medida em que as fronteiras entre equipes de desenvolvimento e operações eram rompidas, as equipes de segurança da informação geralmente permaneciam isoladas em seus silos. Em um esforço para solucionar esse problema, criou-se o termo DevSecOps (junto com várias outras versões, como SecDevOps, DevOpsSec e Rugged DevOps).
O DevSecOps destaca a importância de construir a segurança desde o início, estendendo a cultura de compreensão e responsabilidade compartilhadas às questões de segurança e criando verificações de segurança no regime de testes automatizados de um pipeline de CI/CD. Tal como ocorre com as operações, a ideia é que, ao deslocar a segurança para a esquerda, será mais fácil incorporar os requisitos de segurança e as melhores práticas do que tentar incorporá-los posteriormente, depois do produto ser criado.
Colocando o Sec no DevSecOps: Segurança como Código
Para os não iniciados, pode ser tentador achar que, para deslocar a segurança para a esquerda será necessário apenas disponibilizar seu software para testes pela equipe de segurança na forma de uma etapa do seu pipeline de CI/CD.
Embora haja ainda lugar para testes de segurança manuais, como discutiremos a seguir, limitar seu envolvimento com os requisitos de segurança a apenas uma etapa no final do pipeline não é muito diferente que jogar o software por cima do muro e esperar o relatório voltar.
O resultado mais provável será que, ou as recomendações serão ignoradas porque levarão muito tempo para serem implementadas, ou que todo o processo seja interrompido e o lançamento adiado indefinidamente enquanto os problemas são solucionados e os riscos avaliados. De uma forma ou de outra, isto engendra uma mentalidade nós-e-eles entre a segurança e o resto da organização que não ajuda nenhum dos lados a conseguir o que querem, ou seja, fazer o lançamento de um software útil e seguro.
Então, o que significa na prática a metodologia de deslocamento para a esquerda? Embora não haja uma solução única para todos, as seguintes ferramentas e técnicas podem ajudar a integrar a segurança por todo o SDLC.
Indique campeões de segurança
Embora uma cultura de responsabilidade compartilhada seja importante, não é suficiente dizer às suas equipes de desenvolvimento que todos são responsáveis pela segurança do software. Manter-se em dia com os mais recentes vetores de ataque e novidades de malware é um trabalho em tempo integral e você não pode esperar que todos consigam manter o mesmo nível de conhecimento. Trazer um campeão de segurança para uma equipe multidisciplinar com o objetivo de treinar os outros e compartilhar as melhores práticas pode ajudar a construir o entendimento e promover uma cultura de colaboração junto com os profissionais de segurança.
Faça com que a segurança seja uma restrição de design
Para que os desenvolvedores compartilhem a responsabilidade pela segurança do software que estão construindo, a segurança precisa ser considerada antes que qualquer linha de código seja escrita. A segurança deve ser incluída nas histórias de usuário, levantada durante as reuniões de revisão do backlog e discutida ao planejar cada sprint. Durante o processo de apreciação de um novo recurso, reserve um tempo para discutir os riscos que ele pode apresentar e como mitigá-los.
Adotar uma estratégia de modelagem de ameaças, como o STRIDE, ou usar uma ferramenta como a ficha OWASP, pode ajudá-lo a se manter no caminho certo enquanto aprende essas novas habilidades. Embora tratar de segurança na etapa de design não sirva para interceptar nenhuma ameaça, é um bom começo e ajuda a promover uma cultura DevSecOps.
Acrescente testes de segurança automatizados ao pipeline
A automação é um princípio central do DevOps. Ela não apenas acelera as tarefas e garante que sejam realizadas de uma forma consistente, mas também libera os humanos para que eles cuidem do trabalho mais criativo. Se você quer entregar software aos seus usuários com regularidade e frequência, é essencial que você adicione testes de segurança automatizados ao seu pipeline.
Ao escrever testes automatizados de unidade, de integração e ponta-a-ponta, os recursos de segurança devem ser considerados como tão relevantes quanto qualquer outra funcionalidade. Se sua equipe vem incorporando requisitos de segurança nas histórias de usuários e discutindo modelos de ameaças como parte do processo de design, adicionar testes que cobrem as funções de segurança é uma extensão natural desse trabalho.
Obtenha assistência especializada
Além dos testes que você mesmo escreve, existem várias ferramentas para testes de segurança que podem ajudá-lo a aumentar a confiança na qualidade do seu código. Embora as ferramentas tradicionais de verificação de segurança não fossem adequadas para um pipeline automatizado de CI/CD, agora estão disponíveis ferramentas de teste de segurança de CI/CD que foram projetadas para automação e integração ao pipeline, com os resultados exibidos no painel ou enviados diretamente para ferramentas de rastreamento de bugs. Como acontece com todos os testes automatizados, vale a pena estruturar seus testes para fornecer feedback o mais rápido possível.
As ferramentas de testes de segurança em aplicações estáticas (SAST - Static Application Security Testing) fazem análise estática de código no código-fonte em busca de falhas de segurança conhecidas, tais como estouro de buffer e oportunidades de injeção de SQL. Como a análise estática é executada no código-fonte, ela pode ser executada no início do pipeline de CI/CD, tão logo ocorra o commit das alterações.
As ferramentas SAST são específicas para cada linguagem e algumas se integram ao IDE para fornecer feedback contínuo à medida em que você escreve ou permitem a execução de testes sob demanda. Ao direcionar os desenvolvedores para a linha de código específica que contém a vulnerabilidade, as ferramentas SAST oferecem uma orientação direcionada que torna a correção do problema muito mais rápida. Por outro lado, falsos positivos podem ser um problema, portanto, ser capaz de silenciar ou ignorar alertas específicos é fundamental se você deseja evitar que todos os resultados SAST se transformem em distrações.
O corolário do SAST é o teste de segurança em aplicações dinâmicas (DAST - Dynamic Application Security Testing). Ele adota uma abordagem de teste de caixa preta sobre a aplicação em execução, verificando vulnerabilidades conhecidas, como cross-site scripting (CSS), injeção de comandos e SQL e configuração de insegura do servidor. Como as ferramentas DAST exigem que a aplicação seja compilada e implantada num ambiente de testes, elas são normalmente usadas numa fase posterior do pipeline de CI/CD.
Verifique suas dependências
Composição de software ou análise de componentes (SCA) é outro tipo de teste de segurança automatizado que pode ser executado no início do processo. Como mencionamos acima, praticamente toda base de código incorpora bibliotecas de código aberto e outros componentes, e estes podem introduzir vulnerabilidades.
As ferramentas SCA devem rastrear não apenas as dependências que você inseriu, mas também suas dependências recursivamente em toda a cadeia. Isto é um exemplo perfeito de uma tarefa que é melhor deixar para os computadores, especialmente quando você considera a frequência com que novas dependências são adicionadas a um projeto.
Além de serem executados automaticamente como parte do pipeline de CI/CD, algumas ferramentas SCA estão disponíveis como plug-ins em IDEs para fornecer feedback em tempo real. Como ocorre com testes de segurança estáticos e dinâmicos, os testes em SCA são limitados pelas vulnerabilidades que as ferramentas conhecem, portanto, certifique-se de que as ferramentas escolhidas sejam periodicamente atualizadas com novas ameaças e cubram as áreas que são mais relevantes para seu produto e organização. No entanto, a descoberta de novas e inesperadas ameaças ainda requer a intervenção humana.
Incorpore a equipe vermelha
O conceito de equipe vermelha tem origem nos jogos de guerra, onde membros do seu próprio lado são convidados a desempenhar o papel do inimigo num ataque simulado para identificar fraquezas nas suas próprias defesas e estratégias. A mesma abordagem tem sido usada com ótimos resultados no desenvolvimento de software, às vezes na forma de testes de penetração ou hacking ético.
Para que uma equipe vermelha trabalhe de forma eficaz, eles não podem estar envolvidos no desenvolvimento do sistema em teste. De forma similar ao teste exploratório, o trabalho em uma equipe vermelha requer que os testadores pensem além da caixa e usem o software de maneiras diferentes das intencionadas.
Uma equipe vermelha pode trabalhar num ambiente de teste (de preferência o mais parecido possível com o ambiente de produção) ou num sistema ativo em produção. Se você decidir pela segunda opção, precisará de um elevado grau de confiança nos mecanismos usados pelo seu produto para lidar com falhas ou usuários (e diretores) muito tolerantes.
Trate todas as vulnerabilidades como bugs
Uma abordagem DevSecOps requer que todos assumam a responsabilidade pela segurança de seu software. Portanto, já é hora de parar de pensar nas questões de segurança como uma coisa separada dos bugs "comuns". Quaisquer falhas ou vulnerabilidades descobertas em seu sistema pertencem ao mesmo backlog que todos os outros problemas e devem ser tratados com a mesma prioridade.
A responsabilidade por consertá-los é de toda a equipe, não apenas do campeão de segurança. Essa abordagem ajuda a construir conhecimento e experiência dentro da equipe, e você pode levar essas habilidades para o próximo projeto em que for trabalhar.
Continue inspecionando a produção
Apesar de todos os seus esforços nas etapas anteriores do SDLC, ainda existe o risco de que um hacker encontre um ponto fraco no seu sistema em execução. Ainda vale a pena investir em firewalls e ferramentas de monitoramento para proteger tanto a sua organização como seus usuários. As ferramentas de autoproteção de aplicações em tempo de execução (RASP - Runtime Application Self Protection) são a mais recente adição a essas defesas, detectando e bloqueando automaticamente comportamentos suspeitos.
Concluindo
Desviar a segurança para a esquerda significa torná-la uma questão a ser levada em consideração por toda a equipe em cada etapa do SDLC. Quando você está aplicando práticas de DevOps, esse ciclo de vida repete-se com frequência, proporcionando a você e à sua equipe um feedback constante sobre como seu software se comporta e como ele é usado no mundo real. A introdução da segurança no seu pipeline de CI/CD significa que você recebe feedback constante sobre a segurança da sua aplicação e pode melhorá-lo da mesma forma que o restante das suas funcionalidades.
Verificar e proteger contra vulnerabilidades conhecidas vai pelo menos garantir que seu software segue atentamente os passos dos invasores, em vez de deixá-lo indefeso em relação a ameaças conhecidas. Tratar cada nova vulnerabilidade como um bug que deve passar por triagem, correção e testes vai tornar seu software mais robusto com o tempo.
Em última análise, DevOps - e, portanto, DevSecOps - estão relacionados tanto com cultura quanto a ferramentas e processos que permitem a entrega rápida e frequente de software. Afinal, são as pessoas que tornam tudo possível. Se você deseja incorporar segurança ao SDLC, é fundamental implementar uma cultura de responsabilidade compartilhada, no lugar da cultura de encontrar culpados. Qualquer um deve ser capaz de levantar uma questão de segurança e ser ouvido - seja durante o planejamento do sprint, revisão de código, testes manuais ou no sistema em execução - e todos têm um papel no reconhecimento da importância da segurança e sua implementação.