Como é uma boa segurança da cadeia de suprimentos de software para setores altamente regulamentados

A Segurança da Cadeia de Suprimentos de Software em Ambientes Altamente Regulamentados

Organizações que operam seus negócios com software open source (código aberto) enfrentam um cenário de segurança e compliance (conformidade) mais agressivo e complicado do que nunca. De acordo com o 10º Relatório Anual "State of the Software Supply Chain" da Sonatype, atores maliciosos estão contornando ferramentas de segurança tradicionais ao mirar diretamente nos desenvolvedores. O relatório aponta que o número de pacotes maliciosos registrados em 2024 aumentou 156% ano a ano. Embora os movimentos cloud native e DevOps da última década tenham progredido na promoção da ideia de integrar a segurança em todo o ciclo de desenvolvimento e entrega de aplicativos, as explorações de vulnerabilidades de software estão entre os métodos de ataque externos mais comumente relatados (citados por 29% dos entrevistados), seguidos de perto por violações da cadeia de suprimentos de software (28%). [FONTE: The State Of Application Security, 2025AI Explodes The Attack Surface; Forrester Research; Por Sandy Carielli, Janet Worthington, et al. Maio de 2025]

Diante desse cenário de segurança e compliance cada vez mais complexo, equipes de segurança, líderes de desenvolvimento de aplicativos e executivos de TI estão buscando entender o que constitui uma boa segurança da cadeia de suprimentos de software. Com base em milhares de horas de trabalho com indústrias altamente regulamentadas – desde agências do setor público até organizações globais de serviços financeiros –, identificamos alguns padrões específicos do que caracteriza uma segurança eficaz da cadeia de suprimentos de software.

Imagens Distroless: Elevando Imagens Hardened Além do Básico

Imagens de container hardened (endurecidas/reforçadas) são um padrão nos ambientes de TI atuais. Muitos fornecedores de software prometem imagens hardened e CVEs (Common Vulnerabilities and Exposures) próximas de zero. No entanto, para realmente aproveitar as imagens hardened, as organizações precisam garantir que possuam um "espaço defensável" dentro de sua infraestrutura.

Na Califórnia, propensa a incêndios, a noção de espaço defensável é monitorada pelo Cal Fire. Os proprietários são obrigados a criar 30 metros de espaço defensável ao redor de seus edifícios, removendo materiais que poderiam se transformar em combustível para um incêndio de rápida propagação do perímetro de sua propriedade. Da mesma forma, remover material em excesso de suas imagens de container atinge o mesmo objetivo. Cada linha de código adicional em seu software é uma oportunidade para a introdução de um bug que um hacker pode explorar. Ao remover pacotes e dependências em excesso que não são necessários para executar um aplicativo, há menos chances de "algo dar errado" que um ator mal-intencionado possa usar a seu favor. Catástrofes acontecem quando um número suficiente de coisas falha simultaneamente. Portanto, mesmo que você não consiga eliminar o risco completamente, reduzir os pontos de falha pode melhorar suas chances de resistir a um ataque.

Imagens distroless removem tudo, exceto o que é absolutamente necessário para o software funcionar. Isso não apenas torna a imagem mais leve, ocupando menos espaço em sua máquina, mas também torna seus aplicativos mais seguros ao reduzir os pontos de ataque disponíveis. Para desenvolvedores que precisam da capacidade de adicionar bibliotecas dinamicamente a um runtime de container, as imagens distroless não são a opção certa. O formato distroless brilha quando um aplicativo passou da fase de prova de conceito e a balança de trade-offs se inclina da facilidade de uso para a redução do risco de exploração.

