XBOM, compliance e relatórios

XBOM: um inventário para software, criptografia e modelos de IA

Um achado diz que algo está errado. Um inventário diz o que você entrega. O XBOM, sigla de Extended Bill of Materials, é o inventário do Plexicus para três tipos de ativos dos seus repositórios. Assim como o Plexicus Automation, ele trabalha ao lado do ciclo Validar, Entender, Remediar.

Software (SBOM): bibliotecas, pacotes e dependências.
Criptografia (CBOM): algoritmos, tamanhos de chave, primitivas e onde são usados.
Modelos de IA (AIBOM): modelos de machine learning com seus provedores, conjuntos de dados e licenças.

Abra XBOM na barra lateral principal. A página se chama “Asset Inventory (XBOM)” e tem três abas: Software (SBOM), Cryptography (CBOM) e AI Models (AIBOM). A aba selecionada fica gravada na URL, então recarregar a página ou abrir um link compartilhado leva à mesma aba, mas não aos seus filtros. O XBOM fica disponível conforme o seu plano.

Como ativar as ferramentas de BOM

Cada aba fica vazia até que a ferramenta correspondente seja ativada e um repositório seja escaneado, ou até que você importe um BOM de fornecedor com esse tipo de componente. Uma aba vazia indica qual ferramenta ativar e oferece o botão Go to Connectors.

A ferramenta CBOM detecta criptografia em código JavaScript e TypeScript, Go, Ruby, PHP, C e C++, Python e Java.

O que cada inventário mostra

Aba	Colunas	Filtros extras
Software (SBOM)	Component, Version, Repository, VEX status, Vulnerabilities, License, Actions	License category
Cryptography (CBOM)	Algorithm, Key size / Params, Primitive, Context / Source, Repository, Compliance risk	Quantum classification
AI Models (AIBOM)	Model, Type, Provider, Version, Datasets, Licenses, Repository, Security / Risk	Provider, Risk flag

Todas as abas também têm uma caixa de busca e um filtro Repository. A coluna Vulnerabilities do SBOM conta, por severidade (C, H, M, L), os achados ativos cujo nome e versão de biblioteca correspondem ao componente. As contagens não são links; para ver os achados, filtre Findings por Library. As licenças se dividem em cinco categorias: Permissive (como MIT ou Apache-2.0), Weak copyleft (como LGPL ou MPL-2.0), Strong copyleft (como GPL ou AGPL), Proprietary e Unknown.

Cada ativo do CBOM recebe uma classificação quântica:

Quantum Vulnerable: criptografia de chave pública que um computador quântico poderia quebrar, como RSA, ECDSA, ECDH, DH e Ed25519.
Deprecated/Weak: quebrada ou fraca já hoje, como MD5, SHA-1, DES, 3DES e RC4.
Quantum Safe: padrões pós-quânticos do NIST, como ML-KEM e ML-DSA, além de primitivas simétricas e de hash que resistem a ataques quânticos.
Unknown: não há informação suficiente para classificar.

As linhas do AIBOM trazem sinalizadores de risco: Serialization Risk (arquivos de modelo como .pkl ou .pt), No Model Card, Unknown License, Restricted License (por exemplo, termos não comerciais ou apenas para pesquisa), External API (um modelo chamado pela API de um provedor), No Dataset Provenance e Unpinned Version (vazia, “latest”, “main” e similares).

Clique em uma linha para abrir o painel Details: PURL, hashes, caminhos de arquivo, fornecedor e ferramenta de origem para software, motivos da classificação para criptografia e conjuntos de dados para modelos de IA.

A visão geral executiva

A seção Executive overview, acima das abas, mostra cinco cards de KPI: Total components, Repositories covered (dividido em SBOM, CBOM e AIBOM), Quantum readiness, AI models (com quantos têm riscos) e License risk. Em seguida vêm quatro gráficos: License categories, Quantum classification, Top vulnerable components e AI providers.

Dois cards exigem atenção:

Quantum readiness é a proporção de todos os ativos do CBOM, incluindo os Unknown, classificados como Quantum Safe, com pontuação de 0 a 100 e referência aos prazos de 2030/2035 do NIST. O card fica verde a partir de 80, amarelo de 50 a 79 e vermelho abaixo de 50. Sem dados de CBOM, o card mostra 0/100, então confirme que a ferramenta CBOM está ativada antes de tirar qualquer conclusão dele.
License risk conta os componentes com licenças strong copyleft, proprietárias ou desconhecidas. Weak copyleft, como a LGPL, não entra na conta. O card indica o que enviar para revisão jurídica; ele não é um parecer jurídico.

