Mantendo segredos em um mundo nativo de nuvem devsecops

A adoção do Devsecops está amplamente em andamento, com muitas organizações procurando quebrar silos entre desenvolvimento, segurança e operações, aproveitando arquiteturas nativas da nuvem para gerar resultados de software seguros para as organizações. Dito isso, um problema ainda é difundido em toda essa jornada de devsecops e é o caso do gerenciamento de segredos.

Segredos consistem em informações que as organizações desejam manter em sigilo, principalmente credenciais, chaves de acesso ou certificados de alguma forma. Conforme evidenciado em relatórios anteriores de violação de dados, como os da IBM, credenciais e segredos permanecem entre os principais fatores envolvidos em incidentes e violações de dados, muitas vezes dando aos agentes mal-intencionados acesso inicial ou lateral nos ambientes.

Práticas ruins de gerenciamento de segredos foram vinculadas ou exploradas em várias violações, incluindo Codecov e Twitch. Atividade recente em torno da violação de dados da Samsung que expôs partes do código-fonte da empresa incluiu mais de 6.000 chaves secretas.

O gerenciamento de segredos tem sido um desafio nos últimos anos e o problema parece estar aumentando. Em um relatório recente do State of Secrets Sprawl 2022 do GitGuardian, mais de 6 milhões de segredos foram detectados em varreduras de repositórios públicos do GitHub em 2021, que é o dobro em comparação com 2020.

Alguns dos problemas são que as organizações não têm maturidade em relação ao gerenciamento de segredos, principalmente em ambientes orientados a devsecops nativos da nuvem. Isso inclui lacunas em torno do inventário de segredos, abordagens centralizadas, controle de acesso e preparação para responder a incidentes secretos quando, e não se, ocorrerem.

Outros fatores que agravam o problema da expansão secreta incluem a crescente popularidade de soluções de código aberto e repositórios associados. Código-fonte, imagens e manifestos de infraestrutura como código (IaC) são apenas algumas fontes onde os segredos podem inadvertidamente ou inconscientemente ser confirmados e posteriormente expostos.

O uso generalizado de imagens de contêiner de tecnologias de código aberto e manifestos padronizados de IaC pelas organizações pode economizar muito tempo e acelerar a inovação, mas também pode servir como uma avenida de exposição secreta, principalmente quando comprometida com a comunidade em repositórios públicos.

Os repositórios públicos não são a única fonte de preocupação. À medida que as organizações continuam enfrentando violações de dados que comprometem seus repositórios privados internos ou até mesmo sistemas e pipelines de integração/entrega contínua (CI/CD), os segredos também podem ser expostos a agentes mal-intencionados. As equipes de segurança de aplicativos estão lutando para acompanhar a atividade das equipes de desenvolvimento e outras quando se trata de implementar práticas e maturidade de gerenciamento de segredos.

Práticas recomendadas de gerenciamento de segredos

As organizações precisam amadurecer suas práticas de gerenciamento de segredo. Deixar de fazer isso pode afetar não apenas uma única organização, mas ter um impacto em cascata em toda a cadeia de suprimentos e ecossistema se os segredos expostos pertencerem a um fornecedor de software ou provedor de serviços gerenciados na nuvem.

Parte do desafio são os diversos locais e métodos nos quais os segredos podem ser compartilhados, armazenados ou expostos inadvertidamente. Em ambientes de tecnologia moderna, isso inclui repositórios de código-fonte, pipelines de CI/CD, imagens de contêiner, modelos de IaC e até mesmo uma estação de trabalho local do desenvolvedor. Vamos discutir métodos para mitigar algumas dessas preocupações.

Ferramentas de código aberto e comerciais

Quando se trata de repositórios e pipelines de CI/CD, você tem soluções de fornecedores de código aberto e proprietários para escolher. Algumas das opções de código aberto mais populares incluem Gitleaks e Trufflehog. Ambos podem ajudar a dar suporte à varredura de repositórios Git em busca de segredos armazenados e ser integrados a plataformas de CI populares, como GitHub e GitLab, para capturar segredos que fluem pelo pipeline antes que eles cheguem a um repositório ou, pior, a ambientes de tempo de execução. Eles são capazes de procurar segredos como senhas, chaves de API e tokens de acesso pessoal, todos os quais podem ser abusados por agentes mal-intencionados para impactar não apenas sua organização, mas também quaisquer clientes, parceiros de negócios ou outros com quem você possa interagir de uma perspectiva digital.

Essas soluções de código aberto também suportam o uso de ganchos de pre-commit, que podem ser executados antes de algo realmente ser confirmado, por exemplo. Embora ambas as opções suportem o uso de regras internas, elas também podem criar regras personalizadas de detecção de segredo, que podem ser úteis dependendo do tipo de dados que sua organização pode ser responsável pela proteção.

É importante ajustar essas ferramentas porque, embora sejam extremamente úteis na identificação de possíveis segredos expostos, elas também podem ser muito barulhentas e frustrar a equipe de desenvolvimento enquanto tentam lidar com a enorme quantidade de alertas e descobertas para determinar falsos positivos versus problemas reais.

Líderes emergentes no espaço de fornecedores incluem o GitGuardian, que foi citado anteriormente em alguns de seus estudos associados e descobertas sobre expansão secreta. O GitGuard fornece um mecanismo de política de segurança de código que pode ser integrado a sistemas de controle de versão, ferramentas DevOps e configurações de IaC para evitar que segredos sejam expostos. Eles também monitoram ativamente todos os commits públicos do GitHub e os verificam, que atualmente tem mais de 70 milhões de usuários ativos, embora nem todos estejam usando repositórios públicos. No entanto, a atividade do GitGuardian de fazer esse monitoramento em repositórios públicos ajuda a informar algumas das métricas citadas anteriormente sobre o estado de expansão do segredo e quão grande é o problema.

Educação do desenvolvedor

Outra recomendação é apenas a educação do desenvolvedor da equipe AppSec. Embora as ferramentas possam percorrer um longo caminho e sejam essenciais para garantir que você capture o que puder, começar com o desenvolvedor é um ótimo lugar para iniciar. Educar os desenvolvedores sobre os perigos dos segredos vazados e as ramificações que isso pode ter não apenas na sua organização, mas em outras pessoas associadas a você, seja como clientes ou parceiros, também é fundamental.

Inclua cenários de segredos vazados em seu plano de resposta a incidentes

Como em grande parte da segurança cibernética, não é uma questão de se, mas de quando os segredos são comprometidos. É por isso que seu plano de resposta a incidentes e manuais associados devem abranger cenários de vazamento de segredos. Se os segredos forem expostos, como a organização responderá? Quem está envolvido? Como você invalida esses segredos para minimizar o impacto? Como você se comunica com clientes ou parceiros afetados? Essas são as principais considerações quando se trata do problema da disseminação de segredos e dos incidentes de segurança associados.

Adotar uma abordagem multifacetada conforme discutido acima por meio de ferramentas, processos e pessoas pode ajudar sua organização a mitigar os riscos associados a segredos vazados e as consequências subsequentes. A implementação dos itens discutidos acima será fundamental para desenvolvedores, engenheiros de AppSec e organizações nativas da nuvem para mitigar os riscos associados a segredos. Manter um segredo não é uma questão trivial, principalmente na era da nuvem e dos devsecops.