Glossary

An open-source tool and format for tracking, analyzing, and managing software vulnerabilities reported by SCA scanners. The name combines "vulnerability" and "log." The term refers to both the YAML file format and the CLI tool.

A YAML file following the Vulnlog specification, identified by the .vl.yaml (or .vl.yml) file extension. Simple projects may use vulnlog.yaml (or vulnlog.yml). Each Vulnlog file is scoped to a single release branch.

The command-line interface tool that reads Vulnlog files and generates output artifacts (suppression files, HTML reports).

A single record in the vulnerabilities section of a Vulnlog file. Captures a finding (what was found, where, by whom) and the human verdict about it.

The primary identifier of a vulnerability entry, stored in the id field. Must be unique across all entries and aliases within the file. Preferably a CVE identifier (e.g., CVE-2021-44228).

An alternative identifier for the same vulnerability, stored in the aliases array. Must not overlap with any id or aliases in other entries within the same file. Used for cross-referencing in reports but not for suppression file generation.

The human triage decision recorded for a vulnerability entry, stored in the verdict field. The term reflects a deliberate judgment by an engineer, distinct from automated scanner statuses. Possible values: affected, not affected, risk acceptable. When absent, the vulnerability is considered under investigation. See Verdicts and Justifications.

The implicit state of a vulnerability entry when no verdict has been set.

The free-text rationale for the triage decision, stored in the analysis field. Records why the team reached the verdict.

The reason why a vulnerability does not affect the project, stored in the justification field. Required when the verdict is not affected. Values align with the OpenVEX justification vocabulary. See Justification Values.

The assessed severity of a vulnerability. Values: critical, high, medium, low. Required when the verdict is affected or risk acceptable.

A structured record that a dependency update or other corrective action was taken, stored in the resolution block. Independent of the verdict — a vulnerability may be not affected yet still have a resolution.

A record in the reports array indicating that a specific scanner or source reported the finding. Not to be confused with HTML report (an output artifact).

The reporter field on a report entry, identifying the scanner or source. A fixed enum (e.g., trivy, snyk, dependency-check, other). Determines the suppression file format.

A directive to exclude a vulnerability from a scanner’s findings. Can be temporary (with expires_at) or permanent (without expires_at). See Suppression.

A file generated by the Vulnlog CLI that instructs an SCA scanner to suppress specific findings. Each scanner has its own format.

The project section of a Vulnlog file. Contains metadata: organization, project name, author, and optional contact.

A software release tracked in the releases section. Releases must be listed in chronological order (oldest first) because the CLI uses array position for range resolution.

A line of releases sharing a common major/minor version. Each Vulnlog file is scoped to a single release branch. See Branching Strategy for how to organize files across branches.

A label defined in the optional tags section. Provides flexible categorization for deliverables, usage contexts, or any team-specific taxonomy. See Tags and Filtering.

A standardized format for identifying software packages. Examples: pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1, pkg:docker/demo-project@8.1.1.

An HTML file for communicating vulnerability analysis to stakeholders. Each vulnerability entry corresponds to a single row.

A minimal vulnerability entry containing only required fields (id, releases, packages, reports). Created during quick triage.