Atributos de uma vulnerabilidade¶

Identificar que uma imagem tem vulnerabilidades é apenas o começo. O que define se o seu time vai resolver o problema certo, na ordem certa, é entender o que cada atributo diz e o que ele não diz.

O painel de detalhes de uma vulnerabilidade no Quor serve para auxiliar esse processo de priorização de problemas, organizando todas as informações de uma vulnerabilidade em seis grupos:

Identificação alternativa.
Descrição.
Métricas de severidade e exploração.
Localização do pacote.
CVSS Vector.
Referências externas.

Esses atributos consolidam, em uma única visualização, dados distribuídos entre diferentes bases de dados e registros (NVD, GHSA, FIRST e o repositório do pacote) eliminando a necessidade de consulta manual a fontes externas durante a triagem.

ID Alternativo¶

Identificador secundário da vulnerabilidade em uma base de dados diferente da que originou o registro. O caso mais comum é a coexistência entre um GHSA ID (GitHub Security Advisory) e um CVE ID (NVD - National Vulnerability Database), emitidos de forma independente para a mesma vulnerabilidade.

Descrição¶

Texto direto sobre o comportamento da vulnerabilidade: o que é afetado; como o problema se manifesta; e qual o vetor de impacto em linguagem natural. A descrição vem da fonte original: GHSA, NVD ou do próprio mantenedor do pacote.

É o primeiro ponto de leitura antes de entrar nos números. Uma CVE com Base Score 7.5 que afeta um subsistema de telemetria interno tem impacto operacional muito diferente de uma com o mesmo score que afeta a camada de autenticação, e a descrição é o que deixa isso claro.

Métricas¶

O bloco de métricas reúne os indicadores quantitativos que determinam a gravidade da vulnerabilidade e a probabilidade real de exploração. Existem duas dimensões aqui que é importante não confundir: severidade (quão grave é o dano potencial) e probabilidade (quão provável é que alguém explore isso ativamente).

Base score¶

Score calculado a partir do CVSS Vector. Escala de 0 a 10, categorizado em:

None: 0.0 | Low: 0.1–3.9 | Medium: 4.0–6.9 | High: 7.0–8.9 | Critical: 9.0–10.0

Representa a severidade intrínseca da vulnerabilidade, sem considerar o ambiente de execução.

Impact Score¶

Subcomponente do Base Score. Mede a magnitude do impacto potencial sobre Confidencialidade, Integridade e Disponibilidade do sistema afetado.

Exploitability Score¶

Subcomponente do Base Score. Mede a facilidade de exploração com base nos vetores de ataque, complexidade, privilégios necessários e interação do usuário, os mesmos parâmetros detalhados no CVSS Vector.

Risk¶

Probabilidade de exploração ajustada ao contexto da imagem e da stack. Complementa o EPSS com fatores específicos do ambiente.

EPSS¶

Exploit Prediction Scoring System, mantido pelo FIRST. Estima a probabilidade de exploração ativa da CVE nos próximos 30 dias com base em dados de inteligência de ameaças. Escala de 0 a 1 (0% a 100%).

EPSS Percentile¶

Posição percentual da CVE no conjunto total de vulnerabilidades rastreadas pelo modelo EPSS. Indica a magnitude relativa do score, um valor absoluto baixo pode representar percentil alto dependendo da distribuição geral.

Importante

EPSS e EPSS Percentile juntos são os campos mais relevantes para separar o que precisa de atenção imediata do que pode esperar o próximo ciclo de atualização

Detalhes do pacote¶

Localização precisa do pacote vulnerável dentro da imagem.

Type¶

Ecossistema do pacote: golang, npm, pip, deb, rpm, entre outros. Determina o gerenciador de pacotes e o processo de atualização aplicável.

Location¶

Caminho absoluto do binário ou biblioteca dentro da imagem onde o pacote foi detectado. Permite distinguir se o artefato está presente em runtime ou exclusivamente no processo de build.

PURL¶

Package URL, identificador padronizado pelo PURL Spec que referencia o pacote de forma inequívoca: ecossistema, namespace, nome e versão em uma única string (ex: pkg:golang/go.opentelemetry.io/otel@v1.39.0). É o formato de referência usado por ferramentas de automação e políticas de admissão, e corresponde diretamente às entradas do SBOM da imagem.

CVSS Vector¶

O CVSS (Common Vulnerability Scoring System) é o padrão aberto para comunicar as características e a severidade de vulnerabilidades de software. A string de vector é uma representação textual compacta de todos os valores atribuídos a cada métrica, e deve sempre ser exibida junto com a pontuação.

Ela começa com o prefixo CVSS:3.1/ seguido de cada métrica no formato CHAVE:VALOR, separadas por /.

Em linhas gerais, as métricas se dividem em três grupos: Base, Temporal e Ambiental. As métricas de Base representam as características intrínsecas da vulnerabilidade, constantes no tempo e independentes do ambiente.

Informação

O Quor exibe exclusivamente as métricas do grupo Base, que são as únicas obrigatórias e as mais amplamente publicadas.

Exploitability Metrics¶

Estas métricas descrevem as condições necessárias para que um atacante consiga explorar a vulnerabilidade. Elas são avaliadas do ponto de vista do componente vulnerável.

Attack Vector (AV)

Reflete o contexto pelo qual a exploração da vulnerabilidade é possível. Quanto mais remoto o atacante pode estar, maior a pontuação base, pois o número de potenciais atacantes aumenta.

Network (N): O componente vulnerável está acessível pela rede e o conjunto de potenciais atacantes se estende até a Internet como um todo.

