Grype Table Console Output
The console table a scanner prints, in fixed-width columns — the output people actually paste into tickets, and the one a log scraper has to parse without a delimiter. Advisory identifiers use the invented NOVUS-SAMPLE namespace with SAMPLE-CVE aliases; no identifier here refers to a published CVE, GHSA or OSV record, and no package named exists.
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
example-logger 3.4.1 3.5.0 npm NOVUS-SAMPLE-2026-0001 High
example-cache 0.9.2 0.9.5 npm NOVUS-SAMPLE-2026-0002 Critical
example-yaml-lite 1.1.7 1.2.0 npm NOVUS-SAMPLE-2026-0003 Medium
example-json-path 2.0.5 2.1.0 npm NOVUS-SAMPLE-2026-0004 Low
Specifications
- Seed
- 51200
- Sample Only
- true
- Scanner
- Grype-shaped
- Format
- fixed-width columns
- Columns
- 6
- Rows
- 4
- Line Endings
- LF
Testing contract
Reference control- Scenario
- Scrape findings out of fixed-width console output rather than JSON.
- Expected result
- Four rows parse into name, installed version, fixed version, type, advisory id and severity, matching the JSON report field for field.
What is a .txt file?
TXT is a plain-text file containing unformatted character data with no styling or structure beyond line breaks. Its interpretation depends on character encoding, most commonly UTF-8, and on line-ending convention. It is the most universal and portable text container.
How to use this file
Use an example TXT to test encoding detection, line-ending (LF versus CRLF) handling, and any tool that reads or streams raw text input.
How to use this file for testing
“Grype Table Console Output” is a deterministic Novus Examples fixture for Log parsing, Conversion testing, Error handling. Access logs and JSON-lines application logs — for testing log parsers, tailers, and ingestion pipelines.
Documented properties for this file: seed 51200 · 4 rows · 6 columns · LF. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
SBOM, lockfile, provenance, and advisory fixtures describe the same fabricated component tree across formats, so a converter or scanner can be diffed against a known answer. Every package name, version, hash, and advisory ID is invented — never treat a finding here as real.
Related files
- xmlCucumber JUnit XML — Checkout RunThe same six pickles reported as JUnit XML, which is what a BDD suite hands to a generic CI dashboard. One <testcase> per pickle means the three expanded outline rows appear as three tests with identical names — enough to break any store keyed on name alone.
- xmlFlaky Run — Network Dependency, Build #301 (errored)Build #301 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is errored while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
- xmlFlaky Run — Network Dependency, Build #302 (passing)Build #302 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is passing while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
- xmlFlaky Run — Network Dependency, Build #303 (passing)Build #303 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is passing while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
- xmlFlaky Run — Network Dependency, Build #304 (passing)Build #304 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is passing while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
- xmlFlaky Run — Network Dependency, Build #305 (errored)Build #305 of five consecutive runs of checkout.PaymentTest, in which capturesAuthorisedPayment is errored while the other five cases pass every time. The underlying cause is a real call to the fictional payments host instead of the stub. Read the whole family in build order to reproduce what a flake detector sees.
Generated by generation/supply_chain.py. Free for any use, no attribution required — license.