Pencheff
Docs ↗Sign inOpen an account

Supply chain · Capabilities

Capabilities overview

Pencheff combines deterministic scanners, AI-guided probes, curated payloads, external tools, and evidence normalization so every signal lands in one remediation workflow.

SCA and SBOM workflows connect vulnerable components, manifests, package URLs, fixed versions, reachability, EPSS, KEV, SSVC, and license evidence to the same findings and reports as application testing.

Start freeSign in
Surface routerunified
8coverage areas
5operator steps
4evidence fields
Coverage8
Execution5
Evidence4
Controls4
URLRepoAPIAICloud

One queue routes every target kind into a single normalized findings and evidence model.

ScopeEverything the engine tests
SectionCapabilities
MethodDeterministic-first
OutputUnified evidence
ProfileSupply chain
01

Coverage

What does Capabilities overview test?

  • From live exploits to source-code proof
  • Pencheff combines deterministic scanners, AI-guided probes, curated payloads, external tools, and evidence normalization so every signal lands in one remediation workflow.
  • Dropdown section: Everything the engine tests.
  • 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.
02

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.
03

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.
04

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.