Adjacent (A): O componente vulnerável está acessível pela rede, mas o ataque é limitado a uma topologia logicamente adjacente, como a mesma rede física (Bluetooth, Wi-Fi), subnet local ou domínio administrativo isolado (VPN, MPLS).

Local (L): O componente vulnerável não está acessível pela rede. O atacante age via capacidades de leitura, escrita ou execução, acessando o sistema localmente (teclado, console) ou remotamente (SSH).

Physical (P): O ataque exige que o atacante toque ou manipule fisicamente o componente vulnerável. A interação física pode ser breve ou persistente.

Attack Complexity (AC)¶

Descreve as condições além do controle do atacante que precisam existir para que o exploit seja bem-sucedido. Quanto mais simples o ataque, maior a pontuação. Esta métrica não inclui a interação do usuário, isso é capturado separadamente em UI.

Low (L): Não existem condições especiais de acesso nem circunstâncias extenuantes. O atacante pode esperar sucesso repetível ao atacar o componente vulnerável, o exploit funciona de forma consistente e previsível.

High (H): Um ataque bem-sucedido depende de condições além do controle do atacante. Isso significa que o ataque não pode ser executado simplesmente à vontade; exige investimento mensurável de esforço em preparação ou execução.

Privileges Required (PR)¶

Descreve o nível de privilégios que um atacante deve ter antes de explorar com sucesso a vulnerabilidade. Quanto menos privilégios forem necessários, maior a pontuação base.

None (N): O atacante não precisa de nenhum acesso prévio. Não é necessário autenticação nem acesso a configurações ou arquivos do sistema vulnerável para realizar o ataque. É o valor típico para vulnerabilidades com credenciais embutidas ou que dependem de engenharia social (como XSS refletido ou CSRF).

Low (L): O atacante precisa de privilégios que fornecem capacidades básicas de usuário, normalmente afetando apenas configurações e arquivos pertencentes ao próprio usuário, ou com acesso a recursos não sensíveis.

High (H): O atacante precisa de privilégios que fornecem controle significativo sobre o componente vulnerável, como acesso administrativo, permitindo acesso a configurações e arquivos de todo o sistema.

User Interaction (UI)¶

Captura se um usuário humano, além do atacante, precisa participar para que a exploração tenha sucesso. Quando nenhuma interação é necessária, a pontuação é maior.

None (N): O sistema vulnerável pode ser explorado sem qualquer interação de outro usuário. O atacante age de forma autônoma.

Required (R): A exploração bem-sucedida exige que um usuário execute alguma ação antes que a vulnerabilidade possa ser explorada, por exemplo, um ataque que só é possível enquanto um administrador de sistema está realizando a instalação de uma aplicação.

Scope (S)¶

Captura se uma vulnerabilidade em um componente vulnerável impacta recursos em componentes que estão fora do seu escopo de segurança.

Unchanged (U): A vulnerabilidade explorada só pode afetar recursos gerenciados pela mesma autoridade de segurança. O componente vulnerável e o impactado são o mesmo, ou ambos estão sob a mesma autoridade.

Changed (C): A vulnerabilidade explorada pode afetar recursos além do escopo de segurança da autoridade do componente vulnerável. Componente vulnerável e componente impactado são diferentes e gerenciados por autoridades de segurança distintas.

Impact Metrics¶

Estas métricas capturam os efeitos de uma exploração bem-sucedida. Os analistas devem limitar os impactos a um resultado razoável e final que um atacante seja capaz de atingir com segurança.

Confidentiality (C)¶

Mede o impacto à confidencialidade das informações gerenciadas pelo componente afetado. Confidencialidade refere-se à limitação de acesso e divulgação de informações apenas a usuários autorizados.

High (H): Há perda total de confidencialidade, resultando em todos os recursos do componente impactado sendo divulgados ao atacante.

Low (L): Há alguma perda de confidencialidade. O atacante obtém acesso a algumas informações restritas, mas não controla quais informações são obtidas, ou a extensão da perda é limitada. A divulgação não causa perda direta e grave ao componente impactado.

None (N): Não há perda de confidencialidade no componente impactado.

Integrity (I)¶

Mede o impacto à integridade de uma exploração bem-sucedida. Integridade refere-se à confiabilidade e veracidade das informações.

High (H): Há perda total de integridade, ou perda completa de proteção. Por exemplo, o atacante pode modificar quaisquer arquivos protegidos pelo componente impactado.

Low (L): A modificação de dados é possível, mas o atacante não tem controle sobre as consequências da modificação, ou o volume de modificação é limitado. A modificação de dados não tem impacto direto e grave ao componente impactado.

None (N): Não há perda de integridade no componente impactado.

Availability (A)¶

Mede o impacto à disponibilidade do componente impactado. Diferente de C e I, que se referem à perda de dados, esta métrica se refere à perda de acesso ao próprio componente, como um serviço de rede (web, banco de dados, e-mail).

High (H): Há perda total de disponibilidade. O atacante pode negar completamente o acesso aos recursos do componente impactado de forma sustentada (enquanto o ataque continua) ou persistente (a condição persiste mesmo após o ataque).

Low (L): O desempenho é reduzido ou ocorrem interrupções na disponibilidade dos recursos. Mesmo que a exploração repetida seja possível, o atacante não tem capacidade de negar completamente o serviço a usuários legítimos.

None (N): Não há impacto à disponibilidade no componente impactado.

Links¶

Referências às fontes primárias da vulnerabilidade: advisory original (GHSA ou NVD), pull requests e commits de correção no repositório do projeto, e release tag com a versão corrigida. Os links são providos pela fonte do registro e podem variar conforme a disponibilidade de informação pública sobre a CVE.