aquasecurity/vexhubAgrega documentos do Vulnerability Exploitability eXchange (VEX) de projetos de código aberto. Organiza por PURL para integração automatizada com ferramentas de segurança.
O VEX Hub é um repositório centralizado que coleta e gerencia documentos [Vulnerability Exploitability eXchange (VEX)][vex] de vários projetos de software de código aberto. Ele serve como um recurso abrangente para informações de vulnerabilidades, ajudando usuários e ferramentas de segurança a acessar e utilizar dados VEX com eficiência em vários projetos e ecossistemas.
O VEX Hub recupera automaticamente documentos VEX dos repositórios de origem dos projetos registrados. Ao identificar o repositório de origem a partir do [Package URL (PURL)][purl] registrado, o VEX Hub copia e organiza os documentos VEX, tornando-os facilmente acessíveis para a comunidade em geral.
E pronto! O VEX Hub recuperará e processará automaticamente seus documentos VEX.
O [VEX Hub Crawler][vexhub-crawler] rastreia periodicamente os documentos VEX dos pacotes registrados e os mantém no VEX Hub. Os pacotes registrados são definidos como uma lista de [PURLs][purl] em [um arquivo][purl-list] que pode ser atualizado por qualquer pessoa por meio de Pull Requests.
Para informações detalhadas sobre registro de PURL, ecossistemas suportados e requisitos específicos, consulte o [VEX Hub Crawler][vexhub-crawler].
O arquivo de pacotes especifica apenas o PURL do pacote a ser rastreado, e o VEX Hub Crawler identifica automaticamente o repositório de código-fonte onde o arquivo VEX está localizado. O método para identificar repositórios de origem varia conforme o ecossistema. Para informações detalhadas sobre como repositórios de origem são identificados e rastreados para diferentes tipos de pacotes, consulte a [documentação do vex-crawler][vexhub-crawler].
Após identificar o repositório de código-fonte, o VEX Hub descobre automaticamente os documentos VEX nele. O processo de descoberta envolve os seguintes pontos-chave:
.vex/ na raiz do repositório.*.vex.json, *.csaf.json) são considerados.Para informações detalhadas sobre o processo de descoberta, ecossistemas suportados e requisitos específicos, consulte a [documentação do vex-crawler][vexhub-crawler].
O VEX Hub é estruturado com base no Package URL (PURL), excluindo version, qualifiers e subpath.
A estrutura segue as seguintes regras:
oci, o qualificador repository_url é usado em seu lugar.products dos documentos VEX.Exemplos de formação da estrutura de diretórios:
pkg:npm/express → /npm/express/pkg:golang/github.com/gorilla/mux → /golang/github.com/gorilla/mux/pkg:maven/org.apache.xmlgraphics/batik-anim → /maven/org.apache.xmlgraphics/batik-anim/pkg:oci/trivy?repository_url=ghcr.io/aquasecurity/trivy → /oci/ghcr.io/aquasecurity/trivy/Exemplo com codificação de caracteres especiais:
pkg:npm/@angular/core → /npm/%40angular/core/O VEX Hub está em conformidade com a [Especificação do Repositório VEX][vex-repo-spec]. Os arquivos vex_repository.json e index.json podem ser usados para acessar programaticamente os documentos VEX no VEX Hub.
O VEX Hub tem a capacidade de armazenar múltiplos documentos VEX para um único PURL, pois copia todos os documentos VEX correspondentes do repositório de origem. No entanto, a Especificação do Repositório VEX permite apenas um documento VEX por PURL. Para estar em conformidade com essa especificação, o VEX Hub implementa a seguinte estratégia de distribuição:
Para evitar confusão e garantir consistência, dividir declarações VEX para o mesmo PURL em múltiplos arquivos não é recomendado, pois o VEX Hub distribui apenas um arquivo VEX por PURL.
As abordagens recomendadas são:
Exemplo de cenário:
Considere um repositório de origem https://github.com/org/repo que mantém dois produtos: um módulo Go e uma imagem OCi.
A primeira abordagem é criar um único arquivo VEX, vex.json, contendo declarações VEX para ambos os produtos.
openvex.json: Para ambos os produtos, com os PURLs pkg:golang/github.com/org/repo, pkg:oci/repo?repository_url=docker.io/org/repo e pkg:oci/repo?repository_url=ghcr.io/org/repoA segunda abordagem é criar arquivos VEX separados para cada produto.
golang.vex: Para o módulo Go, com o PURL pkg:golang/github.com/org/repooci.vex: Para a imagem OCI, com os PURLs pkg:oci/repo?repository_url=docker.io/org/repo e pkg:oci/repo?repository_url=ghcr.io/org/repoA seguinte estrutura não é recomendada:
v1.vex: Para o módulo Go, com o PURL pkg:golang/github.com/org/[email protected]v2.vex: Para o módulo Go, com o PURL pkg:golang/github.com/org/[email protected]Neste exemplo, v1.vex é selecionado para distribuição, e v2.vex é ignorado.
Eles devem ser combinados em um único arquivo VEX, golang.vex, com múltiplas versões e qualificadores.
Como o VEX Hub (e o VEX em geral) potencialmente complementa os resultados de varredura de segurança, você tem todo o direito de examinar a exatidão dos documentos VEX que consome. Diferente de outros feeds de Vulnerability Exchange, ou feeds de avisos de segurança prontos para VEX, o VEX Hub não é a fonte de dados das declarações VEX. O VEX Hub apenas agrega documentos VEX existentes e os organiza em um repositório central e conveniente.
Para aparecer no VEX Hub, os documentos VEX precisam ser commitados no repositório de código-fonte do pacote principal primeiro. Essa abordagem se baseia no fato de que, como usuário, você já deve confiar nos pacotes que usa e, portanto, nos mantenedores, na governança e nos processos que eles empregam. Cada projeto tem seu próprio sistema de governança e seus próprios processos para commit no repositório de código-fonte. Esses sistemas e processos que tornam o código do pacote confiável aos seus olhos são os mesmos sistemas e processos que tornam os documentos VEX confiáveis para você. Você não deve confiar no VEX Hub mais do que confia nos pacotes que escolhe usar.