Imagens distroless são essenciais para equipes que estão prontas para segurança de container de ponta em sua infraestrutura. Nem todos conseguirão começar com esse tipo de imagem, mas equipes que já realizam tarefas sofisticadas, como redes air-gapped ou desconectadas, zero-trust ou modelos de autorização de controle de acesso obrigatório, se sentirão à vontade usando imagens distroless. Ao criar um ambiente de "sala limpa" no container, as imagens distroless não são projetadas para humanos trabalharem nelas, pois contêm apenas os bits necessários para os binários de baixo nível do aplicativo. Mas, por não possuírem as partes orientadas ao ser humano do sistema operacional, como shell, gerenciador de pacotes, ferramentas de sistema de arquivos, torna muito mais difícil para um hacker explorar se ele de alguma forma conseguir entrar no container. Além disso, o tamanho da imagem do container é vastamente menor porque podemos eliminar muito peso extra que essas ferramentas exigem. O resultado é um ganho duplo para tornar o container mais seguro, à custa da facilidade de uso quando se trata de depuração e solução de problemas. No entanto, novas ferramentas estão sendo desenvolvidas neste ecossistema para tornar os containers distroless mais fáceis de trabalhar, elevando assim o nível de espaço defensável e segurança proativa para todos na indústria. Certamente, as imagens distroless são menos convenientes, mas mais seguras. É por isso que é melhor torná-las um formato opcional para os aplicativos mais populares. Usuários mais avançados terão apetite por esse nível de segurança e entenderão o trade-off.

Cobertura Abrangente

Um catálogo de imagens construído corretamente com a segurança em mente é ótimo, mas e se o aplicativo ou componente que seus desenvolvedores precisam não estiver nesse catálogo? Se os desenvolvedores frequentemente saem do "jardim murado" de sua cadeia de suprimentos confiável porque não encontram o que procuram, você não pode mais fazer afirmações sobre a conformidade de sua plataforma. E essas exceções podem estar introduzindo riscos que não estão sendo rastreados ou mitigados. É por isso que ter um catálogo com cobertura suficiente dos aplicativos e projetos open source que os usuários da sua plataforma precisam é crucial para uma história de compliance bem-sucedida. Sem isso, a promessa de compliance open source é vazia.

Imagens Otimizadas para Acreditação

A maioria dos requisitos de compliance e controles de frameworks são baseados no NIST 800-53 e no Risk Management Framework (RMF) que implementa e gerencia esses controles. Encontrar um fornecedor que entenda profundamente o cenário de segurança e compliance é fundamental. Além disso, fornecedores que projetam imagens para atender a esses controles "out of the box" (prontas para uso) podem melhorar sua postura de segurança, garantir que você esteja atendendo aos requisitos básicos de compliance e podem reduzir significativamente o trabalho e fornecer modelos para responder aos controles e como as imagens os atendem.

Formato de Pacote OS

Muitas organizações podem precisar customizar as imagens padrão que estão usando para atender às suas necessidades. Ter um formato de pacote padrão da indústria – como RPM – é uma maneira segura de fazer isso. Alguns outros provedores de imagens hardened suportam apenas APK – que não é considerado um padrão da indústria e pode dificultar a localização de pacotes nesse formato. Você obterá um melhor resultado de segurança com tecnologias conhecidas e familiares que são invisíveis para os desenvolvedores, para que eles possam se concentrar no código.

Prontidão para STIG

O Departamento de Defesa dos EUA (DoD) exige que todos os sistemas de TI sigam o Risk Management Framework (RMF), conforme definido no DoDI 8510.01. Uma parte importante do RMF é o uso obrigatório de Security Technical Implementation Guides (STIGs) e Security Requirements Guidelines (SRGs), mantidos pela Defense Information Systems Agency (DISA). Onde um STIG específico para um produto não está disponível, os SRGs relevantes devem ser usados.

Seja você trabalhando com o DoD ou em uma indústria altamente regulamentada, é importante entender esses requisitos, pois eles podem impactar sua postura de compliance. Procure ferramentas e fornecedores que publiquem STIGs e demonstrem experiência em seguir os requisitos de SRG para gerenciamento de riscos. A Prontidão para STIG é o processo de preparar conteúdo que atenda aos padrões da DISA, semelhante ao processo oficial da DISA. Produtos marcados como "STIG Ready" geralmente exigem mínimas alterações se fossem submetidos para publicação oficial da DISA. Ao escolher um fornecedor para melhorar sua postura de segurança e compliance, avalie sua Prontidão para STIG.

FIPS e SLSA

