Saltar para o conteúdo principal
Os analisadores de SCA do ZeroPath reconhecem os seguintes ecossistemas de fábrica:

npm / Yarn / pnpm

PyPI

Go modules

Maven / Gradle / SBT

NuGet

RubyGems

crates.io (Cargo)

Packagist / Composer

Hex (Elixir)

Pub (Dart/Flutter)

Swift

Haskell (Hackage)

R (CRAN)

Cada registro de dependência rastreia se o ZeroPath a viu declarada diretamente ou trazida transitivamente, para que você possa aplicar políticas diferentes a escolhas próprias e a bibliotecas de terceiros. Dependências de desenvolvimento e opcionais declaradas nos seus manifestos também são inventariadas; a alcançabilidade ajuda a separar descobertas relevantes em runtime do ruído exclusivo de desenvolvimento.

​
Como a resolução funciona

O ZeroPath resolve seu grafo de dependências diretamente a partir dos seus manifestos sempre que possível, sem exigir etapa de build ou contêiner, e recorre ao seu lockfile commitado em todos os outros casos. O contrato prático é por ecossistema, resumido na tabela abaixo. Duas regras valem em todos os lugares:
  • Dependências diretas são escaneadas mesmo quando o grafo transitivo não pode ser construído. O ZeroPath registra e compara com vulnerabilidades os pacotes que você declarou diretamente, então um lockfile ausente custa a profundidade transitiva, não as suas descobertas diretas.
  • Versões desconhecidas não são adivinhadas. Se uma versão não pode ser determinada, por exemplo um intervalo não resolvido ou uma cadeia de pais quebrada, o pacote ainda é registrado no seu inventário e SBOM, mas não é comparado com vulnerabilidades. Isso evita falsos positivos causados por versões adivinhadas.

​
Cobertura sem um lockfile commitado

Para cada ecossistema marcado como Apenas dependências diretas, um lockfile ausente significa que as dependências transitivas não são resolvidas e os especificadores de intervalo permanecem ambíguos, prejudicando o pareamento de vulnerabilidades transitivas e a completude do SBOM. O ZeroPath ainda registra suas dependências diretas e sinaliza o manifesto com um aviso Transitive dependencies unresolved para que a lacuna fique visível. Veja Cobertura e avisos para saber como resolvê-la, incluindo os comandos para gerar cada lockfile.
Para npm/Yarn/pnpm, Maven e um requirements.txt totalmente fixado com ==, um lockfile commitado é opcional — ele apenas torna os scans mais rápidos e mais determinísticos.

​
Artefatos compilados e vendorizados

Artefatos JVM binários commitados no seu repositório, como JARs e WARs, são escaneados em busca dos pacotes embutidos dentro deles. Esses pacotes aparecem no seu inventário ao lado das dependências declaradas em código-fonte, com um selo de tipo de origem Compiled (por exemplo, JAR, WAR), para que você veja bibliotecas vendorizadas ou pré-compiladas que uma análise apenas de manifestos deixaria passar. O inventário de Dependencies permite filtrar por Source Type para isolar descobertas compiladas vs. declaradas em código-fonte.

​
Notas por ecossistema

O ZeroPath trata o sufixo +incompatible usado por pacotes Go pré-módulos (versão principal 2+), pareando versões como v3.2.0+incompatible com advisories conhecidos. Pseudo-versões do Go (por exemplo, v0.0.0-20231215084216-abcdef123456) são snapshots de commit, não releases publicados, então o ZeroPath as registra no inventário mas não tenta parear versões de advisories com elas.
Builds multi-módulo (reactor) são totalmente resolvidos: o ZeroPath indexa cada POM no repositório e resolve referências <parent> entre módulos mesmo quando <relativePath/> está vazio ou ausente, de modo que um filho pode herdar versões de <dependencyManagement> do pai de um irmão. POMs pai que declaram dependências apenas em <dependencyManagement> são capturados, e artefatos com classifier são atribuídos ao pacote correto. Quando um POM pai não pode ser resolvido local ou remotamente, versões herdadas por meio dessa cadeia são tratadas como não resolvidas em vez de adivinhadas.
Além das declarações simples em build.gradle(.kts), o ZeroPath também reconhece dependências declaradas por meio de catálogos de versões (libs.versions.toml), convention plugins, restrições de platform/BOM e o Kotlin DSL. Faça commit de gradle.lockfile (./gradlew dependencies --write-locks) para a árvore transitiva completa.
O ZeroPath registra dependências diretas a partir do build.sbt e analisa um lockfile commitado para a árvore transitiva completa: build.sbt.lock (sbt-dependency-lock) ou lock.sbt (sbt-lock).
Os ids de pacote são pareados sem diferenciar maiúsculas de minúsculas, então diferenças de capitalização entre um manifesto e o registro nunca causam uma perda. Opte pelo modo de lockfile do NuGet e faça commit de packages.lock.json (dotnet restore --use-lock-file --force-evaluate, NuGet 4.9+) para cobertura transitiva.
Crates binários commitam Cargo.lock por padrão, e o ZeroPath o usa diretamente. Crates de biblioteca comumente o omitem (conforme a orientação do Cargo); faça commit de Cargo.lock (cargo generate-lockfile) para cobertura transitiva. Um crate que resolve para múltiplas versões no mesmo grafo é reportado como pares (name, version) separados, de modo que cada um chega ao pareamento com advisories.
Todos os formatos comuns são suportados:
  • requirements.txt — formato padrão do pip
  • Pipfile — Pipenv ([packages] / [dev-packages])
  • pyproject.toml (Poetry) — incluindo dependências de grupo do 1.2+
  • pyproject.toml (PEP 621) — a tabela [project] usada por uv, hatch, flit, setuptools e pdm (tanto dependencies quanto optional-dependencies)
Cada descoberta registra a posição de um pacote no grafo (direto ou transitivo) e a cadeia que o introduziu, e linka de volta para o arquivo de manifesto e a linha exatos onde a dependência foi declarada, em vez do lockfile. Um pacote alcançado por múltiplos caminhos de dependência é deduplicado em uma única entrada de inventário, de modo que as contagens refletem pacotes únicos. Veja Raio de impacto para saber como a cadeia de dependência se torna impacto em pontos de chamada durante um upgrade.