Muitas palavras foram escritas nos últimos anos sobre o SBOM – Lista de materiais de software. Com toda essa exposição, as pessoas sentem que sabem o que é bom o suficiente para explicar – é uma lista de ingredientes de software, é importante para transparência e segurança e ajuda a expor dependências transitórias. Tudo isso é verdade.
Ainda assim, o SBOM não é tão claro quanto parece. Por um lado, considere que para se manter atualizado cada nova versão ou patch da biblioteca requer o lançamento de um novo SBOM. Freqüentemente, você altera ou corrige apenas uma ou duas bibliotecas por vez, então pode simplesmente quebrar seus novos ingredientes, adicioná-los ao SBOM e deixar todo o resto igual, certo?
E o que dizer do conceito de “conhecido-desconhecido”? Se os desenvolvedores souberem que está faltando algo, eles podem inseri-lo como 'conhecido-desconhecido' e preencher os espaços em branco mais tarde (ou não preencher).
Existem também artefatos de software que são muito complexos e incluem vários elementos interligados, cada um deles um artefato de software por si só. Cada elemento geralmente tem seu próprio SBOM separado, e toda a construção pode ter um SBOM maior e agregado.
Tudo isso mostra que, em vez de um arquivo SBOM simples e claro, você pode acabar com uma série de elementos diferentes e em constante mudança que você deve manter constantemente o mais atualizados possível.
Tudo isso é muito bom, mas que diferença faria para alguém se um SBOM ou parte de um SBOM não fosse tão preciso ou atualizado quanto poderia ser? O que poderíamos fazer para manter a proveniência e a precisão do SBOM?
Neste artigo, examinaremos o uso do SBOM em verificações de vulnerabilidades e divulgação de vulnerabilidades. Falaremos sobre assinatura criptográfica e veremos como assinar um SBOM, ou partes dele, o torna mais útil como ferramenta de segurança e transparência. Também falaremos sobre metadados e por que eles são tão importantes no SBOM e na produção de outros artefatos, especialmente quando assinados criptograficamente em um atestado.
Comece aqui: O que é assinatura criptográfica?
Assinaturas criptográficas são usadas para verificar a integridade e precisão de arquivos ou pastas digitais. Um arquivo assinado não pode ser adulterado sem tornar a assinatura inválida e, portanto, seria imediatamente descoberto quando alguém tentasse verificar o documento assinado.
Isso faz das assinaturas digitais uma ferramenta inestimável no arsenal do segurança de software indústria e já foram encontrados inúmeros usos para o simples conceito de assinatura digital ou criptográfica de ativos digitais.
Como funciona? As assinaturas digitais são baseadas em criptografia assimétrica, onde uma entidade possui duas chaves – uma chave privada e uma chave pública. As duas chaves estão interligadas de tal forma que um documento assinado com a chave privada pode ser verificado através da chave pública. Uma verificação significaria que o documento não foi adulterado de forma alguma (mesmo a alteração de um único bit tornaria a assinatura inverificável) e provaria a identidade do signatário, ou pelo menos a identidade da chave usada.
O que você está fazendo com esse SBOM?
SBOMs não são apenas arquivos longos e complicados contendo informações de componentes de software. Eles são a sua porta de entrada para saber exatamente quais componentes compõem o seu artefato de software. Você precisa conhecer a lista completa de componentes, pois mesmo que você pense que sabe exatamente o que incluiu, é provável que, com cada biblioteca adicionada, você envie inúmeras dependências ocultas e transitórias, cada uma das quais pode ser um portador de uma vulnerabilidade ou exploração que agora está incluído no software que você envia aos seus clientes.
Depois de ter um SBOM e a lista completa de ingredientes, você pode verificar essa lista em bancos de dados de vulnerabilidades conhecidas e ver quais vulnerabilidades estão incluídas em seu software. Mas isso é apenas o começo. Como qualquer pessoa que já executou uma verificação de vulnerabilidades sabe, os resultados até mesmo de uma simples verificação de artefatos podem facilmente chegar a centenas (ou mais) de vulnerabilidades.
É aí que começa o trabalho árduo, mapeando cada vulnerabilidade, verificando se ela pode ser explorável em sua composição específica de software, documentando essas informações e lidando com as vulnerabilidades exploráveis corrigindo-as e corrigindo-as, de preferência na ordem do perigo que representam (ao vivo explorações em estado selvagem são mais perigosas do que uma exploração teórica que nunca aconteceu ainda).
Todo esse trabalho e documentação e correção de vulnerabilidades são importantes para você como produtor de software, mas também são importantes para seus clientes, parceiros e auditores em potencial.
Eles querem saber se você está ciente das vulnerabilidades potenciais e se está por dentro delas, corrigindo e corrigindo falhas, para que elas não os afetem como seus clientes ou parceiros.
Como o momento em que você faz uma verificação é importante nesse sentido devido ao fato de que novas vulnerabilidades estão constantemente surgindo, assinar seu SBOM junto com os metadados de QUANDO ele foi criado é uma ótima maneira de mostrar que você está realmente no topo da sua lista de vulnerabilidades.
Desta forma, você pode provar que sabia antecipadamente sobre uma vulnerabilidade e que ela não é relevante (usando um VEX consultivo), que não está presente em uma determinada versão, ou que nem existia no momento em que você lançou sua última versão.
Onde eu assino?
Agora vamos substituir esse arquivo simples de lista de ingredientes por um dos casos de uso mais complexos descritos no início do artigo. Depois de combinar vários SBOMs para formar uma versão maior e agregada para descrever seu artefato completo, assinar e verificar cada parte individual dessa versão agregada se torna cada vez mais importante. Digamos que você esteja construindo uma nova versão de um artefato de software complexo. Nesta nova versão, a única coisa que mudou foi a parte 1 de um artefato de 3 partes. As outras duas partes permanecem exatamente iguais. Por que você deveria perder tempo e recursos na construção do SBOM completo em três partes, verificando todas as três em busca de vulnerabilidades e mapeando todas as três em busca de explorações relevantes? As únicas alterações foram na parte 3, então essa é a única na qual você deve trabalhar. Se você assinou todos os 3 SBOMs e verificações de vulnerabilidade na última vez em que os criou, poderá incluir as informações das outras duas partes sabendo que isso poderia ' não foram modificados. Você pode então provar a qualquer momento que os SBOMs das partes 3 e 1 são idênticos às versões originais. Você pode, é claro, fazer as verificações novamente se estiver preocupado com novas vulnerabilidades, mas isso depende inteiramente de você e do seu software. análise de risco.
Ser capaz de provar aos seus clientes, parceiros e auditores quando e com que frequência você criou SBOMs e os verificou em busca de vulnerabilidades é útil por vários motivos. Não menos importante, pode ser usado em tribunal para provar que você não é responsável pelos danos de uma exploração, uma vez que você fez tudo o que deveria para ser protegido, ganhando assim um Porto Seguro.
Para onde ir a partir daqui
Como afirmamos anteriormente, um dos problemas com a assinatura digital de artefatos ou arquivos de software é o incômodo de lidar com sistemas de gerenciamento de chaves. Depois de eliminarmos esse incômodo usando algo como o Sigstore para contornar o uso de uma PKI tradicional e tornar o fluxo de assinatura e verificação automático, há realmente poucos motivos para não utilizar essa ferramenta de segurança. Ao considerar que a identidade usada para assinar um arquivo ou artefato também pode ser usada em uma política que verifica a segurança do seu pipeline de CI/CD, você deve ficar ainda mais motivado para começar a assinar quase tudo que estiver à vista.
Assinar arquivos com seus metadados pode ajudar a verificar a hora e o local de sua origem, bem como a persona e o sistema onde foram criados, todas informações relevantes quando consideradas pelas lentes de um especialista em segurança. Ser capaz de dizer que a pessoa, o sistema e o horário correspondem à empresa e ao pipeline onde o software foi criado é uma boa ideia quando uma simples substituição pode apresentar uma falsificação assinada e convincente – até que a persona cantora seja verificada.
Considerando que a ferramenta que eu sugeriria para assinar e verificar evidências é de uso gratuito, você realmente não deve ter desculpa. Confira nosso artigo completo sobre Valint – nossa ferramenta de Integridade de Validação para ver o que mais você pode fazer com ela e começar a assinar seus SBOMs e outras evidências geradas hoje mesmo.
Este conteúdo é oferecido a você pela Scribe Security, um fornecedor líder de soluções de segurança de cadeia de suprimentos de software ponta a ponta – fornecendo segurança de última geração para artefatos de código e processos de desenvolvimento e entrega de código em todas as cadeias de suprimentos de software. Saiba mais.
Artigos Relacionados
