> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/application-security/code-security/code-security-scanners/software-composition-analysis-sca-scanners/package-operational-risk-scanner/investigate-and-remediate-package-operational-risk-issues.md). # Investigate, prioritize and remediate package operational risk issues To effectively manage package operational risks, follow this lifecycle, moving from an open backlog to a resolved and prevented issue. **Important.** Package operational risk issues do not receive their own Urgency classification. Package Operational Risk acts as a secondary, informational signal within the Urgency calculation for CVE vulnerability issues. This guide therefore replaces the Urgency-driven prioritization and reachability model with a maintenance-posture model, and treats coupling to open vulnerability issues as the primary ordering signal. ```mermaid flowchart LR A[Assess: read the maintenance posture of the estate] --> B[Prioritize: order by risk level and CVE coupling] B --> C[Investigate: establish whether future fixes will arrive] C --> D[Remediate: replace, fork, or accept the dependency] D --> E[Prevent: block unmaintained packages at intake] ``` | Stage | Decision | Primary surface | Guide that owns the detail | | --------------- | ------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------- | | **Assess** | How much capacity to commit to dependency modernization | Software packages inventory `unverified — confirm the surface that aggregates operational risk` | This guide | | **Prioritize** | Which unmaintained package to address next | Risk level, filtered against open vulnerability issues | This guide | | **Investigate** | Whether the package will receive future fixes, and what replacement costs | Package Explorer | Package Explorer | | **Remediate** | Whether to replace, fork, or accept the dependency | Software packages inventory | Software packages as an asset | | **Prevent** | Which enforcement point blocks unmaintained packages | Unified Application Security Policies | Unified Application Security Policies | > **Important:** Package operational risk differs from every other issue type in what it measures. Other issue types report a present defect. Operational risk reports the absence of a future fix — an unmaintained package is not vulnerable today because it is unmaintained, but it will not be patched when it becomes vulnerable tomorrow. Read this lifecycle as capacity planning rather than as incident response. *** ### Assess Before selecting a package, read the maintenance posture of the dependency estate. Operational risk is a leading indicator: the population of unmaintained packages predicts how much of your future vulnerability backlog will have no available fix version. **The risk level distribution — how maintenance posture is spread.** Package operational risk is reported at three levels. Read the proportions rather than the absolute counts. | Shape | What the shape means | What to do | | ----------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | A visible High population | Packages that are deprecated or abandoned by their maintainers | Commit modernization capacity here. Every future CVE in these packages will have no upstream fix | | A High population that overlaps open CVE issues | Vulnerable packages that are also unmaintained | Address first. These are the vulnerabilities that will not be resolvable by an upgrade | | A large Medium population | Packages with slowing release cadence but not formally deprecated | Monitor for escalation, and avoid adding new dependencies on these packages | **Read operational risk against the vulnerability backlog, not on its own.** An unmaintained package with no known vulnerability is a scheduling item. An unmaintained package that already carries an open CVE issue is a remediation dead end — the fix version that would resolve the CVE will never be published. > **Note:** Package Operational Risk contributes as a secondary signal to the Urgency calculation for CVE vulnerability issues. A CVE in an unmaintained package therefore already reflects the operational risk in its Urgency level, which is a second reason to triage the two backlogs together. *** ### Prioritize **Prioritize by risk level, then by coupling to open vulnerability issues.** This replaces the Urgency-first rule that governs security issue types, because operational risk carries no Urgency classification of its own. | Order | Population | Why the population ranks here | | ----- | ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | High risk level, with an open CVE issue on the same package | A vulnerability with no upstream fix path. Replacement is the only remediation, so start the replacement now rather than when the CVE escalates | | 2 | High risk level, deployed and business-critical | Abandoned code running in production. The next disclosure has no fix, and the replacement will be urgent when it arrives | | 3 | High risk level, not deployed | Abandoned code in the codebase. Replace opportunistically, before the package reaches production | | 4 | Medium risk level | Slowing maintenance. Monitor, and prevent new dependencies rather than replacing existing ones | **Sort by the number of consuming applications.** One unmaintained package consumed across many applications concentrates future risk into a single replacement. Addressing that package removes the dead end from every consumer at once. > **Note:** For the package inventory and the applications that consume each dependency, see Package Explorer. *** ### Investigate A risk level tells you a package is unmaintained. It does not tell you whether the project is genuinely abandoned or merely stable, or what replacing the package would cost. Investigation answers three questions, and each answer changes the action you take. #### Will this package receive a fix if a risk is disclosed? This question replaces the reachability question that governs a security issue investigation. There is no present attack path to establish — the question is whether a future remediation path exists. Evidence comes from the package registry metadata and the maintenance signals the scanner collects: whether the maintainer has formally deprecated the package, the interval since the last release, and whether a successor package is recommended. | Evidence | Consequence | | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Formally deprecated by the maintainer, successor named | The maintainer has stated the package is finished and named the replacement. Migrate to the successor | | Formally deprecated, no successor | No fix will arrive and no migration path is offered. Plan a replacement or prepare to fork | | No release in a long interval, not formally deprecated | Ambiguous. A small, complete library may be stable rather than abandoned. Check whether the repository is archived and whether issues receive maintainer responses | | Slowing cadence, maintainer still active | Not yet a dead end. Monitor, and avoid deepening the dependency | > **Caution:** Do not read release inactivity alone as abandonment. A narrowly scoped library that solves a fixed problem may be complete. Confirm with a second signal — an archived repository, an explicit deprecation notice, or unanswered security reports — before committing replacement capacity. #### What is exposed if the package is never fixed? Blast radius for operational risk is the future remediation cost, not present exposure. Establish how many applications consume the package, whether those applications are deployed and business-critical, and whether the package already carries open vulnerability issues. A widely consumed unmaintained package concentrates future risk: a single disclosure against it produces a vulnerability in every consumer at once, with no fix version available for any of them. The **Code-to-Cloud graph** shows the same exposure as a path — the repository, the pipeline that builds it, and every asset the pipeline deploys to. #### What does replacement cost? The **code evidence** names the repository, the branch, the manifest file, and the commit that introduced the dependency. **Dependency Type** determines who can act. A direct dependency is your team's decision to replace, and the cost is the API surface you consume. A transitive dependency is not yours to replace — you must upgrade or override the root package, and the root package maintainer may still depend on the unmaintained package. The consumed API surface determines the engineering cost. Replacing a package used for one utility function is a small change; replacing a package whose types propagate throughout the codebase is a project. Establish both during the investigation, because operational risk work is planned rather than reactive, and an accurate cost estimate is what allows the work to be scheduled at all. *** ### Remediate | Path | Use when | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Migrate to the named successor** | The maintainer formally deprecated the package and named a replacement. The lowest-cost path, because the successor is usually API-compatible or offers a migration guide | | **Replace with a maintained equivalent** | The package is abandoned with no successor, and a maintained alternative covers the consumed API surface. The standard path | | **Fork and maintain internally** | No maintained equivalent exists and the package is essential. Transfers maintenance cost to your organization, including the obligation to patch future vulnerabilities yourself | | **Accept and monitor** | The package is stable, narrowly scoped, and carries no open vulnerability. Record the acceptance, and re-evaluate when a vulnerability is disclosed against the package | Sequence by coupling to open vulnerability issues. Among equally risky packages, replacing one that already carries an open CVE resolves a present vulnerability and removes a future dead end in the same change. Escalate to a Case when the replacement affects multiple applications and requires coordinated migration. > **Important:** Accepting an unmaintained package is a valid outcome, unlike accepting an exposed credential or a malicious package. Record the acceptance and the reasoning, and set the condition that would reverse it — normally the disclosure of a vulnerability against the package. > **Note:** For inspecting the package and the applications that consume it, see Software packages as an asset and Package Explorer. *** ### Prevent Prevention for operational risk operates at dependency intake rather than at vulnerability detection. The cheapest moment to avoid an unmaintained dependency is before the dependency is adopted, when no consuming code exists yet. Close the loop with a Unified Application Security Policy applied to the Operational Risk finding type. Select the trigger in shift-left order: a **PR Scan** trigger flags the unmaintained package in the pull request that introduces it, which is the point at which the developer can still choose a maintained alternative at no cost. **Prefer warning over blocking for this finding type.** Unlike a malicious package, an unmaintained package is not hostile, and a hard block at intake generates friction against a risk that is future rather than present. A warning that surfaces the maintenance posture at selection time changes the decision without stopping delivery. **Encode the acceptance decisions.** Where the organization has accepted specific unmaintained packages, reflect those acceptances in the policy conditions so that the same packages do not re-enter the backlog on every scan. > **Note:** For policy triggers, actions, conditions, and grace period configuration, see Unified Application Security Policies. *** ### When the backlog itself is unreliable **Registry metadata is the source of truth, and the metadata is incomplete.** Maintenance signals derive from the package registry. Not every ecosystem exposes a formal deprecation flag, and a maintainer who abandons a package without announcing the abandonment produces no signal at all. A package absent from the operational risk backlog is not confirmed to be maintained. **Operational risk is not evaluated in isolation from the SCA scan.** Operational risk is detected during SCA scanning. A repository outside SCA coverage contributes no operational risk findings, and its unmaintained dependencies are unmeasured rather than absent. Treat the operational risk backlog as a floor on the unmaintained population rather than as a complete inventory. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/application-security/code-security/code-security-scanners/software-composition-analysis-sca-scanners/package-operational-risk-scanner/investigate-and-remediate-package-operational-risk-issues.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.