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 Testaroo 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.
Generated by generation/supply_chain.py. Free for any use, no attribution required, license.
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.
