Jan 01, 1970
Como transformar um pipeline DevOps em um pipeline DevSecOps: uma visão geral do conceito Shift Left por@goal23
11,152 leituras
Como transformar um pipeline DevOps em um pipeline DevSecOps: uma visão geral do conceito Shift Left
Muito longo; Para ler
Expliquei o que é o conceito Shift Left e como ele ajuda a reduzir o custo de correções de bugs e o tempo de desenvolvimento: quanto mais cedo no processo de desenvolvimento você iniciar as verificações de segurança, melhor. Em seguida, desconstruí a estrutura do Pipeline DevSecOps e observei quais verificações de segurança são realizadas em cada estágio do Pipeline.Olá, HackerNoon! Meu nome é Sofia e sou engenheira DevOps/Cloud. Decidi participar do concurso do HackerNoon e Aptible.
Neste artigo, falarei sobre os recursos do pipeline DevSecOps e o conceito de Shift Left. Você aprenderá sobre os principais estágios do pipeline DevSecOps, verificações automatizadas de segurança no desenvolvimento de software e ferramentas gratuitas e de código aberto. Você também encontrará dicas para ajudá-lo a detectar vulnerabilidades mais cedo e melhorar a segurança dos aplicativos.
Este artigo irá ajudá-lo a avaliar a maturidade do seu pipeline DevSecOps, desenvolver um roteiro para seu desenvolvimento, escolher as ferramentas certas para cada tarefa e entender melhor como gerenciar projetos seguindo a filosofia DevSecOps.
Conceito de mudança para a esquerda
O principal objetivo da metodologia DevSecOps é introduzir verificações de segurança automatizadas nos pipelines DevOps, ou seja, no próprio processo de desenvolvimento de software.
Não faz muito tempo, especialistas em segurança da informação realizavam testes após concluir o processo de desenvolvimento. Essa abordagem é ineficiente – se forem descobertos erros durante os testes de segurança, todo o ciclo de desenvolvimento deverá ser reiniciado. Isso é demorado e caro.
Dê uma olhada na imagem abaixo. Você pode ver que o custo da correção de erros aumenta a cada etapa.
Não custa quase nada corrigir problemas de segurança descobertos durante o desenvolvimento e testes funcionais. Todas as alterações necessárias podem ser feitas imediatamente no código-fonte e enviadas para nova verificação.
A correção de problemas no estágio de construção do artefato é pelo menos duas vezes mais cara. Você terá que fazer alterações no processo de construção, por exemplo, editar o Dockerfile, o que significa que precisará da ajuda de engenheiros de DevOps.
Se um erro for detectado durante o teste de integração, será 10 vezes mais caro corrigi-lo. Nesse caso, você deve reiniciar o ciclo de desenvolvimento e envolver desenvolvedores, engenheiros de DevOps e testadores.
Problemas de segurança detectados na fase de implantação podem levar ao vazamento de dados do usuário. A empresa pode receber milhões de dólares em multas e danos à sua reputação, o que significa que o custo de um erro aumenta centenas de vezes.
Portanto, a principal conclusão é que as verificações de segurança devem ser realizadas o mais cedo possível. Se você visualizá-lo, mova-os para o lado esquerdo do Pipeline. Este é o conceito de Shift Left, sobre o qual os especialistas em segurança adoram falar.
Estrutura do pipeline DevSecOps
Os pipelines DevSecOps são uma cadeia automatizada de processos e ferramentas que criam, testam e entregam aplicativos em um ambiente de produção e os protegem em todas as fases.
A imagem acima mostra a estrutura do DevSecOps Pipeline com todas as principais fases das verificações de segurança. Aqui estão algumas palavras sobre cada um deles:
- Pré-comprometer. Implica verificar a segurança do código-fonte antes que o desenvolvedor envie o código para o sistema de controle de versão. Essa verificação permite detectar informações confidenciais não criptografadas, como senhas ou chaves de API.
- Pré-construir. Implica verificar a segurança do código-fonte após sua entrada no sistema de controle de versão. As ferramentas realizam análises estáticas do código-fonte e de suas dependências para detectar vulnerabilidades comuns, como muitas das
Os dez melhores da OWASP lista.
- Pós-construção. É a verificação de segurança de um artefato construído a partir do código-fonte, como um arquivo Docker, pacote RPM ou arquivo JAR. As ferramentas analisam o ambiente e as dependências da aplicação, encontrando versões desatualizadas de pacotes e bibliotecas que já possuem patches em versões mais recentes.
- Tempo de teste. Implica testar a segurança de uma aplicação executada a partir de um artefato coletado. As ferramentas nesta fase tentam “quebrar” a aplicação simulando as ações dos invasores.
- Pós-implantação. Implica verificar a segurança de uma aplicação após ela ter sido implantada em um ambiente de produção. As ferramentas monitoram registros abertos de vulnerabilidades conhecidas em tempo real e notificam quando uma ameaça ao aplicativo é detectada.
A seguir, vamos dar uma olhada mais de perto no que são essas verificações e quais ferramentas são usadas para realizá-las.
Verificações pré-confirmação
As verificações pré-confirmação permitem analisar o código-fonte na máquina do desenvolvedor antes de confirmar as alterações na cópia local do repositório. Se alguma das instruções retornar um erro, o commit não será executado. Neste caso, o desenvolvedor deve corrigir o erro e cometer novamente.
Essa verificação evita a situação em que código não verificado, por exemplo, com segredos não criptografados, entra no repositório.
Para realizar verificações de código-fonte pré-commit, é necessário instalar ferramentas nas máquinas locais dos desenvolvedores. Esta abordagem não tem apenas vantagens, mas também desvantagens. Por exemplo, diferenças ambientais: diferentes versões dos instrumentos, vários sistemas operacionais e até arquiteturas de processador.
Se os desenvolvedores usarem versões diferentes de ferramentas de pré-comprometimento, os resultados da verificação serão diferentes, e isso pode dificultar o trabalho conjunto. Considere isso ao implementar verificações pré-confirmação dentro de uma equipe ou em toda a empresa.
Ferramentas para verificações pré-confirmação
Muitas ferramentas de código aberto podem ser usadas para configurar verificações de pré-confirmação:
Gileaks segredos do git Verificação secreta de curiosidades Sussurros git-todos-segredos detectar segredos vazamentos complicados
Estas são ótimas ferramentas para verificações pré-confirmação.
Verificações pré-construção
Na fase de pré-construção, é realizado o Teste de Caixa Branca. Essas verificações são utilizadas para analisar o código-fonte, como na etapa anterior. Neste caso, a aplicação é uma “caixa branca” porque conhecemos e entendemos a sua arquitetura e estrutura interna.
Existem vários tipos de verificações de pré-construção:
- Detecção Secreta
- Teste estático de segurança de aplicativos (SAST)
- Análise de Composição de Software (SCA)
Agora, vamos discuti-los em detalhes.
Verificação de detecção de segredo pré-construída
A detecção de segredo é uma verificação automatizada que detecta informações confidenciais não criptografadas: segredos não criptografados no código-fonte que entraram em um sistema de controle de versão.
As verificações de pré-construção são realizadas depois que o código-fonte entra no repositório do sistema de controle de versão. Portanto, todos os dados confidenciais não criptografados no armazenamento podem ser potencialmente acessados por invasores, por exemplo, se o conteúdo do repositório vazar.
Além disso, o processo de implementação de verificações de detecção de segredos pode ocorrer não do zero, mas num projecto em evolução. Nesse caso, segredos não criptografados podem ser encontrados em commits antigos e em diferentes ramificações do repositório.
Para resolver esses problemas, precisamos fazer muitas coisas diferentes. Por exemplo, devemos limpar os repositórios de segredos não criptografados ou implementar várias ferramentas de gerenciamento de segredos, como o Hashicorp Vault .
Ferramentas para detecção de segredos
A detecção de segredo pode ser configurada usando
Verificação SAST pré-construída
O Static Application Security Testing (SAST) é um teste em que os analisadores não apenas verificam a correção sintática, mas também medem a qualidade do código com a ajuda de métricas exclusivas. A principal tarefa dos scanners SAST são os testes de segurança.
Em particular, os analisadores SAST contêm código-fonte para vulnerabilidades comuns, por exemplo, alguns dos
A análise SAST é chamada de Teste de Caixa Branca porque o analisador pode acessar a estrutura interna do aplicativo. É importante observar que os analisadores verificam o código-fonte sem executá-lo, portanto podem gerar falsos positivos e não detectar algumas vulnerabilidades.
Por esse motivo, você não deve se limitar apenas à análise SAST. É melhor abordar a questão de forma abrangente e utilizar diferentes tipos de análise: SCA, DAST, IAST e OAST.
Ferramentas SAST
Soluções proprietárias:
A solução gratuita é GitLab SAST.
Verificação SCA de origem pré-construída
A Análise de Composição de Software (SCA) é uma metodologia que protege aplicativos analisando seus componentes de código aberto.
Os scanners SCA procuram dependências desatualizadas que contenham vulnerabilidades e explorações conhecidas. Além disso, algumas ferramentas SCA podem determinar a compatibilidade de licença de componentes e os riscos de violação de licença.
O Source SCA analisa o código-fonte e, mais especificamente, as dependências do aplicativo definidas no código-fonte. Essa análise costuma ser chamada de Verificação de Dependências.
O SCA permite detectar um problema em que uma vulnerabilidade em um componente pode levar a problemas de segurança em todos os aplicativos.
Um bom exemplo é
Ferramentas SCA
Solução comercial com planos de preços gratuitos:
Como parte do GitLab (disponível apenas na versão Ultimate), você pode usar
Verificações pós-construção: SCA binário
A fase de pós-construção ocorre depois que os artefatos foram construídos a partir do código-fonte no CI Pipeline: uma imagem Docker, um pacote RPM ou um arquivo JAR. Com verificações pós-compilação, você pode analisar as dependências nesses artefatos binários.
A análise SCA binária envolve a inspeção de artefatos binários, como imagens Docker, pacotes RPM e arquivos JAR/WAR/EAR. Também é frequentemente referido como verificação de contêiner. Faz sentido executá-lo quando os artefatos binários são construídos, ou seja, não antes do estágio pós-construção.
Existem alguns recursos interessantes ao trabalhar com imagens Docker. Os analisadores binários SCA verificam camadas de imagens Docker e as procuram como somas de hash em bancos de dados públicos de vulnerabilidade, como
Alguns dos analisadores podem não apenas encontrar componentes vulneráveis, mas também sugerir uma correção, por exemplo, especificando a versão mínima necessária de um componente com uma vulnerabilidade já corrigida.
Exemplos de analisadores SCA binários populares
A solução gratuita é
Soluções de código aberto:
Registro Docker com analisadores integrados -
Verificações de tempo de teste: DAST, IAST e OAST
Nesta fase, são realizados testes dinâmicos de caixa cinza e teste de caixa preta. Quando a estrutura interna da aplicação é parcial ou totalmente desconhecida, essas verificações de segurança são realizadas emulando as ações de um invasor que encontra vulnerabilidades e tenta “quebrar” a aplicação explorando-as. Vamos discutir brevemente cada um deles: DAST, IAST e OAST.
Verificação DAST em tempo de teste
Os scanners DAST testam aplicativos automaticamente simulando ataques externos por meio de várias vulnerabilidades. A aplicação é uma caixa preta para o analisador; nada se sabe sobre isso.
Para verificações DAST, é necessário ter uma instância em execução do aplicativo disponível para o scanner. Além disso, quanto mais próximos os parâmetros da instância de teste da aplicação estiverem da instalação de produção, menos falsos positivos haverá.
Por exemplo, suponha que você tenha implantado uma instância de aplicativo de teste acessível somente por meio do protocolo HTTP, mas na produção, o aplicativo seja acessível somente por meio do protocolo HTTP.
Nesse caso, o scanner DAST irá gerar alguns erros relacionados à falta de criptografia do tráfego entre o cliente (analisador) e o servidor (instância da aplicação).
Exemplos de ferramentas DAST
Ferramentas que merecem sua atenção:
DAST do GitLab — disponível apenas na versão UltimateProxy de ataque Zed OWASP (ZAP) — uma solução de código aberto, que também é usada no GitLab DAST- Acunetix
- Fortify WebInspect
- AppScan de Segurança HCL
- DAST gerenciado pela Synopsys
Tenable.io (Verificação de aplicativos da Web)- Análise Dinâmica Veracode
Ótimo, siga em frente.
Verificação IAST em tempo de teste
IAST (Interactive Application Security Testing) é um teste de caixa cinza que combina as vantagens e os pontos fortes do teste de caixa branca SAST e do teste de caixa preta DAST.
Para coletar todas as vantagens e eliminar as desvantagens dos métodos SAST e DAST, os desenvolvedores inventaram o IAST - um mecanismo híbrido que combina esses métodos. Aumenta a precisão dos testes dinâmicos porque fornece mais informações sobre o funcionamento do aplicativo por meio da análise de código.
Vale lembrar que além das vantagens, o IAST apresenta limitações. A mais básica é a dependência da linguagem em que a aplicação em teste é escrita. As soluções IAST funcionam no nível da aplicação e requerem acesso ao código executável para analisar seu comportamento.
Isto significa que as soluções IAST devem ser capazes de compreender a linguagem de programação na qual a aplicação é escrita. Deve-se notar que o suporte para uma solução IAST específica pode ser melhor implementado para alguns idiomas do que para outros.
A análise IAST também leva muito tempo. Depende de muitos fatores, como o tamanho e a complexidade da aplicação, o número de dependências externas e o desempenho da ferramenta IAST utilizada.
Além disso, o processo de análise não verifica o código em si, mas verifica apenas os fragmentos que são executados diretamente. Portanto, a análise IAST é melhor combinada com testes funcionais quando você pode testar tantos cenários de aplicação quanto possível.
Exemplos de ferramentas IAST
Aqui estão ótimas ferramentas para você:
Buscador de Sinopse Análise Interativa Veracode Microfoco Fortify WebInspect Checkmarx CxIAST Avaliação de contraste Detecção HDiv (IAST)
Ótimo, siga em frente.
Verificação OAST em tempo de teste
OAST (Out-of-band Application Security Testing) é uma técnica desenvolvida por
Exemplos de ferramentas OAST
Eu recomendo você:
Suíte Burp - OWASP ZAP com
Plug-in OAST - Serviços OAST
vangloriar-se ,Tuk Tuk , einteragir
Ir em frente.
Verificações pós-implantação
Esta é uma etapa essencial para garantir a segurança e a operabilidade do aplicativo. Ao contrário das verificações pré-confirmação, que são realizadas no estágio de desenvolvimento, as verificações pós-implantação permitem identificar possíveis problemas já durante a operação do aplicativo no ambiente natural.
Monitorando a Segurança de Artefatos
Para detectar novas vulnerabilidades a tempo, é necessário realizar verificações regulares de artefatos, inclusive após a implantação de um aplicativo.
Isso pode ser feito usando repositórios ou ferramentas especiais, como
Monitoramento de segurança de aplicativos
Outra forma de garantir a segurança é monitorar o próprio aplicativo. Existem diversas tecnologias disponíveis para esse fim:
- Web Application Firewall (WAF) é uma ferramenta de filtragem de tráfego. Ele funciona na camada de aplicação e protege aplicações web analisando o tráfego HTTP/HTTPS.
- RASP (Runtime Application Self-Protection) é uma tecnologia que detecta e bloqueia ataques a um aplicativo em tempo real. Ele adiciona uma função de defesa ao ambiente de tempo de execução, permitindo que o aplicativo se autoproteja automaticamente.
A principal vantagem do RASP sobre o WAF é que ele entende como o aplicativo funciona e detecta ataques e tráfego ilegítimo. O RASP pode ver não apenas ataques típicos usando correspondência de assinaturas, mas também tentativas de explorar vulnerabilidades de dia zero reagindo a anomalias.
Ao contrário do WAF, o RASP funciona dentro e com o aplicativo. WAF pode ser enganado. Se um invasor alterar o código do aplicativo, o WAF não poderá detectá-lo porque não entende o contexto de execução.
O RASP tem acesso a informações de diagnóstico sobre o aplicativo, pode analisá-lo, detectar anomalias e bloquear ataques.
A tecnologia RASP tem como especialidade focar na prevenção de ataques por padrão. O sistema não requer acesso ao código-fonte.
Tolos RASP
Eu recomendo você:
Fortalecer Tela quadrada OpenRASP é uma solução de código aberto desenvolvida pela BaiduCiências de Sinais Jscrambler HDdiv Imperva
Ótimo, siga em frente.
Visualização de resultados de pipelines DevSecOps e gerenciamento de vulnerabilidades
Em diferentes estágios do pipeline, eu uso muitos analisadores de testes de segurança de aplicativos/DevSecOps. Cada um deles gera um relatório em formato próprio, e alguns deles geram os chamados Falsos Positivos. Por isso, não é fácil analisar a segurança de uma aplicação como um todo.
Para analisar vulnerabilidades com eficácia e gerenciar o processo de correção, são usadas ferramentas especializadas de gerenciamento de vulnerabilidades, muitas vezes chamadas simplesmente de painéis de segurança .
Os painéis de segurança resolvem o problema entregando os resultados das análises DevSecOps de uma forma unificada e fácil de analisar. Dessa forma, os engenheiros de segurança podem ver quais problemas existem, quais são os mais críticos e quais precisam ser resolvidos primeiro.
Ferramentas DevSecOps
Uma ampla gama de ferramentas é geralmente usada como painéis de segurança: por exemplo, sistemas SOAR/SIEM clássicos e o orquestrador DevSecOps especializado AppSec.Hub da Swordfish Security ou o kit de ferramentas de gerenciamento de vulnerabilidades de código aberto DefectDojo.
DefectDojo é uma ferramenta amplamente difundida. É amplamente utilizado até mesmo em empresas empresariais. No entanto, apesar de sua popularidade e idade sólida, esta ferramenta ocasionalmente apresenta alguns defeitos de nível inicial quando os contribuidores quebram a funcionalidade básica no commit.
No entanto, o que é bom é que os desenvolvedores e mantenedores do DefectDojo ajudam a resolver as complexidades. Os desenvolvedores do DefectDojo são pessoas muito receptivas - recomendamos contatá-los diretamente por meio de Problemas no GitHub.
Conceito de mudança para a esquerda: vamos resumir
Mais uma vez, aqui está uma rápida recapitulação do que estava no artigo.
Expliquei o que é o conceito Shift Left e como ele ajuda a reduzir o custo de correções de bugs e o tempo de desenvolvimento: quanto mais cedo no processo de desenvolvimento você iniciar as verificações de segurança, melhor.
Em seguida, desconstruí a estrutura do Pipeline DevSecOps e observei quais verificações de segurança são realizadas em cada estágio do Pipeline:
- Pré-comprometer. Implica verificar a segurança do código-fonte antes de entrar no sistema de controle de versão.
- Pré-construir. É uma verificação da segurança do código-fonte no sistema de controle de versão (Secret Detection, SAST, SCA).
- Pós-construção. É uma verificação de segurança de um artefato construído a partir do código-fonte (Source SCA, Binary SCA).
- Tempo de teste. Implica testar a segurança da aplicação que está rodando a partir do artefato coletado (DAST, IAST e OAST).
- Pós-implantação. Implica verificar a segurança da aplicação após implantação no ambiente de produção (WAF, RASP).
Agora você entende como funciona o DevSecOps Pipeline. Agora você pode avaliar a maturidade de seus pipelines DevSecOps, desenvolver um roteiro para seu desenvolvimento e escolher as ferramentas certas para cada tarefa.
L O A D I N G
. . . comments & more!
. . . comments & more!
