Pencheff combines deterministic scanners, AI-guided probes, curated payloads, external tools, and evidence normalization so every signal lands in one remediation workflow.
Supply chain
Reachability
Connect code and dependency issues to reachable runtime paths and attack context.
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 Reachability test?
- Connect code and dependency issues to reachable runtime paths and attack context.
- This page is part of Capabilities under Prioritization.
- It links back into the broader from live exploits to source-code proof 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.
FAQ
Common questions
- What is reachability analysis in security?
- Reachability analysis determines whether a known-vulnerable code path in a library is actually callable from your application. Most CVEs are in code paths you never invoke — reachability analysis filters these out, leaving only the vulnerabilities that represent real risk to your specific application.
- How does reachability reduce alert fatigue?
- A typical Node.js application has hundreds of transitive dependencies, many with CVEs. Without reachability, every CVE demands attention. With reachability, only the fraction of CVEs reachable from your application's call graph surface — often under 10% — require remediation effort.
- Does Pencheff perform reachability analysis for all languages?
- Pencheff currently supports reachability for JavaScript/TypeScript (via call graph analysis), Python, Go, and Java. Reachability data is displayed alongside EPSS and KEV enrichment in the findings stream.
Related