Glossary reference

Use this glossary to interpret terms in Perpensa. Each entry links to the page that explains its context and controls.

Last verified on October 30, 2026.

Applications and sources

Term	Meaning
Application	A named grouping of environments and their repository sources. See Applications.
Environment	An application’s named Production or non-production context, with its own sources and declared exposure settings. See Applications.
Production	The environment kind used for Production posture and priority totals on Overview at /app/overview. See Overview.
Repository	A connected code repository; a source selects the exact branch or tag used by an application environment. See Repositories.
Source	A repository plus an explicit branch or tag, shared when multiple application environments use that same reference. See Applications.
Tracked branch or tag	The exact named reference selected for a source; both reference types use the tracked-branch allowance. See Repositories.
Public watch	A public GitHub repository tracked using a pinned branch or tag. See Your first scan.
Moved tag	A tag observed pointing to a different commit, requiring review before the new commit is accepted for scanning. See Repositories.
Scope	The application, environment, and source selection that determines which results are included. See Findings.

Findings and remediation

Term	Meaning
Finding	A recorded advisory match against a package and version in a source. See Findings.
Occurrence	A source-specific finding identified by ecosystem, package, version, target path, and advisory; the same advisory can have multiple occurrences. See Findings.
Advisory	The vulnerability record associated with a finding, including its identifier, aliases, and available severity and exploit evidence. See Findings.
Update	A proposed package version change, which can relate to multiple findings. See Update queue.
Direct or transitive dependency	Direct and Transitive describe the recorded dependency relationship, separately from reachability. See Inventory.
Accepted risk	A recorded decision for a finding occurrence in a particular environment and occurrence episode; Accept risk records acceptance and Restore reverses it, without resolving the vulnerability. See Findings.
Copy prompt	Copies remediation context to the clipboard for use in your own coding workflow. See Remediate a vulnerability and verify the fix.
SLA	The remediation deadline policy used to identify overdue findings and findings approaching their deadline. See Overview.

Severity, risk, and priority

Term	Meaning
Severity	The finding’s critical, high, medium, low, or informational classification, separate from its rank. See Findings.
CVSS	A numerical severity value displayed alongside Severity when available; priority rules validate it on a 0–10 scale. See Understand the results.
EPSS	The exploit-probability signal displayed as a percentage; unavailable values appear as Unknown in the finding’s Exploit probability signal. See Findings.
KEV	The CISA Known Exploited Vulnerabilities signal; Known exploited distinguishes Yes · CISA KEV, No, and Unknown. See Findings.
Public exploit	A recorded public-exploit flag shown separately from the KEV signal. See Findings.
Signals	The finding detail panel containing severity, exploit probability, known exploitation, public exploit, dependency relationship, and impact evidence. See Findings.
Risk score	A deterministic 0–100 score combining severity, exploitation evidence, reachability, dependency relationship, blast radius, and update lag factors. See Understand the results.
Rank	A 0–100 priority value incorporating risk and application-environment context, with an eligible refinement when available. See Update queue.
Perpensa Rank	The priority refinement included on Pro and Team; its badge requires an accepted refinement, while rules determine the category. See Overview.
Fix now, Plan, Monitor	Rule-based action categories, ordered from most to least urgent before numeric rank is considered. See Update queue.
Reachability	An explicit reachable, unreachable, or unknown signal, independent of whether the dependency is direct or transitive; the score defaults to unknown without explicit evidence. See Understand the results.

Coverage and result age

Term	Meaning
Coverage	The extent to which stored analysis can support conclusions about a source; failed, pending, unsupported, detached, or moved-tag sources can leave zero findings unverified. See Coverage.
Historical results	Retained evidence that is no longer available as current actionable results, including detached sources and moved tags. See Repositories.
Stale results	Older stored evidence whose date and source status must be checked; a refresh or failed attempt does not itself provide a new completed result. See Repositories.
Failure grace period	A three-day interval during which an eligible previous complete result can remain usable after a source failure. See Coverage.
Inventory	The detected package and version records, with available ecosystem, dependency, and source information. See Inventory.

Notifications, exports, and machine access

Term	Meaning
Digest	A stored risk summary for email or Slack, with recorded recipients or destination, items, and delivery status. See Digests.
Delivery destinations	Organization settings for outbound Slack and alert-webhook destinations, subject to the corresponding plan gates. See Settings.
Export	A generated artifact using stored results; generating it does not run a scan. See Exports.
SBOM	A dependency-inventory document containing detected components and versions, available in CycloneDX or SPDX JSON. See Exports.
CycloneDX	The SBOM format generated as CycloneDX 1.5 JSON. See Exports.
SPDX	The alternative SBOM format generated as SPDX 2.3 JSON. See Exports.
API access	Programmatic access governed by authorization scope and permissions for results, CI checks, exports, and feedback; available to eligible Pro and Team organizations. See API and CI gate.
MCP	The tool interface at /mcp for connected clients, sharing the API authorization scope, permissions, and access allowance. See MCP.
CI check	A machine-access check using a blocking severity and maximum scan age, with optional expected commit identifiers. See API and CI gate.