״Os fornecedores de software devem ser responsabilizados quando não cumprem o dever de cuidado que devem aos consumidores, empresas ou fornecedores de infraestrutura crítica ״ (a Casa Branca).
Hoje, espera-se que qualquer fornecedor de software assuma maior responsabilidade por garantir a integridade e a segurança do software por meio de acordos contratuais, lançamentos e atualizações de software, notificações e mitigação de vulnerabilidades. Recentemente, o ESF (Enduring Security Framework), um grupo de trabalho intersetorial, emitiu orientações que incluem melhores práticas e padrões recomendados para ajudar os clientes na implementação de medidas de segurança na cadeia de fornecimento de software. Neste artigo, aprofundarei a recomendação prática de utilizar a pontuação de risco baseada no SBOM como um mecanismo eficaz para triagem e priorização.
Persistem métodos comuns de comprometer as cadeias de fornecimento de software, incluindo a exploração de falhas de design de software, a incorporação de componentes vulneráveis de terceiros em um produto de software, a infiltração de código malicioso na rede do fornecedor antes da entrega final do produto de software e a injeção de software malicioso no software implantado. no ambiente do cliente.
Uma lista de materiais de software (SBOM) emergiu como um elemento crucial na segurança de software e na gestão de riscos da cadeia de fornecimento de software. Um SBOM serve como um inventário aninhado, fornecendo uma lista de ingredientes que constituem os componentes de software.
A operacionalização de SBOMs em escala requer automação e padronização de ferramentas em implantações de sistemas, desenvolvimento de produtos e troca de dados entre fornecedores de software e consumidores.
Existem alguns importantes legíveis por máquina Formatos padrão SBOM apoiado pela indústria. CycloneDX e SPDX definem a forma como os SBOMs são criados, analisados e compartilhados. VEX é uma forma complementar de aviso de segurança que indica se um produto ou produtos são afetados por uma vulnerabilidade ou vulnerabilidades conhecidas. Assim, oferece o benefício de mostrar que um produto não é afetado por uma vulnerabilidade específica, mesmo que essa vulnerabilidade exista no seu SBOM.
A correlação do conteúdo SBOM entre produtos de software implantados na empresa pode fornecer insights poderosos para as equipes de segurança de aplicativos, resposta a incidentes e análise forense, gerenciamento de riscos e compras. Espera-se que as organizações gerem e gerenciem uma grande quantidade de dados SBOM para produtos internos, bem como consumam dados externos que precisam ser gerenciados de maneira eficaz. Portanto, há necessidade de apoiar processo automação do SBOMgerenciamento de risco orientado em escala.
Usando SBOMs e pontuação de risco
A pontuação de risco pode servir como um meio de gerar uma visão geral condensada derivada do conteúdo do SBOM, permitindo comparações rápidas com fontes de dados externas e facilitando a tomada rápida de decisões com base nos SBOMs recebidos e na priorização.
- O SBOM aumenta a transparência, melhorando assim o gerenciamento de ativos de software, o gerenciamento de patches, a identificação de lacunas técnicas de dívidas e o gerenciamento de vulnerabilidades para organizações clientes. Também tem o potencial de extrair a proveniência dos componentes para validar a integridade e a confiança.
- A análise do alinhamento do conteúdo SBOM em produtos de software implementados na empresa produz insights valiosos para equipes de resposta a incidentes, gerenciamento de riscos e validação de processos de aquisição.
Transformando SBOM em informações de risco em escala – justificativa para pontuação de risco
Um desafio importante para todo profissional de AppSec e CISO é gerenciar a fadiga de alertas em seus produtos e serviços. Incluindo a avaliação de riscos externos provenientes de componentes de software de terceiros.
As principais barreiras à implementação são o suporte contratual ou baseado em licença desatualizado que pode impactar a disponibilidade de patches downstream e atualizações de produtos e o crescimento exponencial na complexidade das dependências em produtos de software, sejam eles de código aberto ou fechado.
A pontuação de risco é uma métrica usada para prever aspectos do software e do risco atual e futuro de seus componentes que pode efetivamente apoiar a priorização em escala.
Pontuação de Risco = probabilidade x Impacto
A pontuação de risco permite que as organizações entendam o risco da cadeia de fornecimento de software com base em fatores de risco definidos e antecipem o risco futuro potencial de um determinado produto de software na empresa.
Uma pontuação de risco eficaz poderia estar numa escala de 1 a 10 (como CVSS e Scorecard), para que possamos alinhar cada componente de risco à escala de 1 a 10 para facilitar a referência.
Uma pontuação de risco agregada: Em muitos sistemas complexos e sistemas de sistemas, pode haver vários SBOMs como parte da solução coletiva e, portanto, uma coleção de Pontuações de Risco.
Componentes de pontuação de risco:
1.Vulnerabilidades: Mapeando vulnerabilidades conhecidas usando enumeração CVE e Pontuação CVSS de feeds disponíveis, como NVD, OSV e Github Advisories.
2. Contexto dos fornecedores: Contexto VEX e consultivo de fornecedores que podem alterar a decisão de pontuação de vulnerabilidade no contexto de uso. Vincular SBOMs a vulnerabilidades permite sinalizadores de risco, enquanto documentos VEX permitem que um consumidor priorize vulnerabilidades.
3. EPSS 3.0: Métrica de explorabilidade da FIRST, que prevê a probabilidade (entre 0 a 1.0) de exploração nos próximos 30 dias. Este é um método eficaz camada de probabilidade adicional à pontuação CVSS que pode ajudar a priorizar os CVEs mais importantes a serem tratados primeiro.
4. KEV: A CISA também criou um feed de inteligência sobre ameaças disponível publicamente, conhecido hoje como Catálogo CISA KEV (vulnerabilidades exploráveis conhecidas). Este catálogo contém cerca de 5% de todos os CVEs identificados que foram confirmados pela CISA como tendo sido ou ativamente explorados. Portanto, este é um bom ponto de partida para priorizar vulnerabilidades de alto impacto a serem abordadas. Além disso, isso faz parte da lista de verificação que você validaria antes da aprovação final do lançamento da nova versão.
5. Inteligência de ameaças – Adicionar adicional fontes de ameaças e vulnerabilidades alimentam pacotes maliciosos conhecidos (Exemplos: feeds privados de Snyk, Sonatype, Graynoise, etc.)
6. Reputação OSS: A O scorecard SSF aberto avalia de forma independente as métricas de medidas de desempenho que afetam diferentes partes da cadeia de fornecimento de software, incluindo código-fonte, construção, dependências, testes e reputação de manutenção de projetos de código aberto (classificação de 1 a 10).
7. Desempenho ao longo do tempo: Vulnerabilidades críticas MTTR (Mean Time To Repair) de uma versão de produto/pacote podem fornecer uma métrica relevante de desempenho de risco de segurança.
8. Impacto e contexto. Neste aspecto, a priorização baseada no contexto de negócios do produto de software ajudaria a priorizar e fazer a triagem da floresta de vulnerabilidades.
Alguns exemplos são
- Criticidade do módulo/produto: é de missão crítica (sensibilidade ou criticidade)
- Em quantos produtos tenho a vulnerabilidade específica?
- Exposição externa de um serviço/componente
9. Exposição de conformidade – Licenças: As licenças de software proprietário e de código aberto são importantes para validar a conformidade com a política legal da organização.
Conceito de camadas de pontuação de risco – Adicionando métricas de risco aos SBOMs:
- Início com enumeração CVE e pontuação CVSS com base nos dados SBOM.
- Consumir e adicionar contexto VEX para priorizar novamente a criticidade
- Avalie CVEs com uma pontuação EPSS alta (ou seja, 0.6-1.0)
- Priorizar lista KEV – para endereço primeiro.
- Avalie pela pontuação de reputação do OpenSSF (1-10) – identifique dependências arriscadas.
- Análise exposição para a rede externa (usando vetor CVSS)
- Avaliar o risco acumulado pelo quantidade de contagem de produtos por vulnerabilidade.
- Avaliar pelo rótulo da criticidade do contêiner SBOM específico para o negócio.
- Identifique violação de conformidade riscos no uso da análise de dependências SBOM de acordo com a política de licença da empresa.
- Compartilhar e gerenciar os dados as atestados em uma plataforma colaborativa com fluxos de trabalho para outros sistemas como Jira e outros através de API e legível por máquina.
Aproveitando SBOMs com pontuação de risco para casos de uso prático:
- Triagem contínua de vulnerabilidades para produtos usando métricas de risco para priorizar um plano de trabalho de correção em todos os produtos.
- Compare produtos lado a lado com base em métricas de risco.
- Compare e aprove novas atualizações de versão antes da implantação/lançamento.
- Acompanhe a lacuna da dívida técnica usando os limites de pontuação de risco para versões de produtos.
- Crie um relatório rápido dos 50 principais riscos dos meus produtos mais críticos.
- Análise de impacto para acelerar uma resposta a incidentes – no caso de uma vulnerabilidade explorada ativamente ser encontrada em estado selvagem. Nesse caso, tempo importa para identificar rapidamente como sou impactado e qual seria o raio de explosão do mapa de calor desta exposição.
Como usar a plataforma Scribe Hub para gerenciamento eficaz de riscos:
- Plataforma centralizada de gerenciamento SBOM – Crie, gerencie e compartilhe SBOMs junto com seus aspectos de segurança: vulnerabilidades, avisos VEX, licenças, reputação, explorabilidade, scorecards, etc.
- Crie e implante software seguro – Detecte violações assinando e verificando continuamente o código-fonte, imagens de contêiner e artefatos em todos os estágios de seus pipelines de CI/CD.
- Automatize e simplifique a segurança SDLC – Controle o risco em sua fábrica de software e garanta a confiabilidade do código, traduzindo a segurança e a lógica de negócios em políticas automatizadas, aplicadas por proteções
- Habilite a transparência. Melhore a velocidade de entrega – Capacite as equipes de segurança com recursos para exercer suas responsabilidades, simplificando o controle de segurança sem impedir os resultados da equipe de desenvolvimento.
- Aplicar políticas. Demonstrar conformidade - Monitore e aplique políticas e governança de SDLC para aprimorar a postura de risco de software e demonstrar a conformidade necessária para seus negócios.
Dois exemplos de Central de Escriba recursos de análise de risco são apresentados:
Vulnerabilidades mapeadas por SBOMs, pontuação de risco por dados CVSS, VEX, EPSS e KEV.
Série temporal do desempenho da versão SBOM ao longo do tempo indicando MTTR o tempo médio para reparar vulnerabilidades críticas identificadas.
Resumo
A pontuação de risco orientada pelo SBOM permite que as organizações avaliem o risco da cadeia de suprimentos, avaliando fatores de risco predefinidos e prevendo possíveis riscos futuros associados a um produto de software específico dentro da empresa. A pontuação de risco serve como uma medida quantitativa para antecipar riscos atuais e potenciais relacionados ao software e seus componentes.
Essa métrica de pontuação é derivada de indicadores provenientes do SBOM, VEX, entre outros feeds, e se alinha com o conteúdo de suporte ao Supply Chain Risk Management (SCRM). Ao aplicar ou avaliar uma pontuação de risco, devem ser levados em consideração fatores como o contexto de uso do software, como ele é acessado ou isolado e os processos e sistemas que ele suporta.
O Scribe Hub serve como uma plataforma colaborativa projetada para extração, gerenciamento, coleta de atestados e análise de pontuação de risco de SBOMs em escala. Esta plataforma processa com eficiência vários feeds de dados externos para lidar com as complexidades de sistemas complexos e produtos de software.
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
