Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Map SARIF result locations onto the map with a tool-neutral location annotation

Aperta
  • Qualcosa non va?
#82 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
cli

Direzione di ricerca

Start with the map and stable-ID work in #74 and the golden-corpus entries in #75, then trace the existing CLI capability and guide listings. Define the dircue locate boundaries from the proposal and acceptance checklist; done means bounded SARIF annotation, snapshot-aware ownership results, preserved properties, passing edge-case fixtures, and listings under capabilities --cli and --guide.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement follow-up

Why

Many kinds of tools emit SARIF: linters, compiler analyzers, structural/metrics tools, BCA, OWASP Noir and others. They all report results as file and region locations.

Anyone consuming those results keeps needing the same answer: which component, deployable or entry point does this location belong to? They need it to route, group, count or assign results. Each consumer re-implements that join with path-prefix guesses, which break on monorepos, nested projects, generated/vendored code and multi-service layouts.

The dircue map (#74) already knows the ownership. This utility applies it to any SARIF log without interpreting what the results mean. It is tool-neutral glue, not scanning.

Proposal

A dircue locate command. The name is a proposal. It should:

  • Inputs: a SARIF 2.1.0 log, treated as untrusted input, plus either a saved map document or a source to map on the fly.
  • Default output: the same SARIF log. Each result location is annotated in a namespaced property bag (e.g. properties["dircue.map"]) with:
    • component ID(s) and deployable ID(s);
    • an interface ID, when the region falls inside a known interface span;
    • the content role (source, test, generated, vendored, …);
    • a resolution status: resolved, ambiguous (several owners), outside_root, not_in_snapshot or unresolvable_uri.
  • --format summary: per map node, counts of located results by tool (name and version only).

Rules

  • Tool-neutral. Never read, interpret, filter, rank, deduplicate or rewrite a result's ruleId, level, kind, rank, message, rules or properties. There is no severity, grouping by rule, or verdict. Unknown properties pass through unchanged.
  • URI handling:
    • originalUriBaseIds/uriBaseId;
    • relative, absolute and file:// URIs;
    • percent-encoding and Windows paths;
    • case sensitivity per source;
    • confinement to the map root.
    • Host paths from the input are not echoed anywhere new.
  • Snapshot binding. Compare the run's versionControlProvenance (repository and revision), or a supplied digest, with the map's source identity. A mismatch or unknown binding is reported per run. Results are never silently attributed across different snapshots.
  • Bounded and streaming. Limits on log size, runs, results and locations. No execution, no network. Deterministic output.

Acceptance

  • Fixtures from at least three emitters of different kinds (e.g. a linter, BCA, Noir) on golden-corpus entries (#75).
  • Synthetic edge cases:
    • URI base IDs;
    • locations outside the root;
    • ambiguous ownership;
    • generated/vendored paths;
    • mismatched revisions;
    • very large logs.
  • Ownership correctness measured against hand-written expectations.
  • Annotated output validates against the SARIF 2.1.0 schema and preserves all original properties.
  • Listed in capabilities --cli and --guide.

Related: #74 (map and stable IDs), #77 (SARIF run metadata feeding the coverage ledger), #78 (coverage ledger). Epic: #81. Scope decided by the owner on 2026-09-22: in scope for 1.0.

Lingua principale
Go
Stelle
0
Fork
0
Merge medio
5h 8m
PR unite (30g)
54

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di war-and-code/dircue

Tutte le issue di war-and-code/dircue

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.