Quickstart: triage your first finding

In about ten minutes you create a Vulnlog file, record a scanner finding with your verdict, and generate a suppression file that silences the finding in your scanner.

Prerequisites

  • The Vulnlog CLI is installed (see Install Vulnlog).

  • A finding from an SCA scanner to work with. This quickstart uses a Trivy finding for CVE-2026-1234 in the npm package example-lib; substitute your own scanner and finding as you go.

Step 1: Create the Vulnlog file

Run vulnlog init in the root of your repository:

vulnlog init --organization "Acme Corp" --name "Acme Web App" --author "Acme Corp Security Team" -o vulnlog.yaml
Created: vulnlog.yaml

The file contains the project metadata and empty releases and vulnerabilities sections.

Step 2: Record your release

Vulnerability entries reference the releases they affect, so the file needs at least one release. Open vulnlog.yaml and replace releases: [] with your current version:

releases:
  - id: 1.0.0
    published_at: 2026-01-15

Step 3: Record the finding

Record what the scanner reported, before any analysis:

vulnlog modify add vulnlog.yaml --vuln-id CVE-2026-1234 \
  --package "pkg:npm/example-lib@2.3.0" \
  --reporter trivy \
  --description "Remote code execution in example-lib"
Added: CVE-2026-1234 to vulnlog.yaml

The entry starts without a verdict, so Vulnlog tracks it as under investigation. The report is dated with the current date.

Step 4: Record your verdict

Analyse the finding, then record the outcome. In this example the vulnerable code path is not reachable, so the verdict is not affected:

vulnlog modify add vulnlog.yaml --vuln-id CVE-2026-1234 \
  --analysis "The vulnerable code path is not reachable in our application because we only use the safe subset of the API." \
  --verdict "not affected" \
  --justification "vulnerable code not in execute path"
Updated: CVE-2026-1234 in vulnlog.yaml

The entry in vulnlog.yaml now reads:

  - id: CVE-2026-1234
    description: Remote code execution in example-lib
    releases: [1.0.0]
    packages: ["pkg:npm/example-lib@2.3.0"]
    reports:
      - reporter: trivy
        at: 2026-07-10
    analysis: >-
      The vulnerable code path is not reachable in our application because we only use the safe subset of the API.
    verdict: not affected
    justification: vulnerable code not in execute path

Step 5: Validate the file

vulnlog validate vulnlog.yaml
Validated: vulnlog.yaml

Step 6: Generate the suppression file

vulnlog suppress vulnlog.yaml
Wrote: /path/to/.trivyignore.yaml

Because the verdict is not affected, the finding is included automatically:

---
vulnerabilities:
- id: CVE-2026-1234
  statement: The vulnerable code path is not reachable in our application because
    we only use the safe subset of the API.

Point Trivy at this file and the finding disappears from the scan, while your analysis stays in vulnlog.yaml.

Step 7: Commit the decision

git add vulnlog.yaml
git commit -m "Triage CVE-2026-1234: not affected"

The git history is now the audit trail for the decision.

What you did

You created a Vulnlog file and recorded an entry for a scanner finding: first the facts (package, report), then your judgment (verdict and justification) with the analysis explaining it. From that single source Vulnlog generated a suppression file for the scanner, and the commit preserved the decision for everyone who asks later.

Next steps