Antônio Carlos, da GlobalSign, explica como Code Signing, PKI, HSM e Zero Trust fortalecem segurança da cadeia de suprimentos de software e reduzem riscos de ataques
Os ataques à cadeia de suprimentos de software se tornaram uma das principais preocupações das organizações, impulsionados pela crescente adoção de componentes open source, pipelines automatizados, containers e inteligência artificial no desenvolvimento de aplicações. Nesse cenário, proteger apenas as chaves de assinatura já não é suficiente: é preciso assegurar a identidade de pessoas, máquinas e processos ao longo de todo o ciclo de desenvolvimento.
Nesta entrevista exclusiva ao Crypto ID, Antônio Carlos Gomez Gutierrez, Engenheiro de Soluções para América Latina da GMO GlobalSign, detalha o papel do Code Signing, da Infraestrutura de Chaves Públicas (PKI), dos HSMs e das práticas de Zero Trust na construção de uma arquitetura capaz de garantir autenticidade, integridade e rastreabilidade do software. Ao longo da conversa, o especialista explica onde começam e terminam as responsabilidades dessas tecnologias e quais controles são indispensáveis para fortalecer a segurança da cadeia de suprimentos.
Leia entrevista completa!
Crypto ID: Onde está hoje o elo mais vulnerável da cadeia de suprimentos de software? Quando falamos em supply chain attack, estamos colocando sob o mesmo conceito comprometimento de bibliotecas open source, roubo de credenciais, invasão de repositórios, adulteração do pipeline de CI/CD e comprometimento de chaves de assinatura. Na experiência da GlobalSign, quais desses pontos representam hoje os maiores riscos e como uma empresa deveria mapear sua cadeia de confiança antes mesmo de escolher as ferramentas de proteção?
Antônio Carlos: Os maiores riscos estão na obtenção de software e updates em canais não oficiais, como um link enviado por um colega. Esse é o último elo do ataque e todos os outros dependem dele. Mas isso não impede totalmente, pois canais oficiais também podem distribuir software adulterado. Então é importante que as empresas tenham processos de gestão dos softwares utilizados, como por exemplo repositório único, controle de atualizações e gestão de “SBOM“, que é a lista de componentes e bibliotecas assinada digitalmente pelo fornecedor do software. Essa lista traz mais segurança e, em caso de ataque, permite saber o tamanho da exposição.
Crypto ID: Uma chave privada protegida em HSM garante que apenas software legítimo será assinado? Esse é um ponto que gostaríamos de explorar bastante. Um invasor não precisa necessariamente roubar a chave privada se conseguir comprometer o pipeline e fazer com que uma chave legítima assine um artefato malicioso. Como impedir isso? Que controles precisam existir sobre quem pode solicitar uma assinatura, qual identidade está fazendo a solicitação, qual artefato pode ser assinado, em que ambiente e mediante quais condições? Onde termina a proteção fornecida pelo HSM e começa a segurança do processo de assinatura?
Antônio Carlos: Não, não impede. HSM’s são bastante seguros e o roubo da chave privada certamente não é o caminho mais fácil. Ataques recentes têm mostrado que o pipeline de desenvolvimento é um caminho bem mais exposto e vulnerável. Pense em desenvolvedores trabalhando remotamente e agentes de IA acelerando o desenvolvimento, tudo isso favorece o ataque a uma biblioteca ou componente de software. Por isso é fundamental a supervisão humana, desabilitar scripts automáticos e o controle de versões por hash, que é a impressão digital de um arquivo, para que somente código verificado e aprovado seja compilado e posteriormente assinado. Isso é parte do princípio “Zero Trust” aplicado ao desenvolvimento. O mesmo princípio deve ser aplicado aos contêineres e componentes virtuais. Em outras palavras, o HSM garante a segurança da chave criptográfica. A garantia de que apenas software legítimo será assinado depende dos controles de governança, identidade e integridade implementados em todo o processo de desenvolvimento e entrega de software.
Crypto ID: Quem são as identidades dentro de um pipeline moderno de CI/CD? A assinatura já não é necessariamente solicitada por um desenvolvedor diante de um computador. Temos runners, workloads, containers, serviços automatizados e pipelines executando ações sem intervenção humana. Como essas identidades não humanas devem ser autenticadas e autorizadas a utilizar uma chave de Code Signing? É recomendável trabalhar com credenciais de curta duração, menor privilégio e segregação de funções? Como garantir uma trilha que permita comprovar posteriormente qual identidade solicitou determinada assinatura, em qual build e sobre qual artefato?
Antônio Carlos: O Code Signing garante a autoria do software perante o mercado, não identificando os desenvolvedores. Decidir quem pode assinar é prerrogativa da governança da empresa e aqui estamos falando de gestão de credenciais, atribuição de privilégios, segregação de funções e etc. O ponto mais importante é manter uma trilha de auditoria completa, registrando qual identidade solicitou a assinatura, qual pipeline e build estavam em execução, qual artefato foi assinado, quando a operação ocorreu e qual hash do artefato foi aprovado para assinatura.
O controle do hash é fundamental, pois qualquer alteração no artefato gera um hash diferente. Isso nos dá a certeza de que o software assinado é exatamente o software que foi validado e aprovado durante o processo de desenvolvimento.
Crypto ID: Como deveria funcionar uma arquitetura segura de Code Signing em uma empresa com muitos desenvolvedores e pipelines? A chave deve ficar centralizada em um HSM e ser acessada remotamente? Diferentes equipes devem possuir chaves ou certificados distintos? É possível estabelecer dupla autorização ou políticas específicas para códigos mais sensíveis? Gostaríamos que a Luiza descrevesse uma arquitetura concreta, desde a geração do artefato pelo pipeline até sua assinatura e publicação, mostrando onde entram PKI, HSM, autenticação, autorização, logs e auditoria.
Antônio Carlos: O HSM vai permitir que equipes geograficamente dispersas possam assinar sua produção. No geral empresas possuem apenas um certificado e os desenvolvedores não acessam a chave, a assinatura é feita mediante solicitação. Durante o desenvolvimento, a assinatura, por conter um carimbo do tempo, prova o estado do software naquela data e hora. Um fluxo típico consiste em: geração do artefato pelo pipeline, execução dos testes e verificações de segurança, aprovação para assinatura, envio do hash para o serviço de assinatura conectado ao HSM, geração da assinatura com carimbo do tempo, registro de eventos de auditoria e publicação do artefato. Logs contendo a identidade solicitante, pipeline, build, artefato, hash, certificado utilizado, horário da assinatura e resultado da operação, são gerados para rastreabilidade e auditoria.
Crypto ID: O que acontece depois que uma chave de assinatura é comprometida? Como funciona uma resposta desse tipo na prática? Gostaríamos de entender a sequência: revogação do certificado, rotação ou geração de novas chaves, investigação das assinaturas realizadas e identificação dos softwares que precisam ser substituídos ou redistribuídos. E onde entra o carimbo do tempo? Como distinguir um software legitimamente assinado antes do comprometimento de um artefato malicioso que eventualmente tenha sido assinado com a mesma credencial?
Antônio Carlos: Na prática, o proprietário da chave entra na plataforma da CA e revoga aquele certificado colocando “keyCompromise” como motivo da revogação. As assinaturas realizadas antes da revogação podem ser recusadas conforme a política do verificador, ainda que o carimbo do tempo assegure uma data de assinatura anterior ao cancelamento. Serão inválidas as assinaturas posteriores à data da revogação. Softwares maliciosos assinados são indistinguíveis de softwares legítimos assinados, por isso a importância da aplicação de políticas de segurança e das restrições impostas, como a impossibilidade de exportação da chave. Uma investigação de todas as assinaturas realizadas com a credencial comprometida deve se seguir ao ocorrido, identificando quais artefatos foram assinados, quando a assinatura ocorreu e se existe indício de uso não autorizado da chave. Novos artefatos devem ser assinados com um novo certificado.
Crypto ID: Como proteger containers, bibliotecas e componentes open source, e não apenas executáveis tradicionais? A cadeia moderna é composta por imagens de containers, pacotes, dependências, bibliotecas, firmware e inúmeros artefatos intermediários. Como Code Signing e PKI estão evoluindo para esse cenário? A assinatura deve ocorrer apenas no software final ou também ao longo das diferentes etapas do pipeline? E como informações de proveniência e SBOM podem ser associadas à assinatura para permitir que uma empresa saiba quem produziu um componente, de onde ele veio, por quais etapas passou e se foi alterado antes de chegar à produção?
Antônio Carlos: Uma boa prática de distribuição de software é apresentar a “SBOM” ou Software Bill of Materials. Essa lista de componentes contém os nomes e os respectivos hashes desses arquivos. Essa lista é assinada e tem o carimbo de tempo, que permite ao usuário rastrear os componentes em caso de violação e tenha certeza da integridade dos mesmos Além disso, containers, bibliotecas e demais artefatos também devem ser assinados digitalmente para que se possa verificar tanto a procedência quanto a integridade dos componentes. A combinação de assinaturas digitais, hashes e SBOMs oferece mais segurança para a cadeia de suprimentos de software.
A assinatura ocorre ao final desse processo, pois tem a função de identificar o fabricante do software perante o mercado. A gestão da segurança da cadeia é algo mais ligado à governança. É claro que uma infraestrutura de PKI pode e deve ser usada na autenticação, identificação, entre outros. Isso não é feito com o CodeSigning, mas com certificados que identificam e autenticam máquinas e pessoas. Uma SBOM assinada e com carimbo do tempo garante a integridade do software desde a fábrica.
Crypto ID: Onde Zero Trust e PKI se encontram na proteção da cadeia de suprimentos? Se o princípio é não confiar automaticamente nem mesmo em uma identidade já autenticada, como aplicar Zero Trust ao desenvolvimento de software? É possível estabelecer autenticação mútua entre workloads, pipelines, repositórios e serviços por meio de certificados, limitar quais máquinas podem se comunicar e condicionar a assinatura a uma identidade e a um contexto específicos? Como uma empresa evita transformar simplesmente um certificado válido em uma autorização ampla demais?
Antônio Carlos: O princípio Zero Trust está baseado em não confiar de antemão, em que é necessário sempre exigir autenticação e identidade a cada movimento. Uma PKI oferece meios eficazes de prover isso com uma ótima relação custo-benefício. Assim, cada etapa da cadeia passa a depender de evidências criptográficas de identidade e integridade, reduzindo o risco de adulterações.
Todo esse controle de acesso pode ser implementado à partir de uma PKI. Identificar máquinas, usuários, assinaturas e autenticação mútua. O certificado pode entrar como parte da identificação, como por exemplo um segundo fator de autenticação que vai depender da senha para desempenhar seu papel complementar.
Crypto ID: Para uma empresa que queira proteger sua cadeia de software hoje, o que precisa efetivamente implementar? Gostaríamos de terminar trazendo o tema para quem está contratando a tecnologia. Uma empresa possui equipes internas e fornecedores desenvolvendo software, utiliza componentes open source, pipelines automatizados, containers e distribuição contínua. Que arquitetura vocês recomendariam? Quais componentes dependem de PKI e Code Signing, onde entram HSMs e gestão de identidades e quais controles precisam vir de outras camadas de DevSecOps? E, dentro dessa arquitetura, o que a GlobalSign efetivamente entrega e o que necessariamente precisa ser integrado a soluções de outros fornecedores?
Antônio Carlos: Essa pergunta nos obriga a separar o que é responsabilidade de PKI e CodeSigning do que é responsabilidade de DevSecOps, IAM, CI/CD e governança. Nenhuma tecnologia isolada vai dar conta de proteger toda a cadeia de software. A arquitetura deve combinar controles de identidade, proteção de chaves, validação de código, rastreabilidade e verificação de integridade em todas as etapas. PKI e CodeSigning vão estabelecer identidade, autenticidade e integridade. Desenvolvedores, pipelines, workloads e serviços devem possuir identidades verificáveis, enquanto artefatos, containers, bibliotecas, SBOMs e releases devem ser assinados digitalmente para que sua origem e integridade possam ser verificadas.
As chaves privadas utilizadas para assinatura devem permanecer protegidas em HSMs ou serviços equivalentes, onde também são aplicadas políticas de autorização, segregação de funções, auditoria e rastreabilidade das operações de assinatura. Além disso, são necessários controles complementares de DevSecOps, como revisão de código, análise estática e dinâmica, gestão de vulnerabilidades, validação de dependências open source, proteção dos pipelines CI/CD, gestão de identidades e acessos, monitoramento contínuo e resposta a incidentes.
Dentro dessa arquitetura, soluções como as da GlobalSign entregam os componentes de PKI, certificados digitais, serviços de assinatura, proteção de chaves e integração com HSMs e workflows de assinatura. Já funções como gestão de código-fonte, segurança de pipelines, análise de vulnerabilidades, proteção de containers, SIEM, EDR e governança DevSecOps normalmente dependem de outras soluções. Ou seja, PKI e CodeSigning resolvem o problema de identidade, autenticidade e integridade dos artefatos. Já a proteção completa da cadeia de suprimentos exige uma arquitetura mais ampla, com controles, gestão de acessos, observabilidade, governança, entre outras.
ID Talk | Incidente Hugging Face: como conter um ataque autônomo de IA
ID Talk | Henrique Fabretti, do Opice Blum, destaca os desafios da confiança no ambiente digital
ID Talk são entrevistas que geram insights poderosos e soluções práticas para você tomar decisões estratégicas e liderar o futuro. Assistindo ou lendo você descobre o que há de mais inovador em tecnologia. Você vai gostar muito!