Uma pontuação quântica baixa é um sinal para planejamento. Suponha que o CBOM mostre RSA-2048 no seu serviço de identidade (Quantum Vulnerable) e MD5 em um gerador de tokens de redefinição de senha (Deprecated/Weak). Corrija primeiro o MD5, porque ele já é fraco hoje, e planeje a migração do RSA de acordo com os prazos do NIST.

Declarações VEX, watchlists e diff entre scans

Seu SBOM lista um componente com uma CVE conhecida. Isso, por si só, não significa que o seu produto seja explorável. Uma declaração VEX (Vulnerability Exploitability eXchange) registra a sua avaliação de uma vulnerabilidade em um componente, para que o próximo revisor não precise repetir a análise.

Como definir uma declaração VEX

Na linha do componente, abra XBOM Software (SBOM) Actions Set VEX . O formulário VEX statement tem Component (já preenchido), Vulnerability ID (por exemplo, CVE-2024-12345), Status, Justification e um campo Detail opcional. O Status começa em Under investigation. Clique em Save statement.

Status	Use quando	Justificativa
Affected	O código vulnerável está presente e se aplica ao seu produto, e você está trabalhando nisso	Opcional, mas diga o que está fazendo
Not affected	O componente está presente, mas a vulnerabilidade não se aplica; por exemplo, a função vulnerável nunca é chamada	Exigida pelo formulário
Fixed	Você atualizou ou aplicou um patch para uma versão sem a vulnerabilidade	Opcional, mas informe a versão
Under investigation	Você ainda não concluiu a avaliação	Opcional, mas diga o que está sendo verificado

Exemplo: o seu serviço de pagamentos inclui uma biblioteca YAML com uma CVE de desserialização no loader inseguro. A sua revisão, por exemplo com o Deep Code Analysis (módulo 5), mostra que o seu código só chama o loader seguro. Registre Not affected com uma justificativa como “O loader inseguro nunca é chamado; todo parsing usa o loader seguro, veja o rastreamento do achado.”

A coluna VEX status mostra a declaração mais recente do componente. Se um componente tem declarações para várias vulnerabilidades, a coluna mostra apenas a mais nova, seja qual for a vulnerabilidade que ela cobre. Por isso, um selo Not affected não descarta todas as CVEs desse componente: confira os achados dele em Findings antes de dar o componente como liberado. Salvar uma declaração exige a mesma permissão de escrita necessária para fazer a triagem de achados.

As declarações VEX ficam no Plexicus. As exportações CycloneDX, SPDX, CSV e PDF não as incluem, então mostre o VEX status aos revisores no XBOM ou registre a avaliação no seu próprio documento VEX.

Watchlists

Uma watchlist avisa você quando um componente de software (SBOM) que você quer acompanhar aparece em um novo scan. Ativos criptográficos e modelos de IA não disparam alertas de watchlist. Abra XBOM Watchlists , informe um Pattern, escolha um Type, deixe Notify on match ativado e clique em Add watchlist.

Name corresponde a qualquer componente cujo nome contenha o padrão, sem diferenciar maiúsculas de minúsculas. O padrão “log4j” corresponde a log4j-core e log4j-api.
PURL corresponde a componentes cujo package URL começa com o padrão, como pkg
/lodash.

A ação de linha Watch component na aba SBOM é um atalho: ela cria uma entrada Name para esse componente, com as notificações ativadas.

Um alerta só dispara quando um nome e uma versão correspondentes não estavam presentes em scans anteriores daquele repositório. Assim, um componente que já existe há tempo não gera alerta a cada scan, mas uma nova versão dele gera. Os alertas chegam como notificações de aviso no app, com o nome do componente, a versão e o padrão que gerou a correspondência. Bons candidatos são bibliotecas que a sua equipe baniu, pacotes com histórico de versões comprometidas e pacotes internos que você quer rastrear entre equipes.

Mudanças em relação ao scan anterior

No filtro Repository, selecione exatamente um repositório. Aparece o painel Changes vs previous scan. Ele compara os dois scans mais recentes desse repositório e lista os componentes como Added, Removed ou Changed (a versão é diferente). Consulte-o depois de um merge para detectar uma dependência que ninguém discutiu, ou depois de uma atualização para confirmar que a versão antiga realmente saiu.

Importar BOMs de fornecedores e exportar

Como importar um BOM de fornecedor

