Feature FAQ

Pepper is a complete application-security platform: it discovers, classifies and helps you fix vulnerabilities across source code, dependencies, containers and running applications, then signs and ships the evidence into your CI/CD pipeline. This page answers the twelve most common questions about what Pepper covers and where each feature lives in the product.

At a glance

1 · CI/CD security & fail-build policies

Every project can have a build gate defining the maximum number of findings allowed at each severity, and an optional fail-on-new rule that rejects any finding not present in the previous scan. The worker evaluates the gate at the end of every scan and stamps the result on the Scan record.

• Configure: Settings → Build Gates in the UI, or PATCH /api/settings/build-gates.
• Read from CI: GET /api/scans/<id> returns gateResult: PASSED | FAILED.
• Drop-in pipelines: download templates from /api/cicd-templates/<github | gitlab | jenkins> — they enqueue a scan, poll until completion, download both SBOMs, sign them with cosign and exit non-zero when the gate fails. See CI/CD recipes.
• Webhooks: push and pull-request events from GitHub and GitLab start INCREMENTAL scans automatically.

2 · Software Composition Analysis (SCA)

Pepper parses dependency manifests from 13+ ecosystems and looks every package up against OSV for known vulnerabilities, plus a malicious-package heuristic for supply-chain attacks.

Supported ecosystems:

• JavaScript / TypeScript — package.json, package-lock.json
• Python — requirements.txt, Pipfile.lock, pyproject.toml
• Go — go.mod
• Rust — Cargo.toml
• Java / Kotlin / Scala — pom.xml, build.gradle
• Ruby — Gemfile.lock
• PHP — composer.json, composer.lock
• .NET — *.csproj, *.fsproj, packages.config
• Dart / Flutter — pubspec.yaml
• Elixir — mix.lock
• Swift — Package.resolved

OSV calls are batched and cached. In air-gapped mode set vulnDbMode = offline to skip remote lookups.

3 · SBOM (CycloneDX & SPDX)

Every scan automatically emits two software-bill-of-materials documents from the dependency graph SCA produced. They are stored as scan artifacts in MinIO and downloadable through the API or the scan-detail UI.

Each SBOM includes purl identifiers, dev vs. runtime classification, a root application component carrying scan / commit / branch metadata, and (for SPDX) DEPENDS_ON / DEV_DEPENDENCY_OF relationships.

4 · Static Application Security Testing (SAST)

Pepper runs two SAST engines side by side: a deterministic pattern engine for well-known vulnerability classes, and an LLM-based analyser that reads each file in context. Findings from both engines are deduplicated and ranked.

• Pattern engine (SAST_PATTERN) — regex rules for OWASP Top 10 + language-specific bug patterns. Languages: JavaScript / TypeScript, Python, Go, Java / Kotlin, PHP, Ruby, C#, plus generic rules (hard-coded secrets, deprecated crypto, unsafe deserialisation).
• LLM engine (SAST_LLM) — Pepper batches files through the configured LLM, asks for OWASP-style findings with severity, CWE, and a remediation hint, then filters by a confidence floor.
• Zero-day engine (ZERO_DAY) — a separate LLM pass that scores files by their likelihood of containing a novel logic flaw, then deeply analyses the top-ranked ones.

5 · Dynamic Application Security Testing (DAST)

Pepper delegates DAST to dapper, an AI-driven pentester that exercises a running application. The DAST scanner lives at src/scanners/dast/ and can talk to dapper two ways:

1. HTTP mode — recommended. Set dastEndpoint under Settings → DAST. Pepper POSTs the target URL to dapper, polls GET /scans/<id> until COMPLETED, then ingests the findings.
2. CLI fallback — when dastEndpoint is unset but the dapper binary is on the worker, Pepper invokes dapper start URL=… OUTPUT=json and parses the local JSON report.

Configuration:

• Settings → DAST — enable, set the dapper endpoint and API key.
• Per project — dastTargetUrl (set under project settings or via PATCH /api/projects/<id>).
• Scan types — DAST_ONLY runs dapper alone; FULL runs it alongside SAST/SCA/secrets when enabled.

6 · Container & artifact scanning

The CONTAINER scanner discovers image references in source — both FROM directives in Dockerfiles and image: entries in Compose files — then runs Trivy against each image when it is installed on the worker.

Findings include:

• CVE id (also stored on Finding.cveId)
• Vulnerable package + installed version + fixed version (in description)
• CWE identifier when Trivy returns one
• The originating Dockerfile / compose.yml path + line

Install Trivy in the worker image via apk add --no-cache trivy (or download the binary directly) and the next scan will pick it up automatically.

7 · Code signing

Pepper signs every SBOM it produces, so downstream consumers can prove the artifact came from your Pepper instance. Two modes are supported:

