Glossary
A
Artifact
In Syft’s JSON output format, “artifacts” refers to the array of software packages discovered during scanning. Each artifact represents a single package (library, application, OS package, etc.) with its metadata, version, licenses, locations, and identifiers like CPE and PURL. This is distinct from general software artifacts like binaries or container images.
Related documentation: Working with Syft JSON
Attestation
A cryptographically signed statement about a software artifact that provides verifiable claims about its properties, such as provenance, build process, or security scan results. Attestations establish trust in the software supply chain by allowing you to verify that an SBOM truly represents a specific artifact or that vulnerability scan results are authentic.
Why it matters: Attestations enable you to verify the authenticity and integrity of SBOMs generated by Syft and vulnerability reports from Grype, ensuring they haven’t been tampered with.
C
Cataloger
A cataloger is a component within Syft that specializes in discovering and extracting package information from specific ecosystems or file formats.
Each cataloger knows how to find and parse packages for a particular type (e.g., apk-cataloger for Alpine packages, npm-cataloger for Node.js packages).
When Syft scans a target, it runs multiple catalogers to comprehensively discover all software components.
Why it matters: The foundBy field in Syft’s JSON output tells you which cataloger discovered each package, which can help debug why certain packages appear in your SBOM or troubleshoot scanning issues.
Related documentation: Working with Syft JSON
Container image
A lightweight, standalone, executable package that includes everything needed to run a piece of software, including the code, runtime, system tools, libraries, and settings. Container images are built from layers and typically run using container runtimes like Docker or containerd. See also OCI.
Why it matters: Both Syft and Grype can scan container images directly without requiring them to be running. Syft generates SBOMs from container images, and Grype scans them for vulnerabilities.
Related documentation: SBOM Generation, Vulnerability Scanning
CPE
Common Platform Enumeration (CPE) is a standardized method for describing and identifying software applications, operating systems, and hardware devices. CPEs are used in vulnerability databases to match software components with known vulnerabilities.
Formats:
- URI binding:
cpe:/{part}:{vendor}:{product}:{version}:{update}:{edition}:{language} - Formatted string:
cpe:2.3:{part}:{vendor}:{product}:{version}:{update}:{edition}:{language}:{sw_edition}:{target_sw}:{target_hw}:{other} - Well-Formed Name (WFN):
cpe:2.3:wfn:[attributes]
Examples:
cpe:/a:mozilla:firefox:68.0::~~~en-us~~cpe:2.3:a:microsoft:internet_explorer:8.0.6001:beta:*:*:*:*:*:*wfn:[part="a", vendor="microsoft", product="internet_explorer",version="8\.0\.6001", update="beta", edition=ANY, language=ANY]
Why it matters: Syft generates CPEs for discovered packages (from the NVD dictionary or synthetic generation), which Grype then uses to match packages against vulnerability data. Understanding CPEs helps you troubleshoot why certain vulnerabilities are or aren’t being detected relative to vulnerabilities from NVD.
External resources:
Related documentation: Working with Syft JSON
CVE
Common Vulnerabilities and Exposures (CVE) is a standardized identifier for publicly known security vulnerabilities. Each CVE ID uniquely identifies a specific vulnerability and provides a common reference point for discussing and tracking security issues.
Format example: CVE-2024-12345
Why it matters: Grype reports vulnerabilities by their CVE IDs, making it easy to research specific issues, understand their impact, and find remediation guidance. Each match in a Grype scan references one or more CVE IDs.
External resources:
Related documentation: Vulnerability Scanning
CVSS
Common Vulnerability Scoring System (CVSS) is an open framework for communicating the characteristics and severity of software vulnerabilities. CVSS (base) scores range from 0.0 to 10.0, with higher scores indicating more severe vulnerabilities.
Severity ranges:
- None: 0.0
- Low: 0.1-3.9
- Medium: 4.0-6.9
- High: 7.0-8.9
- Critical: 9.0-10.0
There are more dimensions to CVSS, including Temporal and Environmental scores, but the Base score is the most commonly used as a way to quickly assess severity.
Why it matters: Grype uses CVSS scores to categorize vulnerability severity, helping you prioritize which issues to fix first. You can filter Grype results by severity level to focus on the most critical vulnerabilities.
External resources:
Related documentation: Vulnerability Scanning
CycloneDX
CycloneDX is an open-source standard for creating Software Bill of Materials (SBOMs), supporting JSON and XML representations.
Why it matters: Syft can generate SBOMs in CycloneDX format (-o cyclonedx-json or -o cyclonedx-xml), which is widely supported by security tools and compliance platforms.
Grype can also scan CycloneDX SBOMs for vulnerabilities.
External resources:
Related documentation: SBOM Generation
D
Dependency
A software component that another piece of software relies on to function. Dependencies can be direct (explicitly required by your code) or transitive (required by your dependencies). Understanding and tracking dependencies is crucial for security and license compliance.
Why it matters: Syft catalogs both direct and transitive dependencies in your software, creating a complete inventory. Grype then scans all dependencies for vulnerabilities, not just your direct dependencies—important because transitive dependencies often contain hidden security risks.
Distro
Short for “distribution”, referring to a specific Linux distribution like Alpine, Ubuntu, Debian, or Red Hat. The distro information includes the distribution name and version (e.g., “alpine 3.18”).
Why it matters: Grype uses distro information to match OS packages against the correct vulnerability database.
Syft automatically detects the distro from files like /etc/os-release and includes it in the SBOM, ensuring accurate vulnerability matching.
Related documentation: Working with Syft JSON
Docker
Docker is a platform for developing, shipping, and running applications in containers. While Docker is a specific implementation, the term is often used colloquially to refer to container technology in general. See Container image and OCI.
Why it matters: Syft and Grype can pull and scan images directly from Docker registries or analyze images in your local Docker daemon without needing Docker to be installed.
External resources:
E
Ecosystem
In software, an ecosystem refers to a package management system and its associated community, tools, and conventions. Examples include npm (JavaScript), PyPI (Python), Maven Central (Java), and RubyGems (Ruby). Different ecosystems have different package formats, naming conventions, and vulnerability data sources.
Why it matters: Syft supports dozens of package ecosystems, and each uses a different cataloger. The ecosystem determines how packages are identified (PURL type), which metadata is captured, and which vulnerability data sources Grype uses for matching.
Related documentation: SBOM Generation
EPSS
Exploit Prediction Scoring System (EPSS) is a data-driven framework that estimates the probability that a software vulnerability will be exploited in the wild within the next 30 days. EPSS scores range from 0 to 1 (or 0% to 100%), with higher scores indicating a greater likelihood of exploitation based on real-world threat intelligence.
Unlike CVSS which measures theoretical severity, EPSS predicts actual exploitation probability by analyzing factors like available exploits, social media activity, and observed attacks (among other signals).
Why it matters: EPSS helps you prioritize vulnerabilities more effectively than severity alone. A critical CVSS vulnerability with a low EPSS score might be less urgent than a medium severity issue with a high EPSS score. Grype can display EPSS scores alongside CVSS to help you focus remediation efforts on vulnerabilities that are both severe and likely to be exploited.
External resources:
Related documentation: Vulnerability Scanning
F
False positive
In the context of scanning for vulnerabilities, a false positive is a vulnerability-package match reported by a scanner that doesn’t actually affect the software package in question. False positives can occur due to incorrect CPE matching, version misidentification, or when a vulnerability applies to one variant of a package but not another.
Why it matters: When Grype reports a false positive, you can use VEX documents or Grype’s ignore rules to suppress it, preventing alert fatigue and focusing on real security issues.
False negative
In the context of scanning for vulnerabilities, a false negative occurs when a scanner fails to detect a vulnerability that actually affects a software package. False negatives can happen when vulnerability data is incomplete, when a package uses non-standard naming or versioning, when CPE or PURL identifiers don’t match correctly, or when the vulnerability database hasn’t been updated yet.
Why it matters: False negatives are more dangerous than false positives because they create a false sense of security. To minimize false negatives, keep Grype’s vulnerability database updated regularly and understand that no scanner catches 100% of vulnerabilities—defense in depth and multiple security controls are essential.
K
KEV
Known Exploited Vulnerability (KEV) is a designation for vulnerabilities that have been confirmed as actively exploited in real-world attacks. CISA (Cybersecurity and Infrastructure Security Agency) maintains the authoritative KEV catalog, which lists CVEs with evidence of active exploitation and provides binding operational directives for federal agencies.
The CISA KEV catalog includes:
- CVE identifiers for exploited vulnerabilities
- The product and vendor affected
- A brief description of the vulnerability
- Required remediation actions
- Due dates for federal agencies to patch
Vulnerabilities are added to the KEV catalog based on reliable evidence of active exploitation, such as public reporting, threat intelligence, or incident response data.
Why it matters: KEV status is a strong signal for prioritization—these vulnerabilities are being actively exploited right now. When Grype identifies a vulnerability that’s on the CISA KEV list, you should treat it as urgent regardless of CVSS score. A medium-severity KEV vulnerability poses more immediate risk than a critical-severity vulnerability that’s never been exploited. Some organizations make KEV remediation mandatory within tight timeframes (e.g., 15 days for critical KEVs).
External resources:
Related documentation: Vulnerability Scanning
L
Layer
Container images are built as a series of filesystem layers, where each layer represents changes from a Dockerfile instruction. Layers are stacked together to create the final filesystem.
Why it matters: By default, Syft scans only the “squashed” view of an image (what you’d see if the container were running).
Use --scope all-layers to scan all layers, which can reveal packages that were installed then deleted, potentially exposing vulnerabilities in build-time dependencies.
Related documentation: SBOM Generation
License
A legal instrument governing the use and distribution of software. Software licenses range from permissive (MIT, Apache) to copyleft (GPL) to proprietary.
Why it matters: Syft extracts license information from packages and includes it in SBOMs, helping you ensure compliance with open source licenses and identify packages with incompatible or restricted licenses.
M
Match
A match is a vulnerability finding in Grype’s output, representing a single package-vulnerability pair. Each match indicates that a specific package version is affected by a particular CVE.
Related documentation: Vulnerability Scanning
Matcher
A matcher is a component within Grype that compares package information against vulnerability data using specific matching strategies. Different matchers handle different package types or ecosystems (e.g., distro matcher for OS packages, language matcher for application dependencies).
Why it matters: Grype uses multiple matchers to ensure comprehensive vulnerability coverage. The matcher used for each finding is included in detailed output, helping you understand how the match was made.
N
NVD
National Vulnerability Database (NVD) is the U.S. government repository known software vulnerabilities. It provides comprehensive vulnerability information including CVE IDs, CVSS scores, and affected software configurations. The NVD is maintained by NIST.
Why it matters: The NVD is one of the primary vulnerability data sources used by Grype. Syft also uses the NVD’s CPE dictionary to generate CPEs for packages, enabling accurate vulnerability matching.
External resources:
Related documentation: Vulnerability Scanning
O
OCI
Open Container Initiative (OCI) is an open governance structure for creating industry standards around container formats and runtimes. The OCI Image Specification defines the standard format for container images, ensuring interoperability across different container tools and platforms.
Why it matters: Syft and Grype work with OCI-compliant images from any registry (Docker Hub, GitHub Container Registry, Amazon ECR, etc.), not just Docker images. They can read images in OCI layout format directly from disk.
External resources:
P
Package
A bundle of software that can be installed and managed by a package manager. Packages typically include the software itself, metadata (like version and dependencies), and installation instructions. Packages are the fundamental units tracked in an SBOM.
Why it matters: Every entry in a Syft-generated SBOM represents a package. Grype matches packages against vulnerability data to find security issues. Understanding what constitutes a “package” in different ecosystems helps you interpret SBOM contents.
Package manager
A tool that automates the process of installing, upgrading, configuring, and removing software packages. Examples include npm, pip, apt, yum, and Maven. Package managers maintain repositories of available packages and handle dependency resolution.
Why it matters: Syft discovers packages by reading package manager metadata files (like package.json, requirements.txt, or /var/lib/dpkg/status).
Each package manager stores information differently, which is why Syft needs ecosystem-specific catalogers.
Provenance
Information about the origin and build process of a software artifact, including who built it, when, from what source code, and using what tools. Build provenance helps verify that software was built as expected and hasn’t been tampered with.
Why it matters: SBOMs generated by Syft during builds can be combined with provenance information to create comprehensive supply chain attestations, enabling you to verify both what’s in your software and how it was built.
External resources:
PURL
Package URL (PURL) is a standardized way to identify and locate software packages across different package managers and ecosystems. PURLs provide a uniform identifier that works across different systems.
Format: pkg:type/namespace/name@version?qualifiers#subpath
Example: pkg:npm/lodash@4.17.21
Why it matters: Syft generates PURLs for all discovered packages, and Grype uses PURLs as one of the primary identifiers for vulnerability matching. PURLs provide a consistent way to refer to packages across different SBOM formats.
External resources:
Related documentation: Working with Syft JSON
R
Relationship
In Syft’s JSON output, relationships describe connections between artifacts (packages), files, and sources (what was scanned). For example, a relationship might indicate that a file is “contained-by” a package, or that one package “depends-on” another.
Why it matters: Relationships provide the graph structure of your software, showing not just what packages exist but how they’re connected. This is essential for understanding dependency chains and reachability analysis.
Related documentation: Working with Syft JSON
S
SBOM
Software Bill of Materials (SBOM) is a comprehensive inventory of all components, libraries, and modules that make up a piece of software. Like a list of ingredients on food packaging, an SBOM provides transparency into what’s included in your software, enabling security analysis, license compliance, and supply chain risk management.
Why it matters: Syft generates SBOMs that you can use with Grype for vulnerability scanning, share with customers for transparency, or use for license compliance. SBOMs are becoming required by regulations and standards like Executive Order 14028.
External resources:
Related documentation: SBOM Generation
Severity
A classification of how serious a vulnerability is, typically based on CVSS scores. Common severity levels are Critical, High, Medium, Low, and Negligible (or None).
Why it matters: Grype reports vulnerability severity to help you prioritize remediation efforts. You can filter Grype output by severity (e.g., --fail-on high to fail CI builds for high or critical vulnerabilities).
Related documentation: Vulnerability Scanning
Software supply chain
The software supply chain encompasses all the components, processes, and steps involved in creating, building, and delivering software. This includes source code, dependencies, build tools, CI/CD pipelines, and distribution mechanisms. Securing the software supply chain helps prevent attacks that target the development and delivery process.
Why it matters: Syft and Grype are key tools in supply chain security. Syft provides visibility into what’s in your software (SBOM), and Grype identifies known vulnerabilities, helping you secure each link in the chain.
Source
In Syft’s JSON output, the “source” object describes what was scanned—whether it was a container image, directory, file archive, or other input. It includes details like image name, digest, and tags.
Why it matters: The source information helps you correlate SBOMs with specific artifacts, especially important when tracking multiple image versions or builds.
Related documentation: Working with Syft JSON
SPDX
Software Package Data Exchange (SPDX) is an open standard for communicating software bill of materials information, including components, licenses, copyrights, and security references. SPDX is an ISO/IEC standard (ISO/IEC 5962:2021) and supports multiple formats including JSON, YAML, XML, and tag-value.
Why it matters: Syft can generate SBOMs in SPDX format (-o spdx-json or -o spdx-tag-value), which is widely supported by compliance tools and required by many organizations and regulations.
Grype can also scan SPDX SBOMs for vulnerabilities.
External resources:
Related documentation: SBOM Generation
Squash
The “squashed” view of a container image represents the final filesystem that would be visible if you ran the container. It’s the result of applying all image layers in sequence, where later layers can override or delete files from earlier layers.
Why it matters: Syft scans the squashed view by default (what you actually run), but you can use --scope all-layers to also see packages that existed in intermediate layers but were deleted before the final image.
Related documentation: SBOM Generation
V
VEX
Vulnerability Exploitability eXchange (VEX) is a series of formats for communicating information about the exploitability status of vulnerabilities in software products. VEX documents allow software vendors to provide context about whether identified vulnerabilities actually affect their product, helping users prioritize remediation efforts.
Why it matters: Grype can consume VEX documents to suppress false positives or provide additional context about vulnerabilities. When Grype reports a vulnerability that doesn’t actually affect your application, you can create a VEX document explaining why it’s not exploitable.
External resources:
Related documentation: Vulnerability Scanning
Vulnerability
A security weakness, flaw, or defect in software that can be exploited by an attacker to perform unauthorized actions, compromise systems, steal data, or cause harm. Vulnerabilities can arise from coding errors, design flaws, misconfigurations, or outdated dependencies with known security issues.
Not all vulnerabilities affect all users of a package. Whether a vulnerability impacts you depends on:
- The specific version you’re using
- Which features or code paths you actually invoke
- Your deployment configuration and environment
- Whether compensating security controls are in place
Why it matters: Grype identifies vulnerabilities in the packages discovered by Syft, enabling you to find and fix security issues before they can be exploited. Not all vulnerabilities are equally serious—use severity ratings (CVSS) and exploitation probability (EPSS) to prioritize fixes. Understanding the context of a vulnerability helps you assess real risk rather than just responding to every CVE.
External resources:
Related documentation: Vulnerability Scanning
Vulnerability database
A repository of known security vulnerabilities, their affected software versions, severity scores, and remediation information. Vulnerability databases aggregate data from multiple sources like NVD, security advisories, and vendor bulletins.
Why it matters: Grype downloads and maintains a local vulnerability database that’s updated daily. The database quality directly impacts scan accuracy—Grype uses curated, high-quality data from multiple providers to minimize false positives and false negatives.
Related documentation: Vulnerability Database
Vulnerability scanner
A tool that identifies known security vulnerabilities in software by comparing components against vulnerability databases. Vulnerability scanners like Grype analyze software artifacts (container images, filesystems, or SBOMs) and report potential security issues that should be addressed.
Why it matters: Grype is a vulnerability scanner that works seamlessly with Syft-generated SBOMs. You can scan images directly with Grype, or generate an SBOM with Syft first and scan it separately, enabling workflows where SBOMs are generated once and scanned multiple times as new vulnerabilities are discovered.
Related documentation: Vulnerability Scanning