A assinatura de código é o processo criptográfico pelo qual um fornecedor de software anexa uma assinatura digital a um artefato de software, usando uma chave privada cuja chave pública correspondente é certificada por uma autoridade certificadora. A assinatura permite que o consumidor do software verifique que o artefato foi assinado por quem detém a chave privada e que não foi modificado desde a assinatura. A assinatura de código é um controle valioso de integridade da cadeia de suprimentos: impede a adulteração do software em trânsito, garante que os artefatos possam ser atribuídos ao detentor da chave e fornece um mecanismo para detectar corrupção durante a distribuição. Ela não protege contra um cenário em que a chave privada de assinatura é comprometida.
O modelo de ameaça de comprometimento de chaves é a limitação crítica. A assinatura de código impede a adulteração por partes que não têm acesso à chave de assinatura. Ela não oferece nenhuma proteção se o atacante tiver obtido a chave privada, porque uma assinatura feita com uma chave comprometida é criptograficamente indistinguível de uma legítima. Um atacante que rouba a chave privada de assinatura de código de um fornecedor pode assinar qualquer software com essa chave, e qualquer consumidor que confie no certificado aceitará essa assinatura como autêntica. Uma assinatura válida significa que a chave privada assinou o artefato; não significa que o processo de build do fornecedor o produziu.
O problema da revogação de certificados é a lacuna operacional. Quando uma chave de assinatura de código é comprometida, a resposta adequada é revogar o certificado, informando ao ecossistema que as assinaturas produzidas por essa chave após o momento do comprometimento não devem mais ser consideradas confiáveis. Na prática, a revogação de certificados é imperfeita: as listas de revogação (CRLs) e as respostas OCSP têm atrasos de cache, o software que verifica o status de revogação pode não fazê-lo em tempo real e muitos sistemas aceitam assinaturas sem verificar o status de revogação. O intervalo entre o comprometimento da chave e a revogação é um período durante o qual assinaturas maliciosas parecem válidas.
Por que isso importa
Os limites da assinatura de código são importantes para TPRM porque as empresas que exigem a assinatura de código como controle de segurança da cadeia de suprimentos podem ter uma falsa sensação de garantia sobre a autenticidade do software assinado. A empresa que confirma que um fornecedor assina suas versões e verifica as assinaturas antes da implantação implementou um controle valioso, mas não um controle que proteja contra os ataques mais sofisticados à cadeia de suprimentos, que normalmente envolvem o comprometimento de chaves, e não artefatos maliciosos não assinados.
- Assinatura de código aceita como controle completo de autenticidade dos artefatos
- Modelo de ameaça de comprometimento de chaves não considerado: artefatos assinados presumidos autênticos
- Status de revogação do certificado não verificado em tempo real
- Segurança da gestão de chaves do fornecedor não avaliada junto com as práticas de assinatura
- Verificação em log de transparência ausente: assinaturas não verificadas em relação ao log público
Como é uma boa prática
Programas maduros de assinatura de código combinam a verificação de assinaturas com a verificação em log de transparência (especificamente o log de transparência Rekor do Sigstore, que fornece um registro imutável de todos os eventos de assinatura e permite detectar certificados usados fora dos parâmetros esperados) e incluem a avaliação da segurança da gestão de chaves junto com a confirmação das práticas de assinatura.
- Verificação de assinatura para todos os artefatos de software
- Verificação em log de transparência: Sigstore Rekor ou equivalente para auditoria de eventos de assinatura
- Status de revogação do certificado verificado no momento da implantação
- Segurança da gestão de chaves do fornecedor avaliada: como as chaves privadas de assinatura são protegidas
- Política de rotação de chaves de assinatura: com que frequência as chaves são trocadas e como o comprometimento é divulgado
Ferramentas
Transparência: Sigstore Rekor para verificação do log de transparência; cosign para verificação de assinaturas e atestações
O log de transparência Rekor do Sigstore fornece um registro do tipo somente acréscimo de eventos de assinatura, que permite verificar que uma assinatura foi produzida em um momento específico por um certificado válido naquele momento. Para profissionais de TPRM, perguntar se as versões do fornecedor são registradas no Sigstore Rekor é uma questão de garantia de transparência que vai além da simples verificação de assinaturas.
Gestão de chaves: assinatura baseada em HSM, AWS KMS e Azure Key Vault para proteção das chaves de assinatura
A gestão de chaves baseada em módulos de segurança de hardware garante que as chaves privadas de assinatura não possam ser exportadas, oferecendo a proteção de chaves que evita o cenário de comprometimento descrito na abertura. Para profissionais de TPRM, perguntar se as chaves de assinatura de código do fornecedor são armazenadas em HSMs ou em serviços dedicados de gestão de chaves é uma questão de proteção de chaves que trata da limitação central da assinatura de código.
Desafios de governança
O desafio de governança da assinatura de código é o problema do atraso na divulgação. Fornecedores que descobrem que sua chave de assinatura foi comprometida enfrentam uma pressão significativa para adiar a divulgação, pois ela aciona requisitos imediatos de revogação, notificações a clientes e custos de correção potencialmente significativos. A solução de governança é exigir que os fornecedores se comprometam a divulgar imediatamente o comprometimento de chaves de assinatura de código e a fornecer a verificação em log de transparência como prática padrão.
- Exija nos contratos com fornecedores um compromisso de divulgação de comprometimento de chaves
- Avalie a segurança da gestão de chaves do fornecedor: HSM ou equivalente para as chaves de assinatura
- Exija a verificação em log de transparência para versões assinadas
- Verifique o status de revogação do certificado no momento da implantação
- Inclua a política de rotação de chaves na avaliação de segurança de fornecedores
Se você faz parte de uma equipe pequena
Para os seus fornecedores de software que disponibilizam versões assinadas, faça duas perguntas que a verificação de assinaturas, por si só, não responde. Primeira: as chaves privadas de assinatura de código de vocês são armazenadas em HSMs ou em serviços dedicados de gestão de chaves que impedem a exportação da chave? Segunda: as assinaturas das suas versões são registradas no Sigstore Rekor ou em um log de transparência equivalente? A primeira pergunta trata da prevenção do comprometimento de chaves. A segunda trata da detecção do uso de chaves comprometidas, porque uma chave comprometida usada para assinar uma versão maliciosa aparecerá no log de transparência de maneiras que diferem do padrão normal de assinatura do fornecedor.
- Pergunte se as chaves de assinatura são protegidas por HSM
- Pergunte se as versões são registradas no Sigstore Rekor
- Verifique o status de revogação do certificado na implantação
- Inclua a segurança da gestão de chaves na avaliação de fornecedores
O que exigir
Pergunte diretamente:
"As chaves privadas de assinatura de código de vocês são armazenadas em módulos de segurança de hardware que impedem a exportação da chave, e as assinaturas das suas versões são registradas no Sigstore Rekor ou em um log de transparência equivalente que permita detectar um comprometimento?"
O que esperar como evidência
- Confirmação de proteção de chaves por HSM ou equivalente
- Confirmação do uso de log de transparência
- Política de rotação de chaves de assinatura
- Compromisso de divulgação de comprometimento de chaves
Um fornecedor que confirma a assinatura de código deve ser questionado sobre a proteção de chaves e o registro em log de transparência. A verificação da assinatura confirma que a chave assinou o artefato. A proteção da chave impede o comprometimento. O log de transparência detecta o comprometimento. Os três são necessários para uma garantia significativa da assinatura de código.
Como comprovar
- Registros de avaliação da segurança da gestão de chaves
- Implementação da verificação em log de transparência
- Implementação da verificação de revogação de certificados
- Exigência de divulgação de comprometimento de chaves nos contratos com fornecedores
Principal conclusão
Assinatura de código: válida. Certificado: de uma CA reconhecida. Chave de assinatura: comprometida 11 meses antes. Todas as versões desde então: assinadas por quem detinha a chave comprometida. Verificação de assinatura durante todo o período: correta. A assinatura confirmou que a chave privada assinou o artefato. Não confirmou nada sobre se o processo de build do fornecedor produziu o que a chave privada assinou. A assinatura de código impede a adulteração por partes que não têm a chave. Não oferece nenhuma proteção contra partes que têm a chave. Chaves protegidas por HSM impedem a exportação da chave. Os logs de transparência detectam padrões de uso de chaves comprometidas. Ambos são necessários para que a assinatura de código ofereça uma garantia que se estenda ao modelo de ameaça de comprometimento de chaves.