O seu produto contém software que você não desenvolveu. Quando um fornecedor enviar um BOM, importe-o para que os componentes dele fiquem ao lado dos seus: XBOM Import . O formulário Import supplier SBOM aceita um arquivo JSON CycloneDX ou SPDX de até 20 MB e um Supplier name obrigatório. Uma notificação confirma quantos componentes foram importados.

Em um arquivo CycloneDX, os componentes de ativos criptográficos vão para o inventário CBOM, os componentes de modelos de machine learning vão para o AIBOM e todo o resto vai para o SBOM. Quando o mesmo fornecedor enviar um BOM atualizado, importe-o de novo com o mesmo nome de fornecedor. O Plexicus substitui o snapshot importado anterior desse fornecedor, em vez de adicionar duplicatas.

Formatos de exportação

Escolha a aba primeiro e depois abra Export.

Formato	Funciona em	O que você recebe
CycloneDX JSON	SBOM, CBOM, AIBOM	Um documento CycloneDX 1.6
SPDX JSON	Apenas SBOM	Um documento SPDX 2.3
CSV	SBOM, CBOM, AIBOM	Uma planilha do inventário, baixada na hora
PDF attestation	SBOM, AIBOM (também aparece na aba CBOM, mas falha lá)	Um XBOM Attestation Report pontuado em relação a um perfil de compliance

Para CycloneDX, SPDX e PDF, uma caixa de diálogo pede Product name (em branco, usa o nome exibido, como o do repositório ou da organização) e Product version (em branco, usa a data da exportação). No CycloneDX e no SPDX, esses campos dão nome ao componente raiz do documento, então preencha os dois em tudo o que sair da sua equipe. A atestação em PDF não mostra o nome nem a versão do produto. Ela cita apenas a sua organização, então envie-a junto com a exportação CycloneDX correspondente e informe o release na mensagem que acompanha o envio.

O que uma exportação cobre:

O snapshot do scan mais recente, não o histórico.
O primeiro repositório selecionado no filtro, ou a organização inteira quando nenhum estiver selecionado.
No SBOM, uma entrada por PURL: um pacote encontrado em vários repositórios aparece uma só vez, com os caminhos de arquivo reunidos como evidência.

Os dois formatos nomeiam o seu produto como raiz e trazem a data e a hora de criação e a sua organização. O CycloneDX acrescenta um número de série único e lista a sua organização como fornecedora; o SPDX usa, em vez disso, um namespace de documento único. As relações de dependência só aparecem onde foram resolvidas, e o documento CycloneDX declara a lista de componentes como completa, mas o grafo de dependências transitivas como incompleto. É uma declaração precisa, na qual um revisor pode confiar.

Atestação em PDF e perfis de compliance

Perfil	Tipo de BOM	Campos verificados por componente
EU CRA (BSI TR-03183-2)	SBOM	Nome, versão, PURL, licenças, hashes, fornecedor, caminhos de arquivo
CISA 2025	SBOM	Nome, versão, PURL, licenças, hashes, fornecedor, ferramenta de origem
PCI DSS 6.3.2	SBOM	Nome, versão, repositório, ferramenta de origem
EU AI Act	AIBOM	Nome, versão, provedor, licenças, conjuntos de dados, model card

O relatório informa o tipo de BOM, a organização, a data e a hora de geração e um hash SHA-256 do conteúdo do BOM. Em seguida vêm uma seção Summary e uma pontuação de completude de 0 a 100 para o perfil escolhido, com uma tabela Present, Missing e Coverage por campo e notas regulatórias. A pontuação faz a média entre a cobertura dos campos e as verificações do documento: componente raiz, versão da especificação, número de série, data e hora, criador, ausência de duplicatas, um grafo de dependências e referências de dependência resolvíveis.

O hash cobre uma renderização CycloneDX gerada no momento da exportação, então não vai coincidir com um arquivo CycloneDX que você baixar separadamente. Não o apresente como forma de verificar outro arquivo.

A pontuação de completude avalia o documento, não a sua conformidade. A coluna Missing mostra quantos componentes não têm cada campo obrigatório. As verificações do documento entram na pontuação, mas não são listadas; por isso, se todos os campos mostram 100% e a pontuação continua menor, a lacuna está no nível do documento, na maioria das vezes um grafo de dependências ausente ou parcial. Revise as lacunas antes de enviar a atestação e informe ao destinatário as que você não conseguir fechar.

A visão de Compliance

Escolha seus frameworks primeiro

