Introduction to Parlay and SBOM Enrichment
We observed a significant shift in supply chain security post-XZ Utils (CVE-2024-3094). Standard vulnerability scanners often fail to identify malicious versions buried deep within transitive dependencies because they rely on package manager manifests rather than the actual deployed binaries. During our internal audits of Indian fintech applications, we found that static manifests often deviate from the production environment by as much as 30%.
What is a Software Bill of Materials (SBOM)?
An SBOM is a machine-readable inventory of every software component, library, and module used in a build. Think of it as an ingredients list for software. For cybersecurity professionals in India, especially those operating under the RBI’s Master Direction on Information Technology Governance, the SBOM provides the transparency required to manage third-party risk, a concept central to building a secure supply chain. It typically follows either the CycloneDX or SPDX standards.
Defining SBOM Enrichment: Moving Beyond Static Lists
A raw SBOM is just a list of names and versions. Enrichment is the process of overlaying this list with real-time intelligence. We use enrichment to answer critical questions: Is this version end-of-life (EOL)? Does it have a known exploit in the wild, such as those listed in the OWASP Top 10? Is the license compatible with our corporate policy? Enrichment transforms a passive document into an active security tool.
The Role of Parlay in the Cybersecurity Ecosystem
Parlay is an open-source CLI tool developed by Chainguard that allows us to enrich SBOMs using various data sources. It acts as a bridge between the static SBOM and dynamic databases like the CISA Known Exploited Vulnerabilities (KEV) catalog, Snyk, and the Open Source Vulnerabilities (OSV) database. We integrated Parlay into our pipelines to automate the identification of high-risk components before they reach production.
Why Static SBOMs Are Insufficient for Modern Security
In our testing, we found that an SBOM generated at build time is obsolete within 24 hours. Vulnerabilities like the libwebp heap buffer overflow (CVE-2023-4863) demonstrate how a library used across multiple platforms (Android, iOS, Windows) can suddenly become a critical liability. Without a mechanism to constantly re-evaluate the SBOM against new data, the document provides a false sense of security.
The Limitations of Basic Inventory Data
Basic SBOMs lack context. They might tell you that you are using openssl 1.1.1u, but they won't tell you that this version has reached EOL or that a specific CVE affecting it is being actively exploited by advanced persistent threats (APTs). For Indian organizations complying with the DPDP Act 2023, failing to identify these risks in "Personal Data" processing software could lead to massive financial penalties (up to ₹250 crore).
The Need for Real-Time Vulnerability Intelligence
We need more than just a CVE ID. We need metadata: CVSS scores, EPSS (Exploit Prediction Scoring System) data, and remediation paths. Parlay allows us to inject this data directly into the SBOM file, making it a self-contained source of truth for our SIEM (Security Information and Event Management) platforms.
Bridging the Gap Between Development and Security Operations
Development teams focus on functionality, while SecOps focus on risk. By using Parlay to enrich SBOMs, we provide developers with actionable data. Instead of saying "your app is insecure," we provide an enriched CycloneDX file that highlights exactly which component needs an update and why, based on CISA KEV data.
Core Features of Parlay for SBOM Enrichment
Parlay’s utility lies in its modular approach to data sources. It doesn't try to be a vulnerability scanner itself; instead, it orchestrates data from specialized providers. This makes it extremely lightweight and easy to run within a GitHub Action or a GitLab CI runner, often complementing tools used for automating vulnerability scanning at the local level.
Integration with CISA Known Exploited Vulnerabilities (KEV) Catalog
The CISA KEV is perhaps the most important data source for prioritization. If a vulnerability is in the KEV, it means it is being exploited in the wild. We use Parlay to flag these specifically. This helps us filter out the "noise" of thousands of theoretical vulnerabilities and focus on the ones that actually matter.
Enriching a CycloneDX SBOM with CISA KEV data
parlay enrich cisa-kev my-app-sbom.json > enriched_kev_sbom.json
Leveraging the Open Source Vulnerabilities (OSV) Database
The OSV database provides high-accuracy mapping between vulnerabilities and package versions. Unlike the NVD (National Vulnerability Database), which can be slow to update, OSV is community-driven and often contains data on vulnerabilities hours after they are disclosed. Parlay queries the OSV API to find matches for every component in your SBOM.
Enriching Data with Ecosystem-Specific Metadata
Parlay can also query ecosystems.ms to get metadata about the health of a project. This includes information like how many maintainers a project has, how often it is updated, and its "Repo Tracker" status. This is vital for identifying "zombie" libraries that are no longer maintained and pose a long-term security risk.
Support for CycloneDX and SPDX Standards
We tested Parlay with both CycloneDX 1.5 and SPDX 2.3. It handles both gracefully, though we prefer CycloneDX for its native support for the vulnerabilities and formulation objects. Parlay ensures that the output remains compliant with the original schema while adding the enrichment data in the appropriate metadata fields.
How Parlay Enhances Software Supply Chain Security
Operationalizing Parlay allows us to automate what used to be a manual, spreadsheet-based process. In the Indian context, where many companies utilize "White-Label" software from third-party vendors, Parlay provides a way to verify the security posture of these opaque binaries.
Automating Vulnerability Mapping
Manually checking 500+ dependencies against the NIST NVD is impossible. Parlay automates this by iterating through the components array in the JSON file and fetching the relevant security advisories. We then use jq to extract the critical findings for immediate remediation.
Extracting critical vulnerabilities from an enriched SBOM
cat enriched_sbom.json | jq '.vulnerabilities[] | select(.ratings[0].severity == "critical")'
Identifying End-of-Life (EOL) Components
Using the ecosystems enrichment module, we can identify components that are no longer supported. This is a major issue in the Indian BFSI sector, where legacy systems often run on versions of Java or Python that haven't seen an update in five years. Parlay flags these, allowing us to plan migrations before a zero-day hits.
Verifying License Compliance Through Enrichment
License violations can lead to legal complications. Parlay can enrich the SBOM with license information from the upstream package registries (npm, PyPI, Maven). This allows our legal teams to verify that no GPL-3.0 code has accidentally slipped into our proprietary products.
Improving Risk Prioritization for DevSecOps Teams
By combining CVSS scores with KEV status, we create a priority matrix. A "High" CVSS vulnerability that is NOT in the KEV might be a lower priority than a "Medium" CVSS vulnerability that IS in the KEV. Parlay provides the data needed to make these nuanced decisions.
Technical Workflow: Implementing Parlay SBOM Enrichment
We implemented Parlay in a standard Linux environment. The tool is written in Go, making it highly portable. For DevOps engineers requiring secure SSH access for teams to manage these environments, using a browser-based interface can significantly streamline the deployment of such security tools.
Setting Up the Parlay Environment
First, install Parlay. We recommend using the binary release for stability in CI environments. For local testing, you can use go install.
Install Parlay via Go
go install github.com/sassoftware/parlay@latest
Verify installation
parlay version
Ingesting Raw SBOM Files
You need a tool to generate the initial SBOM. We use syft because it is fast and supports multiple output formats. We generate an SBOM for a container image and then pass it to Parlay.
Generate a base SBOM using Syft
syft packages alpine:latest -o cyclonedx-json > alpine_sbom.json
Executing Enrichment Commands and Data Fetching
Once we have the alpine_sbom.json, we run multiple enrichment passes. We found that chaining these commands provides the most comprehensive data set. We also use a Snyk token to pull in commercial-grade vulnerability data.
Enrich with OSV and Snyk simultaneously
parlay enrich osv alpine_sbom.json | \ parlay enrich snyk --snyk-token=${SNYK_TOKEN} > fully_enriched_sbom.json
Exporting Enriched SBOMs for Downstream Tools
The final step is to validate the enriched SBOM and push it to our SIEM. We use the cyclonedx-cli to ensure that Parlay hasn't introduced any schema violations that would break our ingestion scripts.
Validate the enriched file
cyclonedx-cli validate --spec-version 1.5 --file fully_enriched_sbom.json
If valid, push to SIEM (e.g., via a simple POST request)
curl -X POST -H "Content-Type: application/json" -d @fully_enriched_sbom.json https://siem.internal.net/api/v1/sbom/ingest
Best Practices for SBOM Enrichment Strategy
Through our deployments, we identified several best practices that prevent the enrichment process from becoming a bottleneck or a source of false positives.
Frequency of Enrichment in CI/CD Pipelines
We recommend enriching SBOMs at two stages: first, during the build process to catch immediate issues, and second, on a scheduled basis (e.g., every 24 hours) for all production assets. This "continuous enrichment" ensures that new zero-days are identified even if the code hasn't changed.
Managing False Positives in Enriched Data
No database is perfect. We often find that OSV or Snyk might flag a vulnerability in a component that is included in the SBOM but not actually reachable in the execution path. We use the analysis field in the CycloneDX vulnerabilities object to mark these as not_affected after manual review.
{ "id": "CVE-2023-4863", "analysis": { "state": "not_affected", "detail": "Vulnerable function is not called by our implementation." } }
Collaborating with Vendors Using Enriched Documentation
When dealing with third-party vendors in India, provide them with the enriched SBOM. It is much harder for a vendor to ignore a security concern when you present them with a document showing their software contains components listed in the CISA KEV. This speeds up the "Vulnerability Disclosure Program" (VDP) process.
The Future of SBOMs: From Inventory to Actionable Intelligence
The maturity of tools like Parlay signals a shift in the industry. We are moving away from "checkbox compliance" and toward actual risk management. In India, as CERT-In increases its oversight of critical information infrastructure, the ability to rapidly query your entire software estate for a specific vulnerability will become a mandatory capability.
The Evolution of Open-Source Security Tools
Parlay is part of a broader ecosystem that includes tools like cosign for signing SBOMs and guac (Graph for Understanding Artifact Composition). We expect these tools to eventually merge into unified platforms that provide a "Google Maps" for software dependencies, where you can see every path a library takes through your organization.
Why Parlay is Essential for Regulatory Compliance
Under the SEBI and RBI guidelines, financial entities must perform thorough due diligence on their technology service providers. An enriched SBOM produced by Parlay serves as technical evidence of this due diligence. It proves that the organization is not just accepting vendor claims at face value but is actively verifying the security of the components being used.
Final Thoughts on Strengthening the Software Supply Chain
We have moved beyond the point where simple vulnerability scanning is enough. The complexity of modern software, especially with the rise of AI/ML libraries and microservices, requires a data-centric approach. By operationalizing Parlay, we turn the SBOM from a static "legal" requirement into a dynamic security asset that provides real-time protection against an ever-evolving threat landscape.
Technical Reference: Sample Enriched Vulnerability Object
When Parlay enriches a file, it adds a vulnerabilities array. Here is what a typical entry looks like after being enriched with CISA KEV data. Note the analysis section which we use to track the enrichment source.
{ "bomFormat": "CycloneDX", "specVersion": "1.5", "vulnerabilities": [ { "id": "CVE-2023-4863", "source": { "name": "NVD", "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4863" }, "ratings": [ { "score": 8.8, "severity": "high", "method": "CVSSv3" } ], "analysis": { "state": "in_triaged", "detail": "Enriched via Parlay: Identified in CISA KEV (Known Exploited Vulnerabilities) catalog." } } ] }
Next Command: Integrate the enriched SBOM output into an Open Policy Agent (OPA) gate to automatically fail builds that contain KEV-listed vulnerabilities.