Ingest deeper-tool facts and run coverage into the map: Syft, OWASP Noir, Bifrost and SARIF run metadata

Abierto
  • ¿Algo no está bien?
#77 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go, json
Área
cli, devtools, tooling

Línea de trabajo

Start by reading internal/cli/packages.go and associate.go to understand the existing Syft association path. Then inspect dircue map --attach (#76), the golden-corpus fixtures in #75, and the map node/edge expectations in #74. Done means the specified reports produce attributed nodes and edges, preserve run coverage, and detect mismatched snapshots without importing findings.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement follow-up

Why

dircue should be the glue between deeper open-source analyzers, not a re-implementation of them, and not a security scanner. It takes facts from other tools (what exists, and how things relate) and run coverage (what each tool actually looked at). It does not take their findings, verdicts or severities; those stay with the producing tool and whatever system consumes them. The value lies between them:

  • binding each tool's output to the exact snapshot;
  • attributing its facts to components, deployables and interfaces;
  • keeping what each tool reports separate from what dircue observed.

Today dircue can import native Syft JSON, but it associates packages only with the nearest ancestor project root of the legacy projects population (internal/cli/packages.go, associate.go). It never matches Syft packages or PURLs against declared requirements, and Syft artifactRelationships never become edges. There is no SARIF support anywhere in the tree.

Scope for 1.0

Ingestion of supplied reports comes first. Running tools stays an explicit, separate opt-in (#21, #69).

Provider What to ingest Attach to
Syft JSON (existing importer) packages, PURLs, locations (primary/supporting), artifactRelationships (contains, dependency-of), source metadata package nodes; packaged_in/depends_on edges to components, matched via declared requirements (npm, Go, Cargo, pyproject/uv, PackageReference, Maven, Gradle), with nearest-root as a fallback basis; vendored subtrees
SARIF 2.1.0 (any emitter: linters, structural/metrics tools, BCA, Noir, others) run metadata only: tool.driver name/version, artifacts, invocations, toolExecutionNotifications, versionControlProvenance tool_run nodes and analyzed_by edges for the coverage ledger (#78). Results are not imported into the map; their locations can be mapped to map nodes with #82.
OWASP Noir JSON endpoints (method, path, params, file/line) interface nodes with basis provider_reported, attached to components and deployables; conflicts with declared contracts (#56) recorded as conflicts_with
Bifrost JSON (optional, per #24) answers to selected structural queries (callers/callees, references) evidence edges for specific questions, e.g. whether a handler reaches a capability; never a claim of complete call-graph coverage

Report qualified disagreements between facts, never verdicts:

  • declared but absent from the SBOM;
  • in the SBOM but undeclared;
  • a Noir endpoint with no declared contract;
  • a declared operation with no observed route.

Rules

  • Reports are untrusted input: bounded parsing, no execution, no network. Paths are normalized and confined to the map root. Host paths and credentials are redacted.
  • Source binding: a report is tied to the snapshot by the supplied digest/tree identity or provider provenance. A mismatch downgrades attribution; it isn't silently accepted.
  • Never re-derive what a provider reported. dircue emits no vulnerability, risk or policy conclusions of its own, and doesn't aggregate other tools' findings.

Result locations

Mapping any SARIF result's location to its component, deployable or interface is in scope as a separate, tool-neutral utility: #82 (owner decision, 2026-09-22). It annotates locations without interpreting rule semantics or severity. This issue stays limited to facts and run coverage.

Acceptance

  • Fixtures from real, pinned tool runs on golden-corpus entries (#75): Syft on everything; Noir on the web-framework entries; Bifrost on a subset; at least one SARIF emitter for run-coverage metadata.
  • Attribution precision/recall measured against hand-written expectations.
  • A mismatched-snapshot report is detected and qualified.
  • Works through dircue map --attach … (#76) and produces map nodes/edges (#74).

Related: #20, #21, #24, #26, #57. Epic: #81.

Lenguaje dominante
Go
Estrellas
0
Forks
0
Merge medio
11 h 3 min
PR fusionados (30 d)
5

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de war-and-code/dircue

Todos los issues de war-and-code/dircue

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.