• Keyless (recommended) — uses cosign with Fulcio (short-lived certs from your OIDC identity) and Rekor (transparency log). No keys to manage. Requires cosign on the worker and COSIGN_EXPERIMENTAL=1.
• RSA fallback — paste a PEM private key into Settings → Code Signing. Pepper computes the artifact SHA-256, signs with RSA-SHA256, and stores an AES-256-GCM-encrypted copy of the key.

Signatures are uploaded as a SIGNATURE artifact (GET /api/scans/<id>/artifacts/signature) and contain the algorithm, artifact digest, signature, identity, and signing timestamp for each signed file.

8 · Pre-commit hook + secret detection

Pepper blocks commits that introduce HIGH/CRITICAL secrets or SAST issues by installing a git pre-commit hook that calls POST /api/precommit/scan with the staged file contents.

Install (one-liner)

curl -fsSL https://pepper.your-org.com/api/precommit/install.sh \
  | bash -s -- https://pepper.your-org.com ppr_xxxxxxxxxxxx

The installer:

• Drops scripts/pepper-precommit.sh into .git/hooks/pre-commit and makes it executable.
• Writes PEPPER_API_URL + PEPPER_API_KEY to a local .pepper.env.
• Adds .pepper.env to .gitignore so credentials don't leak.

What runs on each commit

The hook POSTs every staged file (under 2 MB) to /api/precommit/scan. Pepper runs the secret-pattern engine plus the SAST pattern rules in memory and returns a list of findings. The commit is blocked if any match the PEPPER_FAIL_ON set (defaults to CRITICAL,HIGH).

Bypass for emergencies: git commit --no-verify.

Pre-merge variant (webhooks)

For pre-merge enforcement, point your GitHub / GitLab repository at the respective webhook (Settings → Integrations shows the URLs). Pepper will start an INCREMENTAL scan against the PR/MR head and the build gate decides whether the merge can proceed.

9 · Integrations (Jira, Slack, SIEM, IDE)

Outbound integrations are stored encrypted in the IntegrationConfig table and dispatched at scan-completion time. All secrets are protected with AES-256-GCM at rest.

Manage all of these under Settings → Integrations → Outbound, or call POST /api/integrations directly. Test connections from the UI ("Send test message" / "Send test event") or via POST /api/integrations/test.

10 · AI features

Pepper uses LLMs in five distinct places, all configured from Settings → LLM Config:

• LLM SAST (src/scanners/sast/llm-analyzer.ts) — reads files in batched context and reports CWE-tagged findings.
• LLM secret classification (src/scanners/secrets/llm-classifier.ts) — second-pass over regex-matched secret candidates to drop placeholders / examples and reduce false positives.
• Zero-day prioritiser (src/scanners/zero-day/file-prioritizer.ts) — scores files by likelihood of harbouring novel logic flaws, then deeply analyses the top set.
• Suggested fixes (/api/scans/<id>/findings/<fid>/suggest-fix) — generates a code diff that remediates a finding.
• Open-fix PR (/api/scans/<id>/findings/<fid>/open-pr) — pushes the suggested fix to a branch on the source repo and opens a real GitHub PR.

Pepper speaks to any OpenAI-compatible API (OpenAI, Azure, OpenRouter, Anthropic via proxies) or to a local Ollama instance — set llmProvider, llmBaseUrl, llmModel in Settings → LLM Config.

11 · Compliance mapping

Findings are mapped to OWASP Top 10, NIST SP 800-53, and ISO 27001 controls. Generate a per-scan compliance report from the scan detail page or /scans/<id>/compliance.

• Framework PDFs (used as ground truth for the LLM mapper) live in compliance/.
• The mapper itself is src/lib/compliance/llm-mapper.ts — it accepts a finding and returns the control IDs that apply.
• The compliance UI shows control coverage and per-control finding counts.

12 · Audit log

Every security-relevant action is appended to the immutable AuditLog table. View it under Settings → Audit Log or GET /api/audit-log.

Tracked actions include:

• Scan queued, cancelled, paused, resumed, rescanned, stopped
• Integration created / updated / deleted / tested
• API key created / revoked
• DAST and code-signing settings updated
• Project / policy / build-gate changes
• Finding status changes

Each entry stores action, resource, resourceId, the acting userId, the originating IP, a timestamp, and a JSON details blob.

Trend analysis

The /trends page renders three historical charts powered by GET /api/dashboard/trends?days=N:

• Findings by severity — stacked area, latest scan per project per day.
• Build gate failures — daily gate-failure count vs. total scans.
• Mean time to resolve — average hours from finding creation to resolution, broken down by severity.

Get started →    CI/CD recipes →    API reference →