Em abril de 2023, a CISA lançou um novo guia conjunto para segurança de software chamado Mudando o equilíbrio do risco de segurança cibernética: princípios de segurança desde o projeto e padrão. O Guia foi composto com a cooperação de 9 agências diferentes, incluindo a NSA, o Australian Cyber Security Centre (ACSC) e o Federal Office for Information Security (BSI) da Alemanha, entre outros. O facto de várias agências de todo o mundo terem cooperado na preparação de um guia de cibersegurança deve ser um forte testemunho da importância que o tema da cibersegurança tem em todo o mundo neste momento.
Jen Easterly, diretora da CISA, compartilhou suas idéias sobre o tema segurança cibernética em um discurso recente que proferiu aos alunos e professores da Carnegie Mellon University em Pittsburgh. De acordo com o diretor da CISA, estes princípios orientadores deverão ajudar a orientar a indústria global de software nos próximos anos:
- O fardo da segurança nunca deve recair apenas sobre o cliente. Os fabricantes de software devem assumir a responsabilidade pelos seus produtos e códigos.
- Os fabricantes de tecnologia devem abraçar a transparência radical como um compromisso de responsabilização pelos seus produtos.
- Os fabricantes de tecnologia devem concentrar-se na construção de produtos seguros, desenvolvendo produtos que sejam seguros desde a concepção e seguros por defeito.
O guia CISA adota esses princípios básicos e os expande, incluindo uma lista abrangente de sugestões práticas que os fabricantes de software podem adotar para trazer produtos mais seguros ao mercado.
É interessante notar que muitas das sugestões explícitas são baseadas em Estrutura SSDF do NIST mas formulado de uma forma mais prática e menos voluntária.
Uma das sugestões do guia, que se relaciona diretamente com a transparência radical, é que os fabricantes de software incluam a produção de um SBOM em seu SDLC para fornecer visibilidade dos componentes de seu software.
Mas será que criar um SBOM e até mesmo publicá-lo é realmente suficiente? O que um produtor ou consumidor de software pode realmente fazer com um arquivo SBOM JSON ou XML?
Neste artigo, veremos os usos que um SBOM pode trazer para um produtor de software hoje, as informações que podem ser adicionadas a um SBOM para enriquecê-lo e a inteligência de negócios que pode ser obtida ao examinar esses documentos enriquecidos. Analisaremos rapidamente o lado da conformidade do uso de um SBOM e onde reside sua responsabilidade como produtor de software, agregador de software ou mantenedor de código aberto. Encerraremos falando sobre gerenciamento de riscos e como os princípios de segurança desde o design e segurança por padrão da CISA se combinam com a conformidade regulatória de segurança cibernética e o gerenciamento de riscos esclarecido.
Nem todos os SBOMs foram criados iguais
Existem muitas ferramentas disponíveis hoje para a criação de SBOMs, desde soluções de código aberto até soluções proprietárias. Uma pessoa ou empresa que deseje incluir a criação de SBOM em seu SOP poderia facilmente fazê-lo. Podia-se escolher entre os diferentes padrões aquele mais adequado às suas necessidades, mas mesmo assim você pode enfrentar muitas ferramentas para tomar uma decisão informada. Então, o que mais você poderia procurar ao decidir sobre o produto certo Geração SBOM ferramenta para você?
Primeiramente, verifique quais informações são incluídas ou omitidas na criação do SBOM. Uma lista de materiais que inclua ferramentas e códigos que fazem parte do processo de desenvolvimento, mas não fazem parte do produto real, provavelmente conteria muitas informações redundantes que são muito difíceis de 'limpar' do arquivo resultante para permitir que você mantenha apenas as informações mais relevantes. Da mesma forma, ferramentas ou códigos que não sejam incluídos ou omitidos propositalmente estariam visivelmente ausentes quando você deseja verificar vulnerabilidades, por exemplo.
A lista de ingredientes e dependências de software, por si só, não tem sentido. Serve muito pouco propósito além do que você pode escolher fazer com ele. O uso mais comum de SBOMs hoje é verificar os componentes de software para obter uma lista de vulnerabilidades que podem afetar seu produto.
É importante lembrar que cerca de 95% das vulnerabilidades descobertas não podem ser exploradas em seu produto. O truque é encontrar esses 5% indescritíveis, fazer um plano de trabalho e começar a lidar com essas vulnerabilidades exploráveis. Como saber o que é explorável e o que não é? Essa é a grande questão que mantém o pessoal de segurança e engenharia acordado à noite. Uma sugestão atual é empregar uma solução chamada VEX – um Vulnerability Exploitability eXchange, uma forma de aconselhamento de segurança onde o objetivo é comunicar a explorabilidade de componentes com vulnerabilidades conhecidas no contexto do produto em que são usados. Ainda deixa muito trabalho de vasculhar o palheiro de informações sobre vulnerabilidades e encontrar a agulha das vulnerabilidades exploráveis, principalmente para a equipe de engenharia. Afinal, quem conheceria seu produto melhor do que as pessoas que o codificaram?
Porém, há outras coisas que você pode fazer, especialmente quando se trata de vulnerabilidades herdadas que vêm de imagens pai de sua imagem do Docker ou de dependências anteriores em sua cadeia de dependências. Usando ferramentas de código aberto como imagem pai você pode descobrir quais vulnerabilidades vieram com a imagem pai e quais foram resultado direto do seu código. Isso deve eliminar um conjunto potencialmente grande de vulnerabilidades e facilitar o trabalho de triagem. Usar vários avisos sobre diferentes vulnerabilidades também é uma boa ideia, pois depois de determinar que uma vulnerabilidade não pode ser explorada, faz sentido informar outras pessoas da sua equipe ou usuários para que você não fique verificando a mesma vulnerabilidade em todas as versões. do seu produto onde você nem mesmo modificou o módulo onde ele foi encontrado. Também é aconselhável seguir suas dependências de código aberto e de terceiros para que, uma vez que encontrem e corrijam vulnerabilidades exploráveis, você possa atualizar esse código em seu produto para fazer certifique-se de que você também está protegido contra esse problema potencial específico.
O que mais você pode adicionar em um SBOM?
Conforme afirmado acima, um dos usos mais comuns dos SBOMs hoje é como uma lista de verificação para verificação de vulnerabilidades. Usando vários bancos de dados disponíveis gratuitamente, como o NVD (National Vulnerability Database), você pode verificar uma lista de componentes, semelhante àquela fornecida por um SBOM, e ver quais vulnerabilidades ela contém. Depois de ter uma lista de vulnerabilidades, você pode ordená-la por gravidade, verificar se alguma possui correções existentes e assim por diante.
Outra camada de informação útil sobre seus componentes é a licença. Muitos componentes de código aberto vêm com uma licença que não é compatível com uso comercial. É importante ter certeza de que todos os seus componentes de código aberto, mesmo aqueles que você não incluiu, mas foram incluídos por algum outro componente, sejam compatíveis com tudo o que você está tentando fazer em termos de licença.
Uma sugestão final é seguir medidores de 'saúde' de segurança de código aberto para suas dependências, como o Pontuação do OpenSSF. Ter uma medida objetiva relativamente simples para a saúde da segurança cibernética das bibliotecas de código aberto pode ser uma grande ajuda para decidir quais bibliotecas incluir ou omitir em seu produto. Essas pontuações combinadas com a gravidade das vulnerabilidades são uma boa maneira de ajudar a ordenar as vulnerabilidades nas quais você deseja trabalhar primeiro.
Gestão de Riscos como Exercício de Business Intelligence
Existe vários riscos de segurança para qualquer produtor de software lidar hoje em dia. Entre malware, mineradores de criptografia, ladrões de senhas e ransomware, é de admirar que os fabricantes se sintam seguros para lançar qualquer coisa no mercado. Ninguém consegue lidar com tudo de uma vez, por isso as empresas criam modelos de ameaças e tentam gerir os seus riscos de acordo com o que consideram ser os seus elos mais fracos. A primeira etapa mais fácil é garantir que seu código e processo de desenvolvimento estejam em conformidade com quaisquer regulamentos e práticas recomendadas relevantes. SSDF de Nist e OpenSSF SLSA são um bom ponto de partida, bem como os requisitos dos EUA para coisas como um SBOM. Seguir os regulamentos e as melhores práticas poderia pelo menos prometer relativa segurança contra litígios sob o Porto Seguro programa. Mas isso é apenas o começo.
O guia CISA incentiva os fabricantes a abordarem a construção de seus produtos tendo a segurança em mente primeiro. Alguma segurança “agregada” após a conclusão do produto não pode mitigar algumas fraquezas fundamentais que fazem parte da arquitetura do produto. De acordo com o guia, os produtos Secure-by-Design são aqueles em que a segurança dos clientes é um objetivo central do negócio, e não apenas um recurso técnico. Os fabricantes também são incentivados a adotar transparência radical e responsabilidade. Isso significa, entre outras coisas, garantir que os avisos de vulnerabilidade e a vulnerabilidade e exposição comuns associadas (CVE) os registros são completos e precisos. Isso também significa que os componentes do código, suas dependências e vulnerabilidades são incentivados a serem compartilhados como forma de mostrar aos usuários e clientes que o fabricante está pelo menos ciente dos possíveis problemas no produto.
Segundo a Wikipedia, Inteligência de negócios (BI) compreende as estratégias e tecnologias utilizadas pelas empresas para o análise de dados e gerenciamento de informações comerciais. Como você pode imaginar, coletar um SBOM para cada compilação, bem como o relatório de vulnerabilidade, as informações de licença e os avisos que detalham quais vulnerabilidades são ou não exploráveis – isso é muita informação. O número de pontos de informação aumenta quando você leva em consideração a vida útil de um produto de software típico e o fato de que deseja ter essas informações para qualquer código ou ferramenta de terceiros que esteja usando, bem como para pacotes de código aberto que estiver incluindo, direta ou transitoriamente. Para entender tudo isso de uma forma que seja utilizável pelos poderes de segurança da organização (provavelmente o CISO e as pessoas abaixo deles), você precisa de um sistema, uma plataforma única de 'painel de vidro' que permite organizar toda essa informação, pesquisá-la de forma eficaz e apresentá-la em relatórios úteis quando necessário. Para dar apenas um exemplo de quão crítica uma plataforma de BI pode ser para uma plataforma de segurança cibernética, imagine o Log4J drama do ano passado. Não seria incrível pesquisar todos os seus produtos, incluindo dependências e ferramentas de terceiros, pressionando apenas algumas teclas para detectar essa 'nova' ameaça? Que tal verificar a presença de um novo CVE ameaçador que acabou de ser lançado? Ou preparar um relatório sobre como o número geral de vulnerabilidades da sua empresa está diminuindo progressivamente ao longo do tempo (ou pelo menos não aumentando). Esse é o tipo de informação útil que apenas um sistema de BI baseado em uma plataforma de coleta enriquecida com SBOM de segurança cibernética pode oferecer.
Somente depois de ter todas as informações relevantes você poderá realmente avaliar seu risco, tanto em seu código atual, em suas dependências, quanto na escolha de incluir ou omitir alguma ferramenta ou código de terceiros em seu produto. Quando executada continuamente, você também pode usar essa avaliação de risco para proteger compilações e interromper sua produção ou entrega se alguma atividade suspeita for descoberta.
Olhando para o futuro
A tecnologia continua avançando o tempo todo. Se antes os projetos de código monolítico instalados em servidores localizados no escritório da organização eram a norma, hoje em dia é a arquitetura de microsserviços multinuvem e os LLMs que lideram o caminho. Os SBOMs precisam continuar avançando para serem capazes de suportar qualquer arquitetura complexa ou infraestrutura que o software utilize para manter sua relevância e utilidade. O CycloneDX da OWASP, por exemplo, já está trabalhando para incluir Transparência de ML em seu formato SBOM. O mesmo formato também inclui recursos VEX e uma API de compartilhamento SBOM ao planejar o futuro. Prevejo que cada vez mais plataformas como a criada por Escriba serão criados para a acumulação e partilha de informações relacionadas com a segurança, incluindo SBOMs, tanto por razões regulamentares como pelo benefício e valor que tais informações enriquecidas representam para as organizações que as utilizam adequadamente.
A plataforma Scribe está prestes a lançar uma nova ferramenta de BI como parte da plataforma de segurança existente com todos os recursos que sugeri e muito mais. Eu encorajo você a De uma chance, veja a utilidade dessas informações acumuladas ao longo do tempo e veja para que você pode usar as informações. Independentemente de você optar por incorporar a plataforma Scribe em seu SDLC ou não, a corrida por um ecossistema mais seguro e um SBOM mais abrangente e útil está longe de terminar. É melhor entrar no vagão da transparência agora, em vez de ter uma transparência radical imposta pela regulamentação ou pela pressão do mercado.
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
