In this article
Tecnologias DevSecOps
As tecnologias permitem que sua equipe execute corretamente os processos de DevSecOps. Quando a maioria das pessoas pensa em DevSecOps e CI/CD, as ferramentas costumam vir à mente. A capacidade de integrar e automatizar diversos processos de desenvolvimento, segurança e operações é essencial para uma implementação bem-sucedida de DevSecOps. A seguir, apresentamos uma coleção de tecnologias que as organizações devem considerar ao buscar implementar com sucesso uma metodologia DevSecOps na empresa.
Repositório de código-fonte
O repositório de código-fonte é o elemento central de praticamente todo ambiente de desenvolvimento no mundo. Em uma abordagem DevSecOps, ele é a principal tecnologia com a qual a maioria das outras tecnologias do pipeline se integra. Ao avaliar se a organização está pronta para adotar o paradigma DevSecOps, é preciso considerar a capacidade do repositório de se integrar a outras tecnologias essenciais.
À medida que mais aspectos do ambiente da aplicação passam a ser definidos em código, a segurança do repositório se torna fundamental. É preciso adotar práticas recomendadas para acesso de usuários, configurações do repositório e outros aspectos. Expor o repositório a pessoas não autorizadas ou que não precisam acessá-lo pode gerar riscos significativos.
Destaque tecnológico: práticas recomendadas para repositórios Bitbucket
O Bitbucket é um dos repositórios mais populares em organizações que adotam DevSecOps. Sua interface web prática e a integração com uma ampla variedade de outras tecnologias fazem dele uma ótima opção para atender aos requisitos de automação e orquestração do DevSecOps. No entanto, essa popularidade também vem acompanhada de um aumento na ocorrência de vulnerabilidades de segurança, geralmente causadas por configurações ou pelo uso inadequados dos repositórios. Para ajudar a evitar esses problemas, siga estas práticas recomendadas:
Nunca armazene credenciais como código ou configuração no Bitbucket
As práticas de gerenciamento de segredos devem ser adotadas em todos os repositórios armazenados no Bitbucket. Algumas delas incluem usar o git-secrets, auditar segredos regularmente e utilizar um gerenciador de segredos confiável.Remova dados confidenciais
Se dados confidenciais forem parar em um repositório, invalide todos os tokens e senhas expostos, remova as informações e limpe o histórico do Git. Em seguida, avalie o impacto do vazamento de informações privadas.Controle rigorosamente o acesso
Falhas na segurança dos repositórios costumam ser causadas por erros humanos. Para ajudar a reduzir esse risco, adote um gerenciamento robusto de usuários e use técnicas de controle de acesso.Adicione um arquivo SECURITY.md
Inclua um arquivo SECURITY.md com informações relacionadas à segurança do projeto. O arquivo deve conter uma política de divulgação, uma política de atualizações de segurança, configurações relacionadas à segurança, lacunas de segurança conhecidas e melhorias futuras.Valide os apps do Bitbucket
Verifique os direitos de acesso, a credibilidade dos autores ou organizações e a postura geral de segurança desses apps, desenvolvidos por terceiros.Receba dicas de segurança no fluxo de trabalho com o Code Insights
Faça varreduras em todas as solicitações de pull abertas usando o Bitbucket Code Insights. Isso ajuda a identificar novas vulnerabilidades que possam ser introduzidas pela solicitação.Adicione testes de segurança às solicitações de pull
Use os hooks do Bitbucket para verificar se as solicitações de pull introduzem novas vulnerabilidades.Adicione testes de segurança aos Bitbucket Pipes
Inclua pipes de varredura de segurança no fluxo de CI/CD para garantir que os pipelines automatizados não introduzam regressões de segurança.Considere o Bitbucket Server
Para reduzir significativamente a superfície de ataque de um repositório, o Bitbucket Server permite hospedá-lo localmente.Alterne as chaves SSH e os tokens de acesso pessoal
O acesso ao Bitbucket geralmente é feito com chaves SSH ou tokens de usuário pessoais. Alternar essas chaves periodicamente pode reduzir o risco de que chaves vazadas exponham seu repositório.
Para saber mais, consulte nosso blog e o guia prático em https://snyk.io/blog/cheat-sheet-10-bitbucket-security-best-practices/
Gerenciamento de configuração
Tradicionalmente, as tarefas necessárias para definir e manter configurações consistentes em toda a infraestrutura, nos softwares de sistema e até mesmo nas aplicações de suporte consomem muitos recursos. Para viabilizar um verdadeiro modelo DevSecOps, o gerenciamento de configuração precisa ser automatizado e integrado ao ciclo de vida geral do desenvolvimento. Com o aumento dos componentes definidos como código, isso ficou mais fácil de realizar.
Integrar e automatizar o gerenciamento de configuração traz vários benefícios importantes. Primeiro, facilita a visualização e a geração de relatórios sobre mudanças no ambiente. Embora isso não substitua as práticas de gerenciamento de mudanças, ajuda a garantir o rastreamento adequado. Além disso, essa automação oferece controle granular de versões, permitindo vincular as mudanças na infraestrutura e nos softwares de suporte às versões de código correspondentes. Isso ajuda a evitar problemas causados por configurações incompatíveis que levam a falhas de software. Por fim, ao automatizar o gerenciamento de configuração, as organizações também garantem que as configurações sejam consistentes em todo o ambiente. Isso também facilita a identificação de ameaças e a resposta a incidentes de segurança.
Ao se preparar para automatizar o gerenciamento de configuração, a organização precisa considerar alguns elementos importantes.
Orquestração
Uma das grandes vantagens de integrar o gerenciamento automatizado de configuração à infraestrutura como código é poder automatizar a implantação da infraestrutura conforme necessário. Seja em um ambiente de máquinas virtuais, na nuvem ou com contêineres, há soluções que orquestram a implantação dinâmica da infraestrutura. Ao adotar um modelo DevSecOps, as organizações precisam entender o escopo dessas implantações e garantir que estão usando as ferramentas certas para suas aplicações.

