Run web, API, code, dependency, cloud, AI, and internal-network assessments from one queue with unified findings, evidence, remediation, and audit output.
Supply chain
SCA and SBOM
OSV, NVD, GHSA, RustSec, GoVulnDB, SPDX, CycloneDX, EPSS, KEV, and SSVC.
Findings, reports, dashboards, exports, integrations, and retests all read from the same normalized record.
Pencheff favors repeatable checks, then uses AI for triage, enrichment, orchestration, and remediation where it adds signal.
Coverage
What does SCA and SBOM test?
- OSV, NVD, GHSA, RustSec, GoVulnDB, SPDX, CycloneDX, EPSS, KEV, and SSVC.
- This page is part of Platform under Security Surfaces.
- It links back into the broader a complete adversarial security platform experience.
- OSV.dev, NVD 2.0, GitHub Advisory Database, RustSec, GoVulnDB, EPSS, CISA KEV, and SSVC enrichment.
- Manifest support for npm, PyPI, Go modules, Cargo, Ruby, Composer, Maven, OS packages, and container packages.
- SPDX 2.3 and CycloneDX 1.5 SBOM generation with optional Syft enrichment.
- Reachability annotation that separates exploited, reachable, present, and unknown risk.
- License policy checks and deterministic version-bump remediation for eligible dependencies.
Execution
How does Pencheff run this?
- Parse repository manifests, lockfiles, or container package inventories.
- Resolve packages to advisories, fixed versions, package URLs, and known exploitation signals.
- Annotate reachability from imports, call paths, runtime evidence, or scanner context.
- Generate SBOM output and link component rows back to findings.
- Prioritize remediation by exploitability, reachability, business criticality, and compliance impact.
Evidence
What evidence does this produce?
- Package name, ecosystem, installed version, fixed version, advisory id, CVSS, EPSS, KEV, and SSVC.
- SBOM component records with PURL, supplier, version, license, and dependency relationships.
- Reachability state, import evidence, or reason the vulnerable component is currently only present.
- Audit appendix output for procurement, compliance, and release records.
Controls
How is this kept safe to run?
- Dependency risk is not sorted by CVSS alone; operational signals influence priority.
- SBOM generation is repeatable and latest-generation output replaces stale records.
- License and vulnerability policy can be used as release-gate input.
- Version-bump fixes are deterministic when advisory metadata supports them.
Documentation
Read the full reference.
References
Authoritative sources
FAQ
Common questions
- What is Software Composition Analysis (SCA)?
- SCA identifies open-source dependencies in your codebase, matches them against vulnerability databases (NVD, OSV, GHSA, CISA KEV), and reports which packages have known CVEs — including transitive dependencies that your direct dependencies pull in.
- What is an SBOM and why do compliance frameworks require it?
- A Software Bill of Materials (SBOM) is a machine-readable inventory of every library, package, and component in a software artefact. NTIA, CISA, EO 14028, and PCI-DSS 4.0 require SBOMs as a baseline for supply-chain security and vulnerability management.
- Does Pencheff prioritise CVEs by exploitability?
- Yes. Pencheff enriches each CVE with EPSS (Exploit Prediction Scoring System) scores and flags entries on the CISA Known Exploited Vulnerabilities (KEV) catalogue — so you see which vulnerabilities are actively exploited in the wild, not just which ones are theoretically severe.
- What SBOM formats does Pencheff generate?
- Pencheff generates SBOMs in CycloneDX and SPDX formats, covering NPM, PyPI, Go modules, Maven, Cargo, RubyGems, and NuGet ecosystems.
Related