A visão de Compliance mostra apenas os frameworks que a sua organização acompanha. Escolha-os em Settings Organization Regulations : clique em Edit, selecione os frameworks no catálogo e clique em Save changes. Os dois botões Configure frameworks da aba Compliance levam até lá. Enquanto você não selecionar pelo menos um, a aba mostra “No compliance frameworks configured”.

O catálogo reúne 50 frameworks, incluindo NIS2, DORA, CRA, GDPR, PCI DSS v4.0.1, ISO 27001

, SOC 2, NIST CSF, NIST 800-53r5, HIPAA, ENS e ISA/IEC 62443. Alguns frameworks dependem do seu plano: eles exibem um selo com o nome do plano exigido, e selecionar um deles abre um aviso de upgrade. Frameworks fora do catálogo são adicionados mediante contato com a Plexicus.

Como os achados são mapeados

O mapeamento acontece quando o Plexicus enriquece um achado com IA. Cada framework é avaliado, mas só é associado quando existe um controle estrito, ou seja, um que poderia prevenir a vulnerabilidade. Controles que apenas ajudam a detectar ou responder ficam de fora, e no máximo um controle por framework é registrado. Uma injeção de SQL em um handler de login pode ser mapeada para um controle de validação de entrada ou de desenvolvimento seguro. Ela não é mapeada para um controle de logging só porque o logging poderia ter percebido o ataque.

O resultado fica gravado no achado como Regulation, Control e Control category. Abra um achado e role até a seção Compliance & OWASP, que lista cada regulamentação com o controle, a categoria do controle e uma breve descrição. Quando nada se aplica, ela mostra “This security finding does not activate any applicable compliance policies.” Em Findings, All filters permite filtrar por Regulation, Control e Control category, e o filtro Regulation oferece apenas os frameworks que você ativou.

O mapeamento é gerado por IA. Trate-o como um ponto de partida sólido, que uma pessoa confirma, principalmente para qualquer controle que você pretenda citar em uma auditoria.

Como ler a aba Compliance

Abra Dashboard Compliance . O endereço antigo da página Compliance redireciona para cá. A barra de filtros tem Repository, Asset type (All assets, Code, Cloud, SCM), Severity e Framework, além de Configure frameworks e Refresh. A aba e alguns frameworks ficam disponíveis conforme o seu plano.

Widget	O que mostra
Cards de framework	Open findings, Critical / High, Fixed, Affected assets e uma contagem de controles para cada framework
Risk Dashboard	Um fluxo de Total Findings para Fixed e Remaining, seguido de severidade, grupo de ativos (Code, Cloud, SCM) e framework
Compliance Findings	Um heatmap de achados em aberto por repositório e framework, para os seus repositórios mais movimentados
Findings Trend	Novos achados por semana e por framework em Last 30 days, Last 90 days (o padrão), Last 6 months ou Last year
Framework Risk Quadrant	Achados em aberto plotados em relação a quantos repositórios cada framework afeta
Top Violated Controls	Control, Framework, Category, Severity, Findings e Assets, com os controles com mais achados primeiro

Na maioria dos widgets, um clique abre Findings com os filtros aplicados. Um card ou um nó de framework filtra por aquela regulamentação, um nó de severidade por aquela severidade, uma célula do heatmap pelo framework e pelo repositório, e uma linha de Top Violated Controls pelo framework e pelo controle. Os filtros Repository e Severity da aba são mantidos. Asset type não é mantido, e o clique abre a aba Repo de Findings; então, para esses achados, mude para a aba Cloud ou SCM. Um card que mostra “No findings · mapping pending” ainda não tem achados mapeados.

As contagens excluem duplicatas, sub-achados, falsos positivos e achados excluídos, e “em aberto” significa ainda não resolvido. A qualidade da triagem aparece diretamente aqui: um falso positivo deixado em aberto infla os números de um framework, e os achados resolvidos passam para Fixed.

Relatórios e evidências

Auditores, clientes e a sua própria liderança pedem evidências em formatos diferentes. Além das exportações do XBOM, o Plexicus oferece três tipos de relatório.

O Findings Intelligence Report

Em Findings, escolha a aba (Repo, SCM, Cloud, Registry ou App Pentest), defina os filtros e clique em Findings Download PDF . O relatório é gerado em segundo plano. Uma notificação “Report being generated” avisa que você receberá um e-mail quando ele estiver pronto. Em seguida, você recebe um e-mail e uma notificação Report Ready no app, com um botão Download report. Os dois abrem uma página de download no Plexicus que exige login. Se o relatório ainda estiver sendo gerado ou o link tiver expirado, a página informa isso, e você pode gerá-lo de novo.