Fortalecimento de hosts
A prática de fortalecer hosts não é nova, mas, se fosse mais adotada, menos serviços e aplicações ficariam desnecessariamente expostos ao público. Com a introdução de infraestruturas orquestradas altamente dinâmicas, essa prática se torna ainda mais importante. Inúmeros incidentes de segurança podem ser atribuídos diretamente à manutenção de uma superfície de ataque genérica, que permite que ferramentas automatizadas tenham sucesso até mesmo nos ataques mais básicos. As práticas e metodologias recomendadas para fortalecer a maioria das tecnologias já estão maduras o suficiente para serem facilmente incorporadas à criação de modelos, reduzindo a superfície de ataque e reforçando um modelo de confiança. Esse modelo pode ser codificado como metadados para processamento posterior pelo pipeline de CI e, depois, usado em outros processos, como a aplicação de patches.
Destaque tecnológico: protegendo imagens Docker
Com a migração de cada vez mais organizações para ambientes nativos da nuvem, o uso de contêineres cresceu exponencialmente. As imagens Docker se tornaram comuns, assim como as violações causadas por imagens de contêineres inseguras. Para ajudar a garantir a segurança das imagens Docker, siga estas práticas recomendadas:
Minimize as imagens de contêiner
Escolha imagens com menos bibliotecas e ferramentas de sistema operacional para reduzir a superfície de ataque geral. Sempre que possível, prefira imagens baseadas em Alpine a imagens completas de sistemas operacionais.Limite os privilégios de usuários
Crie um usuário e um grupo dedicados na imagem, com permissões mínimas para executar a aplicação, e use o mesmo usuário para executar esse processo.Assine e verifique as imagens de contêiner
Assine digitalmente as imagens ao criá-las e verifique a confiança e a autenticidade delas ao baixá-las de um publicador.Monitore regularmente as imagens em busca de vulnerabilidades de código aberto
Faça a varredura das imagens Docker em busca de vulnerabilidades conhecidas e integre essas verificações ao ambiente de integração contínua.Proteja as imagens contra vazamento de informações
Tokens, chaves e outros segredos costumam ficar expostos nas imagens durante a criação. Para evitar isso, use builds em múltiplas etapas e o recurso Docker secrets para montar arquivos confidenciais sem armazená-los em cache. Além disso, um arquivo .dockerignore pode ajudar a evitar instruções COPY que incluam arquivos confidenciais presentes no contexto do build.Use tags fixas para garantir a imutabilidade
Novas versões de imagens podem ser enviadas usando as mesmas tags, o que pode resultar em imagens inconsistentes durante os builds. Para evitar isso, use tags descritivas que incluam a versão e o sistema operacional ou uma hash do conteúdo da imagem.Use COPY em vez de ADD
A instrução ADD pode expor vários vetores de ataque, incluindo ataques man-in-the-middle e Zip Slip. Sempre que possível, use COPY.Use labels para os metadados
A inclusão de metadados adicionais nas labels da imagem pode fornecer informações úteis aos usuários. Também é recomendável incluir nas labels informações sobre a política de divulgação responsável.Use builds em múltiplas etapas para reduzir o tamanho da imagem
Use builds em múltiplas etapas para criar imagens menores e mais enxutas, reduzindo assim a superfície de ataque das dependências incluídas na imagem Docker.Use um linter
Uma ferramenta de análise estática de código pode ajudar a aplicar as práticas recomendadas para Dockerfiles e detectar possíveis problemas.
Para saber mais, consulte nosso blog e o guia prático em https://snyk.io/blog/10-docker-image-security-best-practices/
Como esses metadados são definidos em código e geralmente armazenados em um repositório junto com o restante do código da aplicação, também é preciso implementar ferramentas automatizadas capazes de identificar vulnerabilidades nas configurações ou desvios das práticas recomendadas de fortalecimento. Isso ajuda a garantir que a segurança não seja apenas incorporada ao projeto e à implantação da infraestrutura, mas também aplicada sem atrapalhar o desenvolvimento.
CI/CD para aplicação de patches
Depois que os metadados forem associados a cada ativo, a organização poderá usar esses dados para aplicar patches no nível de CI/CD. É possível comparar feeds de inteligência contra ameaças e de gerenciamento de vulnerabilidades com a pilha de software implantada para identificar correspondências nos modelos e, em seguida, colocá-las na fila de implantação. Assim, a aplicação de patches em sistemas ativos deixa de ser necessária, limitando o impacto do tempo de inatividade. Isso também permite avaliar a exposição a riscos quase em tempo real.
Práticas de programação segura
Todos os padrões de programação segura devem ser comparados continuamente com as novas recomendações de segurança. Todas as mudanças no código precisam ser verificadas e testadas em relação a essas recomendações: nenhuma mudança é pequena demais para ser ignorada nesse processo. Essa tarefa não é simples, e os benefícios dessas práticas não devem ser subestimados, pois vão além da quantidade de mudanças feitas durante o ciclo de vida do desenvolvimento.
O OWASP Top 10 é um ótimo ponto de partida para essa análise. Transforme as mudanças no código em testes de QA e aproveite os testes automatizados para fornecer feedback em tempo hábil às equipes de desenvolvimento. Além disso, o OWASP ASVS, com seus 19 domínios de verificação, é muito adequado ao desenvolvimento de software seguro.
Com o ritmo cada vez mais acelerado de surgimento de técnicas e frameworks de desenvolvimento de software, o desenvolvimento orientado a ataques define um processo no qual os desenvolvedores aprendem, em paralelo, sobre ferramentas, técnicas e procedimentos de desenvolvimento de software e segurança de aplicações.
Avaliação no nível da aplicação
A avaliação automatizada de aplicações em busca de vulnerabilidades de segurança é fundamental para o DevSecOps. Ela permite que a empresa compreenda plenamente sua postura de risco e corrija vulnerabilidades antes que sejam exploradas por invasores. As soluções a seguir podem ajudar a aprimorar a postura de segurança de um ambiente DevSecOps:
Verificação do código-fonte
A verificação do código-fonte deve ser feita com ferramentas de testes estáticos de segurança de aplicações (SAST). O SAST é usado para verificar o repositório do código-fonte, geralmente a branch principal, identificar vulnerabilidades e realizar análise de composição de software. As ferramentas de SAST devem ser integradas aos processos pós-commit para garantir que o novo código seja verificado proativamente em busca de vulnerabilidades. Com a integração de uma ferramenta de SAST, é possível corrigir vulnerabilidades mais cedo no ciclo de desenvolvimento de software, reduzindo os riscos e a exposição das aplicações.
Ferramenta de análise dinâmica de aplicações (DAST)
As ferramentas de análise dinâmica de aplicações verificam os sites de homologação e produção em execução, analisando campos de entrada, formulários e diversos outros aspectos da aplicação web em busca de vulnerabilidades. Essas ferramentas devem ser integradas ao pipeline, à medida que as versões são implantadas nos ambientes seguintes.
Integração de SAST com IDEs
A integração de plugins de análise estática de código às IDEs permite que a pessoa desenvolvedora receba notificações quase em tempo real sobre práticas de codificação inseguras dentro do ambiente de desenvolvimento integrado. Essa é uma maneira eficaz de corrigir e mitigar vulnerabilidades imediatamente, sem precisar sair do ambiente de desenvolvimento.
Verificação de binários
Todos os binários devem ser verificados em busca de problemas de segurança com base na lista de verificação de codificação e, em seguida, assinados digitalmente. A assinatura digital é tratada da mesma forma que os metadados. Por exemplo, na CI, somente binários assinados podem ser usados e implantados, garantindo o nível adequado de aprovação de segurança sem que seja preciso esperar a equipe de segurança ter disponibilidade.
Auditoria pré-implantação
Usar um modelo predefinido para criar ativos é essencial para garantir o nível de segurança desejado, mas isso deve ser complementado por verificações nos hosts. A maioria dos scanners de segurança já oferece um módulo de conformidade que permite importar seu modelo.
Auditoria pós-implantação
Depois de instanciados, esses modelos predefinidos podem ser comparados às verificações pré-implantação para identificar diferenças e detectar alterações que possam introduzir ameaças à segurança. Para automatizar esse processo, o ideal é usar a integração com APIs.
Gerenciamento automatizado de vulnerabilidades
As soluções de gerenciamento de vulnerabilidades devem ser integradas por API às plataformas de verificação de infraestrutura e aplicações web. Essa integração garante que todas as vulnerabilidades detectadas sejam rastreadas pela organização. Além disso, em ambientes DevSecOps maduros, ela pode correlacionar em tempo real ameaças ativas com vulnerabilidades identificadas. Isso ajuda a identificar:
Quais ativos estão sujeitos a exploits conhecidos.
Novas ameaças que possam representar um risco imediato para a empresa.
Os processos de gerenciamento de vulnerabilidades também devem ser integrados ao sistema de rastreamento de bugs usado pelas pessoas desenvolvedoras. Assim, os registros de bugs podem ser abertos assim que as vulnerabilidades forem detectadas, acelerando sua correção.
Verificação automatizada de conformidade
É possível alcançar a conformidade com avaliações automatizadas das configurações de segurança, reduzindo riscos e mantendo a conformidade contínua. Isso reduz os custos de conformidade ao diminuir o tempo e o esforço necessários para avaliar os sistemas. Também permite compartilhar dados de conformidade com a ferramenta de GRC da empresa e com os aplicativos de suporte técnico, dando visibilidade ao status de conformidade.
Gerenciamento de segredos
Em um contexto de segurança da informação, “segredos” são todas as informações confidenciais que uma equipe precisa conhecer, como as credenciais de um banco de dados ou de uma API de terceiros. Para estabelecer uma conexão confiável, são necessárias credenciais, um certificado ou um token de API. Mesmo com essas precauções, gerenciar segredos pode ser desafiador e, muitas vezes, se tornar uma fonte de erros ou até de violações de segurança.
Entre as técnicas que facilitam o gerenciamento de segredos estão definir uma constante no código-fonte ou armazenar os segredos em um arquivo de configuração que não seja incluído no controle de versão. Essas técnicas resolvem alguns problemas, mas também criam outros desafios, principalmente na rotação de chaves.
A abordagem ideal é usar um repositório compartilhado e sincronizado de senhas criptografadas, que cada pessoa da equipe possa descriptografar individualmente, sem precisar compartilhar uma senha. Duas ferramentas permitem fazer isso: GPG (GNU Privacy Guard) e Pass. O GPG permite implementar uma infraestrutura de chave pública e é usado com frequência para criptografar e-mails. No entanto, o GPG pode ser complexo, e o Pass — chamado por seus desenvolvedores de “gerenciador de senhas padrão do Unix” — oferece uma interface prática para usá-lo. Com o Pass, você pode criptografar informações secretas com uma ou mais chaves privadas. Todas as informações criptografadas ficam armazenadas em arquivos simples em um diretório, que pode ser compartilhado por meio do controle de versão. Essas ferramentas permitem criar um conjunto de informações criptografadas que pode ser compartilhado sem comprometer a segurança.
Gerenciar segredos de forma eficaz com ferramentas como GPG e Pass é essencial para o DevSecOps. Essas ferramentas atuam desde a solicitação até a criação e a distribuição, garantindo a segurança em todas as etapas.