Supply Chain Intel (Continuous Watch)

Cruzamento diário de cada SBOM enviado com o OSV e o CISA KEV, priorizado pela explorabilidade EPSS, com aceitação formal de risco, atestação OpenVEX e um Exploitability Report com identidade visual.

O WASViking^® Supply Chain Intel executa o Continuous Watch sobre cada SBOM que a sua organização enviou. Os SBOMs entram no inventário uma única vez e são reavaliados todos os dias com base nos advisories mais recentes. Não é preciso refazer o scan nem reenviar nada.

Esta é a página em Inventory → Supply Chain Intel no portal.

O que ele faz

Continuous Watch cross-references every SBOM you have submitted against OSV and CISA KEV every day. Each vulnerable component becomes a Finding with its own lifecycle. (O Continuous Watch cruza todos os dias cada SBOM que você enviou com o OSV e o CISA KEV. Cada componente vulnerável vira um Finding com o seu próprio ciclo de vida.)

Três resultados concretos:

1. Advisories realmente novos, publicados hoje, são comparados com cada SBOM ativo que você enviou no passado.
2. Advisories existentes que mudam (inclusão no KEV, aumento de severidade, correção publicada) disparam um novo alerta conforme a política de renotificação.
3. Higiene de status: um componente vulnerável entregue sob a mesma dedupe_key não produz Findings duplicados; ele atualiza o existente.

Como funciona

Fontes

A ingestão é incremental: a cada ciclo, só os advisories novos e modificados são baixados. Os dois feeds são públicos; nenhum dado de cliente sai do seu tenant durante a ingestão.

Cadência

O Continuous Watch roda diariamente. A cada ciclo, ele:

1. Atualiza os deltas do OSV por ecossistema.
2. Calcula o diff do catálogo CISA KEV.
3. Compara cada advisory com cada SBOM ativo da sua organização.
4. Promove as correspondências a Findings com a categoria vulnerable_component e source = continuous_watch.
5. Encaminha os alertas conforme a política de renotificação e a configuração dos canais.

Severidade

A WASViking calcula uma única severidade por correspondência, nesta ordem de precedência:

1. CVSS v4 se disponível; caso contrário, CVSS v3.
2. Severidade qualitativa do GHSA (critical / high / moderate / low) se não houver CVSS.
3. Advisories listados no KEV assumem no mínimo high, mesmo sem uma pontuação CVSS, porque a exploração está confirmada.
4. unknown somente se nenhuma das opções acima estiver disponível.

Política de renotificação

Por design, o Continuous Watch trabalha apenas com sinal. Um novo alerta só dispara em mudanças de estado relevantes de um advisory que já está no seu inventário:

Execuções diárias repetidas que encontram o mesmo advisory no mesmo estado não disparam de novo. Correspondências suprimidas continuam suprimidas; se uma escalada atinge um advisory suprimido, a trilha de auditoria registra o fato com "escalated while suppressed" (escalado enquanto suprimido), mas nenhum alerta é enviado.

Onde ele fica no portal

Inventory → Supply Chain Intel é a visão do operador. A página lista as correspondências com filtros por ecossistema, severidade e status (open, acknowledged, suppressed e fixed, isto é, aberto, reconhecido, suprimido e corrigido), um selo CISA KEV e uma coluna de explorabilidade EPSS. Cada linha abre o detalhamento de:

• Detalhes do advisory (vínculo com CVE / GHSA / KEV, referências, descrição sanitizada).
• Componente afetado e faixa de versões.
• SBOM de origem e alvo.
• Linha do tempo de status com as transições feitas por operadores.
• O painel de exceção por aceitação de risco (aprovador, expiração, justificativa e status VEX) quando a correspondência está suprimida.

Priorização por explorabilidade (EPSS + KEV)

Uma severidade CVSS diz o quanto uma vulnerabilidade é grave em teoria. Ela não diz qual é a probabilidade de a vulnerabilidade ser explorada. O Continuous Watch acrescenta esse sinal que faltava, para que a sua equipe trate primeiro os advisories que importam.

Todo advisory traz dois sinais de explorabilidade:

• CISA KEV sinaliza os advisories com exploração ativa confirmada em ambiente real.
• EPSS é o Exploit Prediction Scoring System da FIRST.org, uma probabilidade diária de que uma CVE seja explorada nos próximos 30 dias. Ele aparece como percentual na coluna EPSS, com a pontuação exata e o percentil ao passar o mouse.

A lista é ordenada pelo risco no mundo real: primeiro os advisories listados no KEV, depois o maior EPSS, depois a severidade CVSS. Um advisory recente de severidade média que atacantes já estão usando fica à frente de um crítico antigo em que ninguém tocou. O EPSS é indexado por CVE, então um advisory sem CVE (uma entrada apenas GHSA) mostra um traço até que apareça um alias de CVE.

O EPSS é atualizado diariamente junto com a ingestão do OSV e do KEV, então a ordenação acompanha o cenário real de ameaças sem nenhuma ação da sua parte.

Aceitação de risco e exceções

