> ## Documentation Index
> Fetch the complete documentation index at: https://zeropath.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Ecossistemas Suportados
> Quais ecossistemas de pacotes o ZeroPath analisa, e o que cada um precisa para cobertura transitiva completa
Os analisadores de SCA do ZeroPath reconhecem os seguintes ecossistemas de
fábrica:
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](/pt/sca/reachability) 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
| Ecossistema | Sem um lockfile commitado |
| ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| npm / Yarn / pnpm | **Cobertura transitiva completa** — resolvida diretamente do `package.json` |
| Maven (`pom.xml`) | **Cobertura transitiva completa** — resolvida deterministicamente a partir dos seus POMs (pai, BOM e propriedades); nenhum lockfile necessário |
| Python (`requirements.txt`, totalmente fixado com `==`) | **Resolvido como está** — cada pacote fixado é escaneado (um arquivo de `pip freeze` / `pip-compile` já lista as transitivas) |
| Python (`pyproject.toml`, `Pipfile`, `requirements.txt` parcialmente fixado) | **Apenas dependências diretas** — gerencie via `pyproject.toml`/`Pipfile` e faça commit de `poetry.lock`, `uv.lock` ou `Pipfile.lock` (ou fixe tudo com `==`) |
| Go modules | **Apenas dependências diretas** — faça commit de `go.sum` (`go mod tidy`) |
| Gradle (`build.gradle`, `.kts`) | **Apenas dependências diretas** — faça commit de `gradle.lockfile` |
| SBT (`build.sbt`) | **Apenas dependências diretas** — faça commit de `build.sbt.lock` ou `lock.sbt` |
| Cargo (`Cargo.toml`) | **Apenas dependências diretas** — faça commit de `Cargo.lock` |
| NuGet (`*.csproj`, `*.fsproj`, `*.vbproj`) | **Apenas dependências diretas** — faça commit de `packages.lock.json` |
| Ruby | **Apenas dependências diretas** — faça commit de `Gemfile.lock` |
| PHP | **Apenas dependências diretas** — faça commit de `composer.lock` |
| Elixir | **Apenas dependências diretas** — faça commit de `mix.lock` |
| Dart / Flutter | **Apenas dependências diretas** — faça commit de `pubspec.lock` |
| Swift | **Apenas dependências diretas** — faça commit de `Package.resolved` |
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](/pt/sca/coverage) para saber como resolvê-la, incluindo os
[comandos para gerar cada lockfile](/pt/sca/coverage#generate-lockfiles-before-scanning).
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 `` entre módulos mesmo
quando `` está vazio ou ausente, de modo que um filho pode
herdar versões de `` do pai de um irmão. POMs pai que
declaram dependências apenas em `` 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](https://github.com/stringbean/sbt-dependency-lock)) ou
`lock.sbt` ([sbt-lock](https://github.com/tkawachi/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](/pt/sca/blast-radius) para saber como a cadeia de dependência
se torna impacto em pontos de chamada durante um upgrade.