Pencheff

Supply chain

CI/CD gates

Repo, dependency, IaC, container, GitHub checks, SARIF, and policy blocking.

ScopeProgram Workflows

Use the same platform for sprint gates, release assurance, audit prep, AI product validation, executive risk, and continuous attack-surface monitoring.

OutputUnified evidence

Findings, reports, dashboards, exports, integrations, and retests all read from the same normalized record.

MethodDeterministic first

Pencheff favors repeatable checks, then uses AI for triage, enrichment, orchestration, and remediation where it adds signal.

Coverage

What does CI/CD gates test?

  • Repo, dependency, IaC, container, GitHub checks, SARIF, and policy blocking.
  • This page is part of Solutions under Program Workflows.
  • It links back into the broader security programs without fragmented tooling 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 a security gate in CI/CD?
A security gate is an automated check in a CI/CD pipeline that runs security tests and blocks deployment when findings exceed a defined threshold — preventing vulnerable code from reaching staging or production environments.
How do I add a Pencheff security gate to GitHub Actions?
Add the Pencheff GitHub Action to your workflow YAML, configure your API key and target URL or repo path, and set a severity threshold. The action runs the scan and fails the workflow when critical or high-severity findings are detected.
Can Pencheff gate on both DAST and SAST findings in the same pipeline?
Yes. You can configure a single pipeline step that runs both web DAST against a staging environment and SAST/SCA against the source repository — blocking on any finding class above your threshold from either scan type.
What happens when a CI gate finds a vulnerability?
The pipeline step exits non-zero, the build fails, and Pencheff posts a summary of the blocking findings as a GitHub check run annotation on the pull request. Engineers see the finding details and remediation guidance inline without navigating to a separate dashboard.

Related

Keep exploring Solutions.