I would like to view this page in
O DevSecOps integra práticas de segurança em todas as fases do desenvolvimento, garantindo que as vulnerabilidades sejam tratadas com antecedência, sem desacelerar seu pipeline de CI/CD.
O DevSecOps destaca a importância de incorporar testes e práticas de segurança ao processo de desenvolvimento de software. Antecipar a segurança no processo de desenvolvimento ajuda a garantir que a entrega rápida não ocorra às custas de vulnerabilidades de segurança.
DevSecOps é uma abordagem de desenvolvimento de software baseada na metodologia DevOps. Assim como "DevOps" mescla "desenvolvimento" e "operações", o termo "DevSecOps" combina desenvolvimento, segurança e operações. O acréscimo de "segurança" enfatiza a importância de integrar as considerações de segurança em todos os estágios do ciclo de vida do desenvolvimento de software.
O objetivo do DevSecOps é permitir que as equipes forneçam software com mais rapidez e eficiência, mantendo a base de código livre de vulnerabilidades de segurança. Essa estratégia protege sua organização e seus usuários contra ataques cibernéticos.
A metodologia DevOps foi projetada para acelerar a entrega de software e, ao mesmo tempo, melhorar a qualidade e reduzir os bugs. Com raízes no Movimento Agile, o DevOps foi desenvolvido para resolver problemas com a abordagem tradicional em cascata para o desenvolvimento e a entrega de software.
Em vez de um processo linear de design, desenvolvimento, integração, teste e lançamento que pode durar vários anos, o DevOps incentiva as equipes a mover seu trabalho por esses ciclos com rapidez e frequência. Para conseguir isso, o DevOps defende processos de CI/CD robustos e automatizados que reduzem os tempos de entrega e fornecem feedback rápido, criando um ciclo virtuoso de melhorias contínuas.
Qual é a diferença entre DevSecOps e DevOps? De fato, o DevOps nunca teve a intenção de excluir a segurança. No entanto, embora o movimento de DevOps tenha ajudado a romper as fronteiras entre as equipes de desenvolvimento e de operações, as equipes de segurança da informação geralmente permaneciam isoladas. O termo DevSecOps (juntamente com várias outras versões, como SecDevOps, DevOpsSec e Rugged DevOps) foi criado em um esforço para resolver esse problema.
O uso do termo “DevSecOps” lembra as equipes de levar a segurança em consideração no processo de desenvolvimento e implantação de software. Isto inclui:
Da mesma forma que os testes antecipados na cadeia de desenvolvimento facilitam e agilizam a localização e a correção de bugs, as práticas de segurança são mais fáceis de incorporar e mais eficazes quando abordadas logo no início do processo de desenvolvimento.
O impacto potencial das vulnerabilidades de segurança no seu software não pode ser exagerado.
Além de danos financeiros e de reputação, violações de segurança de software resultaram no vazamento de grandes quantidades de dados confidenciais, incluindo documentos internos e informações pessoais de clientes. Dependendo da jurisdição aplicável, o vazamento de dados dos usuários pode resultar em penalidades financeiras severas, bem como responsabilidade legal.
Apesar de tudo isso, a abordagem tradicional à segurança de software pode fazer com que ela pareça um estorvo em vez de um trunfo. Auditorias e relatórios de segurança retardam o progresso e impedem que você coloque seus recursos mais recentes nas mãos dos seus usuários. No entanto, ao optar por ignorar a importância da segurança no ciclo de vida de desenvolvimento de software (SDLC), você corre o risco de fazer com que o próximo ataque cibernético se torne notícia popular.
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). Porém, em outras situações, eles são novos, talvez resultantes de uma combinação de fatores que nunca foram combinados dessa maneira.
Para complicar ainda mais a situação, quase todos os softwares incorporam dependências, sejam elas de código aberto ou proprietárias, e não há garantia de que o código de terceiros esteja isento de vulnerabilidades. Dessa forma, proteger sua cadeia de suprimentos de software é tão importante quanto avaliar a segurança de seu próprio código-fonte.
Então, como a segurança deve ser trazida para o SDLC? A abordagem de DevSecOps aplica os mesmos princípios que possibilitaram lançamentos mais rápidos e mais estáveis: antecipar a segurança na cadeia de desenvolvimento, para que ela seja abordada com antecedência e frequência.
À primeira vista, antecipar a segurança pode passar a impressão de que você só precisa adicionar um estágio ao seu processo de CI/CD para disponibilizar o software para testes e revisão pela equipe de segurança.
Embora exista um lugar para testes manuais de segurança (como discutiremos), limitar seu envolvimento com os requisitos de segurança a uma etapa no final do processo de CI/CD significa que você perde os benefícios de um feedback rápido e regular, por vários motivos:
Então, o que significa, na prática, uma abordagem de antecipação em relação à segurança? 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.
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.
O ideal é que a segurança seja considerada antes que qualquer código seja escrito. 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.
A automação é um princípio central do DevOps. Isso acelera as tarefas e garante que elas sejam executadas de maneira consistente, liberando as pessoas para fazer um 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.
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 projetadas para automação. Elas se integram ao seu pipeline de CI/CD e podem informar os resultados por meio do dashboard ou inseri-los diretamente em 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.
Os testes dinâmicos de aplicativos (DAST) são o complemento natural ao SAST. 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.
O potencial de ataques cibernéticos é imenso. Muitas vezes, usuários mal-intencionados conseguem encontrar uma falha de segurança em um software amplamente utilizado. Esses ataques (e outros semelhantes) serviram como um lembrete essencial da importância de proteger sua cadeia de suprimentos de software.
O que queremos dizer com "cadeia de suprimentos de software"? Em poucas palavras, é tudo o que está envolvido no desenvolvimento e na entrega do seu software. Todo desenvolvimento de software requer outros softwares, desde componentes e bibliotecas reutilizáveis até IDEs, frameworks e ferramentas de build. A segurança da cadeia de suprimentos de software envolve a avaliação da segurança do software do qual você depende e a proteção dos seus processos de desenvolvimento.
Você pode avaliar a primeira usando ferramentas de composição de software ou análise de componentes (SCA). 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 relevantes para seu produto e organização.
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 grande eficácia no desenvolvimento de software, às vezes sob o disfarce de testes de penetração ou hacking ético, para encontrar ameaças novas e inesperadas.
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á ter bastante confiança nos mecanismos usados para lidar com falhas no software ou ter usuários (e altos executivos) muito tolerantes.
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.
Toda a equipe, e não apenas o responsável pela segurança, deve ser responsável por corrigir as vulnerabilidades. Isso ajudará todos a desenvolverem seu conhecimento e experiência em segurança para que possam usar essas habilidades na base de código atual e em projetos futuros.
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.
Aqui estão algumas medidas adicionais que você pode tomar para reforçar a segurança dos seus pipelines de compilação.
Orquestração de lançamentos é a capacidade de coordenar tarefas automatizadas executadas por vários sistemas para fornecer atualizações de software aos usuários.
O recurso de Submissão pré-testada do TeamCity permite verificar remotamente suas alterações ANTES de enviá-las ao VCS.