Capacidades

Software Supply Chain (SBOM, SCA, KEV)

Quatro camadas coordenadas que respondem ao OWASP A06, da detecção a partir da nuvem a um Evidence Bundle assinado.

A WASViking^® entrega a cobertura de cadeia de suprimentos de software em quatro camadas coordenadas, e não em quatro ferramentas isoladas. Detecção a partir da nuvem, SBOM no ambiente do cliente, um gate de CI/CD e um Evidence Bundle assinado, todos compartilhando um único inventário de componentes e um único conjunto de regras de KEV.

Camada N1: Detecção a partir da nuvem

A detecção de componentes a partir da nuvem identifica componentes de fora da rede, por fingerprinting, usando:

Matchers de regex de caminho por ecossistema.
Hashes SHA1 de arquivos e assets comparados com um catálogo conhecido.
Um subconjunto do Wappalyzer para detecção de frameworks.
Análise de meta-generator.
Sinais em headers de resposta.
Sinais em nomes de cookies.
Caminhos conhecidos de CMS (/wp-admin/, /administrator/, etc.).

Cada detecção é enriquecida com advisories do OSV.dev e flags do CISA KEV. Uma heurística de EOL destaca os componentes que já passaram do fim de vida.

Mapeamento de CWE: CWE-937 (Vulnerable Components), CWE-1104 (Use of Unmaintained Component), CWE-1395 (Outdated Software).

Camada N2: SBOM no ambiente do cliente

wasviking-sentinel sbom percorre os manifestos de build no host e produz um SBOM CycloneDX 1.5 enriquecido com OSV e KEV. Ele é enviado ao seu tenant pelo mesmo túnel mTLS.

Veja wasviking-sentinel sbom para a referência do agente.

Camada N3: Gate de CI/CD

wasviking-sentinel ci --sca executa a passagem de SBOM, OSV e KEV no momento do build. Exit codes determinísticos: 70 KEV, 71 não KEV, 72 OK. Os pipelines falham antes do merge.

Veja wasviking-sentinel ci para a referência do gate.

Evidence Bundle: artefato de due diligence de fornecedores

Um pacote assinado por submissão, mais um CycloneDX consolidado de toda a organização, mais um PDF de capa com a marca, mais CSVs de drift / achados / auditoria / conformidade, mais verification.txt.

Modelo de distribuição: compartilhamento com token + senha separados, com prazo de validade e revogável. Escopo REST público sca:read. O mesmo modelo zero-knowledge do Posture Shares.

Ação	Endpoint
Criar bundle	`POST /v1/sca/bundles` (`evidence.share`)
Listar bundles	`GET /v1/sca/bundles` (`sca:read`)
Revogar bundle	`POST /v1/sca/bundles/{id}/revoke`

Os operadores podem emitir, reemitir e revogar bundles pelo portal em Inventory → SBOM.

Busca de componentes

O inventário de SBOM mantém um índice invertido de componentes que abrange todas as submissões. Use a busca para responder a perguntas em uma única consulta:

GET /api/v1/inventory/components/search?name=log4j-core&version=2.14.1

{
  "matches": 3,
  "hosts": ["checkout-api.prod", "billing-worker.stg", "legacy-portal.dr"],
  "kev": true,
  "first_seen": "2026-04-18T11:02Z"
}

Continuous Supply Chain Watch

Cruzamento diário de todos os SBOMs enviados com o OSV e o CISA KEV. Novos advisories viram Findings automaticamente. Os alertas só são reenviados em mudanças de estado relevantes (inclusão no KEV, escalada de severidade, disponibilidade de correção).

Veja a página dedicada: Supply Chain Intel.

Supply-chain IOC (Manual Indicators)

Para indicadores fornecidos pelo operador, fora dos feeds automatizados de OSV + KEV. Defina um pacote e um intervalo de versões, faça um dry-run para pré-visualizar as correspondências e aplique para promovê-las a Findings.

Veja a página dedicada: Supply-chain IOC.

Onde isso fica no portal

Inventory → Software Bill of Materials: submissões e visão de componentes.
Inventory → Supply Chain Intel: Continuous Watch.
Inventory → Supply-chain IOC: indicadores fornecidos pelo operador.
Inventory → SBOM Evidence Bundles: pacotes de auditoria assinados.
Findings: filtrável pela categoria vulnerable_component.
Settings → API Keys: para os escopos sca:submit, sca:read, sca:ioc e sca:intel:read.

Configuração

Os três pontos de entrada são ativados de forma independente:

A detecção a partir da nuvem roda em todo scan externo. Não há nada a configurar.
O SBOM no ambiente do cliente começa quando você executa wasviking-sentinel sbom em um repositório e envia o resultado.
O gate de CI/CD começa quando você adiciona o binário ao seu pipeline. Veja wasviking-sentinel em CI/CD ou a receita para GitHub Actions.

Quando já houver submissões, emita evidências seguindo SBOM Evidence Bundles e acompanhe o monitoramento diário de advisories em Supply Chain Intel.