Nem todo advisory com correspondência é um problema que você precisa corrigir. Um pacote vulnerável pode estar em uma dependência usada só no build, ou em um caminho de código que a sua aplicação nunca executa. Nesses casos o operador aceita o risco, e a WASViking^® registra essa decisão da forma que um auditor espera vê-la.

A ação Accept risk (aceitar risco) na página de detalhes da correspondência registra:

• Quem aprovou. O operador que executa a ação é registrado como o aprovador.
• Por quê. Uma justificativa por escrito é obrigatória. A decisão não é salva sem ela.
• Até quando. A aceitação traz uma data de expiração definida por você.
• Reatestação. Antes da expiração você pode reatestar, o que estende a janela e registra uma nova justificativa e um novo timestamp.

Um risco aceito não é permanente. Um job diário reabre toda exceção cuja expiração já passou, de modo que uma aceitação vencida volta à tona para revisão em vez de ficar escondida. Toda concessão, reatestação e expiração é gravada na trilha de auditoria.

É isso que transforma uma supressão em um controle defensável: uma decisão atestada, com prazo definido e responsável identificado, em vez de uma caixa de seleção que esconde um achado para sempre.

Atestação VEX

Quando você aceita um risco com o fundamento de que um componente realmente não é explorável, pode registrar o motivo como uma declaração VEX formal. VEX (Vulnerability Exploitability eXchange) é o padrão apoiado pela CISA para declarar, por vulnerabilidade e por componente, se um produto é afetado e, se não for, por quê.

No momento de aceitar o risco, você escolhe uma das cinco justificativas not_affected do OpenVEX:

Uma correspondência com uma justificativa válida é exportada como not_affected no documento OpenVEX. Um risco que você aceita sem justificativa é exportado com honestidade como affected, de modo que a atestação nunca exagera a sua postura. A WASViking gera sob demanda o documento OpenVEX legível por máquina, para que um cliente ou um auditor possa ingeri-lo nas próprias ferramentas.

Exploitability Report (PDF)

O botão Export Exploitability Report na página Supply Chain Intel produz um PDF com identidade visual que responde à pergunta que um cliente regulado ou um auditor realmente faz: das vulnerabilidades conhecidas no seu software, quais podem ser exploradas e quais não podem, com a justificativa de cada uma.

O relatório contém:

• Uma capa com a sua organização, a data de geração e os filtros de escopo aplicados.
• Uma explicação curta do que é o relatório, para que um leitor sem contexto o entenda.
• Um resumo executivo com as contagens de advisories no escopo, afetados, não afetados, corrigidos, listados no KEV e críticos.
• Uma tabela de declarações ordenada por KEV e EPSS, com o status VEX e a justificativa de cada item.

O relatório respeita os filtros atuais de status e de ecossistema, então você pode restringi-lo a um único projeto ou ecossistema antes de exportar. Ele é gerado no servidor com o mesmo motor do relatório de avaliação de segurança da WASViking^®, e foi feito para entrar direto na pasta de um auditor ou em uma resposta de due diligence de fornecedor. As mesmas determinações estão disponíveis como OpenVEX legível por máquina, para ingestão por ferramentas.

Findings produzidos

Toda correspondência é promovida a um Finding no fluxo de trabalho padrão.

Os Findings herdam o fluxo de trabalho de Findings padrão, incluindo as transições de status e os eventos de webhook.

Canais de alerta

O Continuous Watch reutiliza o roteamento de alertas da plataforma. Configure os destinatários em Settings → Notification Channels. No modal de cada canal, ative o evento Supply Chain Advisory.

Veja Eventos de webhook para o catálogo completo de eventos.

API REST

Acesso público de leitura para integrações do tenant e ingestão em SIEM.

O esquema de autenticação é ApiKey wv_live_*. IDs criptografados em trânsito (padrão em toda a API pública). Veja Autenticação.

Disponibilidade por plano

O Continuous Watch é um recurso do plano Pro e superiores. Os planos Free e Starter veem o inventário de SBOMs, mas não a ingestão diária nem o pipeline de renotificação. Limites por plano:

Quando você está no Starter, a página Supply Chain Intel mostra um estado desativado que convida a fazer o upgrade.

O que ele NÃO faz

• Nenhum tráfego de saída para os seus repositórios. O Continuous Watch opera sobre SBOMs já enviados; ele não baixa código-fonte.
• Nenhuma remediação automática. As correspondências viram Findings; a remediação é conduzida pelo operador.
• Nenhum dado de cliente no payload do alerta. Os alertas trazem o advisory e o componente correspondente, além de uma referência opaca à correspondência.
• Não substitui o gate de CI/CD. O gate wasviking-sentinel sbom roda no momento do build. O Continuous Watch é a rede de segurança pós-build para os advisories publicados depois do seu último build.

Como isto se encaixa no restante da história da cadeia de suprimentos

O resumo da capacidade está em Software Supply Chain.

Configuração

Nada a configurar. O monitoramento começa assim que a sua organização envia pelo menos um SBOM e o seu plano inclui o módulo (Pro e superiores). Para começar a enviar, veja wasviking-sentinel sbom.