Como mudar para a esquerda com integração contínua
A integração contínua (CI) é um processo que melhora a qualidade do código por meio de pipelines de implantação. A segurança pode ser integrada a esses pipelines mais cedo no processo, ajudando as empresas a mudar para a esquerda.
Mudar para a esquerda é uma abordagem que move o teste para o início do ciclo de vida do desenvolvimento de software (logo, "mudando para a esquerda"). Se os testes de segurança acontecerem quando o código estiver pronto para produção, fica mais difícil voltar e corrigir problemas e, muitas vezes, fica tarde demais para corrigi-los rapidamente. Isso pode levar a atrasos de entrega, problemas de segurança e silos de comunicação entre as equipes de segurança e outros grupos de trabalho de DevOps.
À medida que as empresas tentam mudar para uma estrutura mais orientada ao DevSecOps, executar testes de segurança mais cedo no ciclo de vida do desenvolvimento será fundamental. A maneira de fazer isso é integrando testes de segurança nos pipelines de implantação para que o código seja continuamente testado, não apenas em relação a outros commits no repositório compartilhado, mas também para segurança.
A integração contínua](/topics/ci-cd/) é um processo que melhora a qualidade de código por meio de pipelines de implantação. A segurança pode ser integrada a esses pipelines mais cedo no processo, ajudando as empresas a mudar para a esquerda.
Integrar a segurança em pipelines de integração contínua
Os Testes Estáticos de Segurança de Aplicações (SAST) são uma forma de automatizar a segurança por meio da integração contínua. O SAST analisa o código-fonte e permite que os desenvolvedores corrijam problemas mais cedo no ciclo de vida do desenvolvimento de software.
No GitLab CI/CD, o pipeline de implantação verifica o relatório SAST e compara as vulnerabilidades entre os branches de origem e específico. Essas descobertas aparecem na solicitação de merge.
Os Testes Dinâmicos de Segurança de Aplicações (DAST) geralmente funcionam em conjunto com o SAST. Enquanto SAST analisa o código-fonte, DAST analisa erros de runtime em aplicações executadas. Uma vez que uma aplicação é implantada, ela é exposta a novas formas de riscos de segurança, como cross-site scripting (XSS) ou falhas de autenticação.
Como os SAST, o GitLab verifica o relatório DAST e compara as vulnerabilidades entre os branches de origem e específico e exibe os resultados, mas a comparação usa apenas o pipeline mais recente executado para o commit básico do branch específico.
Outros tipos de teste de segurança incluem os Testes Interativos de Segurança de Aplicações (IAST) e Proteção de Segurança de Aplicações em Runtime (RASP). O IAST opera colocando um agente dentro de uma aplicação. Já a RASP é uma ferramenta de segurança dentro da aplicação que pode responder a ataques em tempo real.
Reduzir a complexidade da cadeia de ferramentas
Além da manutenção demorada, uma cadeia de ferramentas complexa pode deixar um sistema vulnerável a riscos de segurança. Muitas equipes de DevSecOps usam plugins, scripts ou integrações personalizadas embutidas em código para integrar suas ferramentas. Como alguns deles precisam ser feitos manualmente, isso torna essas cadeias de ferramentas sujeitas a erros humanos. Além disso, mais ferramentas significam mais autenticação, mais permissões, requisitos de segurança e menos visibilidade do ciclo de vida do desenvolvimento de software. Essas camadas de abstração dificultam não apenas identificar problemas, mas também resolvê-los.
Um sistema complexo incorpora vários pontos de falha. Se as empresas quiserem mudar para a esquerda, reduzir parte dessa complexidade facilita a entrada da segurança e da conformidade no ciclo de vida do desenvolvimento. Uma cadeia de ferramentas ou um ambiente de plugins complexo também pode resultar em pipelines frágeis que demandam atenção extra.
Proteger seus sistemas de integração contínua
A proteção do sistema é um processo que reduz sua superfície de vulnerabilidade. Semelhante à redução da complexidade da cadeia de ferramentas para diminuir as fontes de risco, as listas de verificação de proteção permitem que uma empresa examine seus sistemas internos para garantir que estão seguindo as melhores práticas de segurança.
É recomendado proteger os sistemas que hospedam os repositórios de artefatos de origem e de compilação, os servidores de CI e de entrega contínua (CD) e os sistemas que hospedam as ferramentas de gerenciamento de configuração, compilação, implantação e lançamento. Garanta que sua equipe saiba o que é feito na infraestrutura local e o que é feito na nuvem e como isso afeta os fluxos de trabalho.
Proteger seu sistema de integração contínua, além de incorporar análises de segurança em seus pipelines de implantação, pode tornar mais fácil para as equipes mudarem para a esquerda. Equipes maduras de DevOps estão naturalmente implementando testes de segurança em seu processo de integração contínua e adotando a abordagem mudar para a esquerda. Em vez de tratar a segurança como um adendo tardio, essas equipes de DevSecOps mantêm a segurança em primeiro lugar.
Tudo pronto para começar?
Descubra o que sua equipe pode fazer com uma plataforma DevSecOps unificada.