Desenvolvidos pelo National Institute of Standards and Technology (NIST), os Federal Information Processing Standards (FIPS) são usados quando não há padrões ou soluções da indústria aceitáveis para um requisito governamental específico. Embora os FIPS sejam desenvolvidos para uso pelo Governo Federal, muitos no setor privado usam voluntariamente esses padrões para proteger suas informações e sistemas e estabelecer programas robustos de segurança da informação. Para proteger sua cadeia de suprimentos e contra ataques criptográficos, um catálogo curado de software aprovado por FIPS estabelece a base para uma postura de segurança mais forte. Você pode encontrar a lista dos FIPS mais atuais aqui. Recomendamos consultar o FIPS 140-2 e 140-3, que especificam os requisitos criptográficos e operacionais para módulos dentro de sistemas de segurança que protegem informações sensíveis.

O framework Supply-chain Levels for Software Artifacts (SLSA) consiste em um conjunto de diretrizes incrementalmente adotáveis para a segurança da cadeia de suprimentos, estabelecido por consenso da indústria (em oposição a um órgão governamental). Ele é projetado para suportar o rastreamento do tratamento do código, da fonte ao binário, para proteger contra infiltração por atores mal-intencionados em toda a crescente complexidade da cadeia de suprimentos de software. Idealmente, você tem opções para produzir atestações de proveniência para todos os ativos distribuídos, para que possa verificar informações sobre artefatos de software descrevendo onde, quando e como algo foi produzido, que atenda ao SLSA Build Level 3. A tabela abaixo mostra os requisitos necessários para ser compatível com SLSA para o Nível 3 com base nesta especificação.

Suporte para Ambientes Desconectados

Muitas agências federais e organizações altamente regulamentadas exigem o isolamento de sistemas de computador de conexões externas como a internet. Sistemas fisicamente isolados – ou air-gapped – protegem dados altamente sensíveis, garantem a integridade desses dados bloqueando o acesso remoto aos seus sistemas e, em muitos casos, suportam padrões de compliance regulatórios relacionados à proteção de dados e privacidade. Redes desconectadas ou "Air Gap" são uma maneira eficaz de aumentar as defesas de segurança da sua infraestrutura. No entanto, isso tem um custo, especialmente se o software em que você confia foi projetado para estar sempre conectado à internet. É por isso que é importante identificar soluções desde o início do design de seus sistemas que possam suportar bem ambientes desconectados.

Para que uma estratégia de segurança da cadeia de suprimentos seja eficaz, as atualizações do seu software, especialmente aquelas com correções de CVE, precisam atravessar o air gap em tempo hábil. Você deve esperar que seu provedor de soluções ofereça um procedimento bem documentado e ferramentas para mover software da internet para o ambiente desconectado. O perigo é que, se for muito difícil lidar com atualizações de software, os benefícios de uma estratégia de rede desconectada serão atenuados pelo funcionamento prejudicado da sua cadeia de suprimentos. Felizmente, existem ferramentas, como o open source Bitnami charts-syncer, que tornam trivial a sincronização e movimentação de pacotes de charts e imagens de container associadas entre repositórios de charts e ambientes altamente regulamentados.

Documentação de Compliance Automatizada

Grandes corporações e agências federais, conscientes da segurança, estão exigindo que SBOMs (Software Bill of Materials), declarações VEX (Vulnerability Exploitability eXchange) e atestações in-toto sejam incluídas com qualquer software que executam ou distribuem. A capacidade de coletar automaticamente documentos de compliance via APIs – certamente simplifica o processo de auditoria; também pode reduzir o tempo médio de recuperação de uma organização de um potencial ataque à cadeia de suprimentos de software. Aqui está um exemplo de como os SBOMs podem reduzir seu tempo de recuperação de uma interrupção ou ataque. Esse tipo de visão holística é fundamental para apoiar o compliance contínuo.

De Blocos de Construção a Uma Casa Completa!

Em última análise, a segurança da cadeia de suprimentos de software requer múltiplas ferramentas e processos ao longo do ciclo de desenvolvimento e entrega de aplicativos. Não basta mais "shift security left", é preciso "shift security everywhere" (levar a segurança para todos os lados). À medida que vemos os padrões cloud native se consolidarem no território PaaS, faz sentido arquitetar seus sistemas para uma experiência de segurança contínua, onde os resultados são alcançados em todos os sistemas, para que não prejudique sua capacidade de lançar software de alta qualidade mais regularmente, recuperar-se de contratempos e ataques mais rapidamente e tornar os desenvolvedores mais felizes!