O que saber antes de contar com ele:

A sua organização pode solicitar no máximo 5 relatórios por hora, um limite compartilhado entre todos os usuários. Acima disso, aparece “Rate limit reached”. Cada solicitação, inclusive uma recusada, reinicia a contagem da hora, então espere em vez de tentar de novo.
O relatório é escrito no idioma definido em Scan & Report Language para a organização, em Settings Platform . Títulos de achados e código ficam no idioma original.
Os relatórios em PDF ficam disponíveis conforme o seu plano.

O relatório começa com uma capa (organização, data de geração, total de achados, repositórios escaneados, marcada como CONFIDENTIAL) e um Executive Summary com o total e as contagens de Critical, High, Medium, Low, Resolved, In Progress e repositórios. Os gráficos incluem Severity Distribution, os 5 principais achados por EPSS, Remediation Status, Findings by Repository e Findings by Language. Uma tabela Findings Detail (Severity, Title, Repository, Tool, EPSS, Status) lista até 500 achados, dos mais graves para os menos graves, enquanto os contadores e os gráficos continuam cobrindo todos os achados do escopo. Até 10 achados críticos ganham uma seção de detalhes com orientações de remediação geradas por IA.

Filtre antes de clicar. “Critical e High, repositório de pagamentos, Regulation NIS2” é um relatório com o qual um revisor consegue trabalhar. Uma exportação sem filtros de um backlog grande corta a tabela em 500 linhas.

Exportações SARIF e CSV

Findings Download JSON baixa o findings.json, um documento SARIF 2.1.0 limitado à aba e aos filtros atuais. Por padrão, ele inclui apenas achados com status AI-Analysed. Achados que já avançaram para Ready to Fix, Fix Submitted, Issued ou Fixed ficam de fora, então use o relatório em PDF quando precisar mostrar o progresso da remediação. Use o arquivo SARIF para passar os resultados a outra ferramenta que leia SARIF.
Download report, na tela de detalhes de um achado, gera um arquivo SARIF só daquele achado, útil para um ticket ou um code review.
Em Assets Repo Scan , o botão de download da tabela exporta os repositórios filtrados como repositories.csv, uma lista de ativos pronta para entregar a um auditor.

As exportações de Findings ficam gravadas no registro de auditoria (módulo 10). Os relatórios de AI Pentest são abordados no módulo 6.

Apoio às conversas regulatórias

Conversa	Evidências que você pode levar do Plexicus
NIS2, sobre tratamento de vulnerabilidades e segurança da cadeia de suprimentos	A aba Compliance filtrada por NIS2, um Findings Intelligence Report filtrado pela regulamentação NIS2, o Findings Trend e uma exportação do SBOM
DORA Art. 28, sobre risco de terceiros de TIC	BOMs de fornecedores importados, exportações do SBOM, declarações VEX sobre componentes de terceiros registradas no XBOM (exibidas no app, não nas exportações) e a aba Compliance filtrada por DORA
EU CRA	Um SBOM em CycloneDX ou SPDX, uma atestação em PDF com o perfil EU CRA e as declarações VEX que você registrou no XBOM
EU AI Act	O AIBOM com provedores, conjuntos de dados e sinalizadores de risco, e uma atestação em PDF com o perfil EU AI Act

Principais pontos

O XBOM é um inventário com três abas, Software (SBOM), Cryptography (CBOM) e AI Models (AIBOM), alimentadas quando você ativa Plexicus SBOM, CBOM e AIBOM na página Connectors e escaneia.
As declarações VEX registram, por componente e por vulnerabilidade, se você está Affected, Not affected (justificativa obrigatória), Fixed ou Under investigation. Elas não mudam o status dos achados, então faça a triagem dos achados separadamente.
As watchlists alertam, por nome ou PURL, sobre componentes de software que aparecem pela primeira vez, e o diff compara os dois últimos scans de um repositório.
As exportações cobrem o snapshot mais recente: CycloneDX 1.6 para todas as abas, SPDX 2.3 para o SBOM, CSV e uma atestação em PDF cujo perfil precisa corresponder ao tipo de BOM.
A aba Compliance mostra apenas os frameworks escolhidos em Settings, Organization, Regulations, mapeia achados apenas para controles que poderiam preveni-los e leva até os achados mapeados para um framework ou controle.
Findings Intelligence Reports, exportações SARIF e CSVs de repositórios são evidências para conversas sobre NIS2, DORA, CRA e EU AI Act. O Plexicus gera as evidências; seus auditores avaliam a conformidade.