Dependency vulnerability triage
classify reachability, route to a named owner, and verify the closure on one record
A new SCA scan can ship 40 critical CVEs in a single dependency tree. Most of them are not reachable from the application, several are already patched in a transitive update, a few are exploitable in the deployed environment, and one is the actual fire. Programmes that treat every dependency CVE as critical burn the engineering team and ignore the real risk. Run dependency vulnerability triage as a governed workflow on the engagement record so each finding is classified by reachability and exposure, the routing decision lands on a named owner, the closure is verified by a re-scan, and the audit trail proves which CVEs were prioritised, why, and how the closure happened.
No credit card required. Free plan available forever.
Run dependency vulnerability triage as a governed workflow on the engagement record
A new SCA scan against a typical service tree can ship 40 critical CVEs in a single afternoon. Most of them are not reachable from the application code. Several are already patched in a transitive update available on the next dependency bump. A few are exploitable in the deployed runtime, and one is the actual fire. Programmes that treat every dependency CVE as critical burn the engineering team and ignore the real risk. Programmes that ignore SCA findings entirely because the noise is too high miss the reachable KEV entry that appears two weeks later. The cost of triage shortcuts is not a process gap; it is the reachable CVE that ships unaddressed because the queue was sorted by upstream CVSS rather than by exploitable risk in the running system.
This is the dependency-vulnerability triage workflow. For the upstream code-review work that decides which dependencies enter the tree in the first place, read the code review workflow. For the integration of SCA into the development pipeline that produces the scanner output, read the DevSecOps scanning workflow. For the upstream validation step that decides whether a finding is real before it enters the queue, read the scanner result triage workflow. For the cross-stage routing layer that moves findings between SDLC gates, read the SDLC vulnerability handoff workflow. For the per-finding lifecycle from open to verified closed, read the remediation tracking workflow. The vulnerability reference for the underlying class is the vulnerable dependencies explainer.
Six lifecycle stages and how the triage plays out at each one
Every dependency-vulnerability triage has a healthy posture and a default failure mode. The six stages below are the ones where most programmes accumulate the gap between intended process and operational reality. Each one starts as a routing convenience and ends as an audit-reconciliation problem.
| Lifecycle stage | Healthy posture | Default failure |
|---|---|---|
| Detection | A code scan against the connected repository surfaces the dependency CVE with the affected package, the version range, the fixed version, the dependency path (direct or transitive), and the CVSS score on the engagement record. The detection event is the start of a triage clock that does not stop until the finding is classified, routed, remediated, and verified. The activity log captures the moment the CVE entered the repository so the audit lookback can answer how long the vulnerable dependency was live. | The CVE is detected by an SCA scanner whose output lands in a dashboard nobody opens daily. The triage clock starts when somebody happens to glance at the scanner UI rather than at detection time. The audit lookback cannot answer how long the vulnerable dependency was live because the detection event was never recorded against a tracked finding. |
| Reachability classification | Each detection is classified by reachability: whether the vulnerable function is called from the application code, whether the dependency is loaded only in a test or build profile, whether the deployed runtime exposes the affected surface, and whether the asset is internet-facing. The classification lands on the finding with the named triager, the rationale, and the timestamp so the next match against the same dependency inherits the prior decision rather than re-litigating it. | Every dependency CVE is treated as critical because the upstream advisory says so. The team ships emergency upgrades for vulnerabilities that are not reachable from the application, burns engineering capacity on test-only dependencies, and ignores the actually exploitable CVE that is buried under a wave of false-priority work. Within a quarter, engineering disengages from SCA findings entirely and the next reachable CVE ships unaddressed. |
| Prioritisation | The queue is ordered by CVSS for impact severity, EPSS for exploitation probability, the CISA KEV catalog for known exploited vulnerabilities, and the asset criticality on the engagement for blast radius. The combined priority lands on the finding so the queue reads as a defensible ordering rather than as a CVSS-only list. KEV entries jump to the front; high-EPSS, high-asset-criticality CVEs follow; the long tail of low-reachability mediums sits in a triaged backlog with a documented review cadence. | The queue is ordered by CVSS alone. Every critical CVE blocks every other change. The team ships a patch for a CVSS 9.8 in an unreachable test dependency and misses the CVSS 6.5 KEV entry in a production-facing library. The prioritisation looks defensible against CVSS and is indefensible against the actual exploit landscape. |
| Routing | Each finding routes to a named owner on a named team. Direct dependencies route to the application owner. Transitive dependencies route to the owner of the closest direct ancestor. Shared platform dependencies route to the platform team. The asset-to-owner mapping on the engagement resolves most cases as a query, the inheritance rationale lands on the finding, and the SLA crosses the seam from AppSec triage into engineering on a deliberate routing event rather than as a hallway conversation. | Findings land in a shared queue with no owner. Engineers debate whose dependency tree the CVE actually lives in. Triage owns the conversation but cannot ship the fix; the dependency owner does not see the finding until the next status meeting. The CVE ages across three sprints because the routing decision never lands on the record. |
| Remediation | Three closure paths converge on the same record. An upgrade to the fixed version is the default path; the named owner ships the bump and the activity log captures the commit reference. A workaround (configuration mitigation, runtime control, dependency replacement) is recorded with the rationale and the residual risk. A documented exception lands in the exception register with an expiry, a review trigger, and the named approver. Each path produces evidence the audit can read. | The upgrade ships to the application module that imports the dependency directly, but the transitive pin in another module still pulls the vulnerable version. The closure note says upgraded; the lockfile says still vulnerable. The next scheduled scan re-detects the same CVE because the upgrade was partial and the verification step was skipped. |
| Closure verification | A follow-up code scan against the upgraded branch confirms the dependency CVE no longer reports. The verification scan attaches to the same finding as a state event and the closure moves to verified closed. Closures that did not survive the re-scan stay open with the reopen reason captured so the next remediation cycle starts from the same record. The audit committee can reconstruct the closure history from one record. | The finding is moved to closed because the developer reported they bumped the version. No follow-up scan ran. The next scheduled scan (days or weeks later) re-detects the same CVE because the bump landed on a feature branch that never merged, the lockfile was not regenerated, or a transitive constraint pinned the dependency back to the vulnerable version. The reopen rate climbs and the closure-on-evidence discipline never takes hold. |
Six failure modes that quietly break dependency CVE triage
Dependency-vulnerability triage failures rarely look like failures at the moment they happen. They look like convenience: a CVSS-only sort that produces a clean queue, a quick Slack confirmation that a CVE is not reachable, a closure note that mentions the upgrade. The cost arrives at the next compromise investigation, the next audit lookback, or the next scheduled scan that resurfaces a CVE the previous cycle thought it had closed.
Every CVE is treated as critical
The team treats the upstream CVSS as the priority. CVSS 9.8 in a test-only dependency outranks CVSS 6.5 in a production-facing KEV entry. Engineering burns weeks on unreachable upgrades. Within a quarter, engineering disengages from SCA findings and the next reachable CVE ships unaddressed.
Reachability is asserted instead of recorded
The reachability call lives in a Slack thread, not on the finding. Six months later, the auditor asks why a dependency CVE is open with the closure plan unreachable. The answer is somewhere in chat history. Reachability decisions that are not recorded on the finding are decisions that did not happen.
Transitive dependencies have no owner
A vulnerable dependency two layers deep in the tree has no clear owner. AppSec routes it to one team, engineering rejects ownership, the finding ages across sprints. The asset-to-owner mapping that resolves direct dependencies has nothing to say about transitive paths, so transitive CVEs become permanent backlog.
Closure on plan rather than on a re-scan
The finding is moved to closed because a pull request title mentions the upgrade. The PR may have merged, may have landed on the wrong branch, may have been reverted, or may not have regenerated the lockfile. Without a verification scan against the post-upgrade branch, the closure is a claim, not a fact.
Exceptions accumulate without expiry
A dependency CVE is documented as an exception (unreachable, no fix available, blocked by a downstream API change) and the exception never gets reviewed. Two years later, the dependency is still in the tree, the application has changed enough that the original reachability claim no longer holds, and the exception register has accumulated dozens of stale entries.
Lockfiles are not the source of truth
The triage decision is made against the manifest (package.json, pom.xml, requirements.txt) rather than the lockfile (package-lock.json, pom.xml resolved versions, pip freeze). The manifest declares the intended version; the lockfile records the resolved version. CVEs live in the resolved version; closures land in the resolved version. Triage that ignores the lockfile is triage on the wrong artefact.
Six fields every dependency CVE triage policy has to record
A defensible triage policy is six concrete fields on the engagement record, not an abstract paragraph in a security handbook. Anything missing from the list below is a known gap in the triage discipline rather than a detail that surfaces later.
Detection-to-triage SLA
The maximum time between an SCA finding landing on the engagement record and a named triager classifying it for reachability and routing. Without an SLA, dependency CVEs accumulate in a shared backlog the on-call rotation never owns. The SLA lives on the engagement so the next finding inherits it rather than waiting for an operator to set the deadline per match.
Reachability classification rule
How each finding is classified into reachable from production code, reachable only from test or build code, dependency loaded but vulnerable function never called, or not loaded in the deployed artefact. The rule names the inputs (the dependency path, the import graph, the runtime profile, the deployment posture) so the triage decision is reproducible across triagers and across cycles.
Prioritisation formula
The combination of CVSS, EPSS, KEV membership, asset criticality, and reachability that produces the queue order. The formula lives on the engagement so the priority of every new finding is computed from the same inputs rather than negotiated per match. Without the formula, prioritisation becomes a recurring debate and the dangerous CVEs sit in queue position dictated by whoever spoke last.
Routing rule for direct and transitive dependencies
The asset-to-owner mapping that resolves which engineering team owns the dependency. Direct dependencies route to the application owner; transitive dependencies route to the owner of the closest direct ancestor; shared platform dependencies route to the platform team. The rule lives on the engagement so routing is a query rather than a negotiation.
Exception register integration
The contract that says any closure path other than upgrade or workaround lands in the exception register with an expiry date, a review trigger, and the named approver. Exceptions without expiry accumulate into permanent backlog. Exceptions on the engagement record with explicit review cadence stay defensible against the next audit lookback.
Verification scan as the closure event
A follow-up code scan against the upgraded branch confirms the SCA finding no longer reports. The scan result attaches to the same finding as a state event and the closure moves to verified closed. Closure on plan does not satisfy the rule; only closure on a verification scan that ran after the upgrade commit landed on the target branch.
Dependency vulnerability triage checklist
For every confirmed dependency CVE, the AppSec lead and the engineering owner walk through a short checklist. Each item takes minutes; missing any one of them is the source of the failure modes above and the audit gaps that follow.
- Every code scan against the connected repository runs SCA against the lockfile and lands findings on the engagement record with package, version range, fixed version, dependency path, and CVSS.
- Each detection is classified by reachability with the named triager, the rationale, and the timestamp on the finding.
- The queue is ordered by a documented formula combining CVSS, EPSS, KEV membership, asset criticality, and reachability rather than by CVSS alone.
- KEV entries jump to the front of the queue regardless of their CVSS score because known exploited vulnerabilities are operational risk, not theoretical risk.
- EPSS scores feed the prioritisation so a high-EPSS medium outranks a low-EPSS high in the operating queue.
- Findings route to a named owner using the asset-to-owner mapping; direct dependencies route to the application owner, transitive dependencies route to the closest direct ancestor, shared platform dependencies route to the platform team.
- Closure paths are explicit: upgrade to the fixed version, workaround with documented residual risk, or exception with expiry and review trigger.
- Triage decisions are made against the lockfile (the resolved versions) rather than the manifest (the declared versions) so the triage operates on the artefact the CVE actually lives in.
- Exceptions land in the exception register with an expiry date, a review trigger, and the named approver so unreachable findings do not accumulate into permanent backlog.
- Closure is paired with a follow-up code scan against the upgraded branch; closure on plan does not satisfy the rule.
- Reopen events surface the gap (revert, wrong branch, lockfile not regenerated, transitive pin) on the same record so the next remediation cycle starts from the same finding.
- AI-generated reports derive the dependency-CVE narrative from the engagement record so leadership reads the verified closure status rather than a hand-built status update.
How dependency vulnerability triage looks in SecPortal
Dependency-vulnerability triage runs on the same feature surfaces the rest of the product security programme already uses: the engagement record, the findings record, the activity log, code scanning, and AI reporting. The discipline is keeping the security record canonical across detection, classification, prioritisation, routing, remediation, and verification rather than letting each step create its own parallel record.
SCA in code scanning
Code scanning connects to GitHub, GitLab, and Bitbucket via OAuth and runs SCA against the lockfile on every code scan. Findings land on the engagement record with the affected package, version range, fixed version, dependency path, and CVSS score. The repository is cloned into an isolated container with no persistent storage and destroyed after the scan.
Repository connections
Repository connections handle the OAuth lifecycle for GitHub, GitLab, and Bitbucket so the SCA scan can run against the lockfile on the connected branch without storing long-lived access tokens. The connection records on the workspace pair against the engagement so the scan inherits both the scope and the access scope from the same record.
One canonical finding across stages
Findings management holds severity, evidence, owner, and closure on the security record. Detection, classification, prioritisation, routing, remediation, and verification all attach to the same record. The journey from detection to closure is one record with a state history rather than six parallel records.
Reachability decision on the finding
Every detection is classified for reachability with the named triager, the rationale, and the timestamp on the finding. The decision is reproducible across triagers and inherited by the next match against the same dependency, so the next quarter does not re-litigate the same call from scratch.
Prioritisation derived from the engagement
The combined priority (CVSS plus EPSS plus KEV plus asset criticality) lands on the finding so the queue order is computed from the same inputs across every match rather than negotiated per CVE. The asset criticality input comes from the asset criticality scoring workflow on the same engagement record.
Verification scan as the closure event
A follow-up code scan against the upgraded branch confirms the SCA scan no longer reports the CVE. The result attaches to the finding as a state event and the closure moves to verified closed. Closure on plan does not satisfy the rule; only closure on a verification scan that ran after the upgrade landed on the target branch.
Lockfile-anchored detections
SCA findings are produced against the lockfile (the resolved versions) rather than the manifest (the declared versions). Triage operates on the artefact the CVE actually lives in, and closures land in the same artefact. Programmes that triage against the manifest close findings the lockfile still pulls in vulnerable versions for.
Audit trail in the activity log
Every detection, classification, prioritisation, routing, remediation, and verification event lands on the activity log with timestamp and user attribution. The CSV export is the evidence trail SSDF, ISO 27001, SOC 2, PCI DSS, and OWASP ASVS assessors expect to see when they ask for the response history behind a third-party component vulnerability.
AI reports from the engagement record
AI reports derive the dependency-CVE narrative from the engagement record so the dependency backlog summary, the leadership update, and the audit narrative all reconcile to the same underlying findings rather than a parallel hand-built status update.
Five views the dependency CVE triage cycle actually drives
The reports that drive dependency-vulnerability triage are not the static summary that lands at the end of a quarter. They are the live views AppSec leads, security engineering owners, and engineering managers use between scans. The five below are the ones every meaningful product security programme settles on, and they all derive from the live engagement record rather than a parallel scanner-tool extract.
Reachable open backlog
Open dependency CVEs filtered by reachable classification and ordered by the combined priority. The view that shows the engineering team what to ship this sprint instead of the wall of upstream advisories sorted by CVSS.
Time from detection to closure
For each closed finding, the time between the first detection event and the verified closure event recorded on the finding. The view that shows whether the response window is shrinking and which dependency owners ship faster than others.
Verification scan coverage
Closures paired with a verification scan against the upgraded branch and closures that are not. The view that distinguishes durable closure from administrative closure and surfaces silent reopens before the next scheduled scan does it for you.
Reopen rate by dependency
Findings that closed and reopened within a defined lookback window, broken out by dependency. The view that surfaces the dependency trees where the upgrade keeps partially landing because of transitive pins, lockfile regeneration gaps, or downstream consumers blocking the bump.
Exception register expiry
Active exceptions ordered by expiry date with the named approver and the review trigger. The view that prevents exceptions from accumulating into permanent backlog and surfaces the next review date so the unreachable claim is re-validated against the current codebase rather than against the codebase at the time of first triage.
What auditors expect from dependency vulnerability triage
Dependency-vulnerability evidence shows up in audit reads whenever an external assessor reviews the product security programme or investigates a third-party component incident. The frameworks below all expect the programme to show that components are inventoried, that vulnerabilities are detected, that triage decisions are recorded, and that closure is verified. A documented policy without enforcement evidence reads as a process gap.
| Framework | What the audit expects |
|---|---|
| NIST SP 800-218 SSDF | PW.4 (Reuse Existing, Well-Secured Software When Feasible), PW.5 (Create Source Code by Adhering to Secure Coding Practices), and RV.1 (Identify and Confirm Vulnerabilities on an Ongoing Basis) all expect documented evidence that third-party components are inventoried, that vulnerabilities in components are identified, and that remediation is verified. A canonical record covering detect, classify, prioritise, route, remediate, and verify satisfies the SSDF evidence ask without a parallel attestation per CVE. |
| ISO 27001:2022 | Annex A 8.8 (management of technical vulnerabilities) expects the organisation to obtain timely information about technical vulnerabilities, evaluate the exposure, and take appropriate measures. Annex A 8.28 (secure coding) expects secure coding principles to be applied including dependency hygiene. Annex A 8.29 (security testing in development and acceptance) expects evidence that the testing actually finds the vulnerabilities and that closure is verified. |
| SOC 2 | Common Criteria CC7.1 expects the entity to use detection and monitoring procedures to identify changes to configurations that result in new vulnerabilities. CC7.2 expects monitoring of system components and the response to identified vulnerabilities. A canonical engagement record covering detection, reachability classification, prioritisation, routing, remediation, and verification produces the audit trail SOC 2 reviewers expect when they ask for the response history behind a third-party component vulnerability. |
| PCI DSS 4.0 | Requirement 6.3.1 requires identification and ranking of vulnerabilities by risk. Requirement 6.3.3 requires the application of patches and updates within defined timeframes. Requirement 11.3 requires authenticated internal vulnerability scans on a defined cadence. The activity log of detect, classify, prioritise, route, remediate, and verify is the evidence trail an assessor expects when reviewing dependency CVE handling. |
| OWASP ASVS | V14 Configuration requirements expect dependencies to be inventoried, monitored for vulnerabilities, and updated under defined conditions. V1 Architecture requirements expect documented decisions about which third-party components are in the deployed artefact and which are excluded. The verification expectation is that SCA controls run regularly and that vulnerabilities are remediated with evidence rather than with a checkbox. |
Where dependency vulnerability triage sits in the wider security programme
Dependency-vulnerability triage composes with the rest of the security programme on the same engagement record so the SCA workflow stays connected to the SDLC, the code-review process, and the broader vulnerability management cycle that owns reachable CVEs across every asset class.
Upstream and adjacent
Dependency triage depends on DevSecOps scanning integrating SCA into the pipeline, code review deciding which dependencies enter the tree, scanner result triage promoting validated findings before they become engineering work, asset criticality scoring feeding the prioritisation formula, and the SDLC vulnerability handoff workflow when the dependency CVE crosses stage gates.
Downstream and reporting
Dependency-CVE evidence rolls into remediation tracking for the per-finding lifecycle from open to verified closed, vulnerability prioritisation for queueing dependency CVEs against the rest of the backlog, vulnerability acceptance and exception management for the exception register the unreachable findings land in, and security leadership reporting for the leadership cadence that reads time-to-closure as a leading indicator of programme health.
Pair the workflow with the long-form guides and the framework references
Dependency-vulnerability triage is operational; the surrounding guides explain the prioritisation models and the secure-SDLC practice expectations the workflow has to satisfy. Pair this workflow with the SBOM guide for the inventory layer that anchors dependency triage, the VEX explainer for the machine-readable exploitability statements that travel with components, the reachability analysis explainer for the prioritisation discipline this workflow operationalises, the EPSS explainer for the exploitation-probability input into the priority formula, the CISA KEV catalog guide for the known-exploited list that jumps to the front of the queue, and the SAST vs SCA explainer for where dependency detection sits in the code-scanning toolchain. The vulnerability reference for the underlying class is the vulnerable dependencies explainer. The framework references that mandate component-vulnerability handling and verified remediation evidence include OWASP ASVS for the V1 and V14 verification requirements, ISO 27001 for Annex A 8.8, 8.28, and 8.29, PCI DSS for requirements 6.3.1, 6.3.3, and 11.3, and SOC 2 for CC7.1 and CC7.2.
Buyer and operator pairing
Dependency-vulnerability triage is the workflow AppSec teams run as the front line for SCA findings, product security teams run as the owner of the third-party component control, DevSecOps teams run when SCA output flows into the pipeline at the build gate, security engineering teams run as the platform-side owners who coordinate transitive upgrades across services, vulnerability management teams run alongside the broader vulnerability management programme, and internal security teams run as the cross-functional owner across products. CISOs read time-to-closure on KEV-flagged dependencies, verification-scan coverage, and reopen rate by dependency tree as leading indicators of whether the third-party component programme is reducing reachable CVEs in production.
What good dependency vulnerability triage feels like
One canonical record across the lifecycle
Detection, classification, prioritisation, routing, remediation, and verification all live on the same security record. Each step adds state events; nothing dissolves at the seams. Audit lookback queries hit one record rather than reconstructing the journey from chat logs and pull request titles.
Reachable risk reaches the front of the queue
The combined priority (CVSS plus EPSS plus KEV plus asset criticality plus reachability) puts the actually exploitable CVEs at the top of the queue. KEV entries jump to the front. Unreachable criticals sit in a triaged backlog. The team ships the fixes that change risk in the running system rather than chasing the upstream advisory wall.
Closure is verified, not asserted
A finding moves to closed only when a follow-up scan against the upgraded branch confirms the SCA scan no longer reports the CVE. Closure on plan accumulates into reopen rate; closure on evidence produces durable closures that survive the next scheduled scan.
Evidence is derivative of the work
Detection events, classification decisions, prioritisation rationale, routing history, remediation outcomes, and verification-scan results all derive from the live engagement record. The activity log export is the trail, and the AI report is the narrative. Nobody assembles the dependency-CVE evidence the week before the audit.
Dependency vulnerability triage is the workflow that turns the SCA detection wall into a defensible queue of reachable risk. Run it on the engagement record so the security finding stays canonical across detect, classify, prioritise, route, remediate, and verify, the receiving owner records each step as a deliberate event, the closure is paired with a follow-up scan, and the audit lookback resolves from one record rather than from a multi-system reconciliation sprint.
Frequently asked questions about dependency vulnerability triage
What is a dependency vulnerability triage workflow?
A dependency vulnerability triage workflow is the operating discipline that turns an SCA detection into a routed, prioritised, and verified closure. It covers the detection event from a code scan against the lockfile, the reachability classification (whether the vulnerable function is called from production code), the prioritisation against CVSS plus EPSS plus KEV plus asset criticality, the routing to the named dependency owner, the closure path (upgrade, workaround, or documented exception), and the verification scan that confirms the CVE no longer reports against the upgraded branch. SecPortal runs the workflow on the engagement record so each dependency CVE is one record with a state history rather than a chain of chat messages and pull request titles.
How does SecPortal detect dependency vulnerabilities?
SecPortal connects to GitHub, GitLab, or Bitbucket through OAuth and runs SCA against the connected repository on every code scan. The scan reads the lockfile and manifest, identifies the resolved versions of every dependency, and lands findings on the engagement record with the affected package, the version range that introduces the CVE, the fixed version, the dependency path (direct or transitive), the CVE identifier, and the CVSS score from the upstream advisory. The repository is cloned into an isolated container with no persistent storage, the scan runs, and the container is destroyed after the scan completes.
Why is reachability classification more important than CVSS for dependency CVEs?
CVSS captures the severity of a vulnerability in the abstract; reachability captures whether the vulnerability is exploitable in the deployed application. A CVSS 9.8 in a function the application never calls is not a 9.8 risk in the running system. A CVSS 6.5 in a function called on every request is a higher operational risk than the unreachable critical. Programmes that prioritise by CVSS alone burn engineering capacity on unreachable critical findings and leave reachable mediums in queue position dictated by their CVSS score. Reachability classification produces a queue ordered by what the application actually exposes, not by what the upstream advisory says.
How do EPSS and KEV change the prioritisation?
EPSS (Exploit Prediction Scoring System) estimates the probability that a CVE will be exploited in the wild within the next 30 days; the score is a useful signal that an upstream CVE has active exploit interest beyond the theoretical severity. KEV (the CISA Known Exploited Vulnerabilities catalog) lists CVEs that are known to have been exploited, which means the question of whether the CVE is being exploited is already answered. KEV entries jump to the front of the queue regardless of their CVSS score because known exploited vulnerabilities are operational risk rather than theoretical risk. EPSS feeds into the queue ordering so a high-EPSS medium outranks a low-EPSS high in the operating priority. CVSS sets the upper bound on impact; EPSS and KEV adjust the urgency.
How is the closure verified?
A follow-up code scan against the upgraded branch is the closure event. SecPortal re-runs the SCA scan after the upgrade commit lands on the target branch and the result attaches to the same finding as a state event. If the SCA scan no longer reports the CVE, the finding moves to verified closed. If the SCA scan still reports it (the upgrade landed on a feature branch that never merged, the lockfile was not regenerated, a transitive pin still pulls the vulnerable version), the finding stays open with the reopen reason captured. Closure on plan does not satisfy the rule; only closure on a verification scan against the post-upgrade branch.
How do we handle transitive dependencies?
Transitive dependencies (the dependencies of your dependencies) are the long tail of the SCA backlog. The triage decision is made against the lockfile, not the manifest, so the triage operates on the resolved version that actually ships. Routing follows the closest-direct-ancestor rule: if the vulnerable transitive dependency is pulled in by a direct dependency the application team owns, the application team is the owner; if it is pulled in by a shared platform dependency, the platform team is the owner. The closure path is usually a version bump on the direct ancestor that pulls in a fixed transitive, or a manual override (npm overrides, Maven dependencyManagement, pip constraints) that pins the transitive to a fixed version. Each closure path is recorded on the finding so the next scan against the same dependency tree inherits the prior decision.
When should we accept the risk and document an exception?
Three conditions justify an exception. The vulnerable function is genuinely unreachable from the deployed application and a reachability re-classification confirms it. The upstream maintainer has not shipped a fix and the cost of replacing the dependency exceeds the residual risk. The upgrade requires a downstream API change that is scheduled but not yet shipped. Exceptions land in the exception register with an expiry date (90 days is a defensible default), a review trigger (next scheduled scan, next dependency upgrade in the same tree, next downstream API change), and the named approver. Exceptions without expiry accumulate into permanent backlog and read as weak controls at audit; exceptions with explicit review cadence stay defensible.
Where do dependency CVEs fit alongside other AppSec findings?
Dependency CVEs sit on the same engagement record as SAST, secret-scanning, DAST, and authenticated-scanning findings. The reachability and prioritisation discipline is specific to third-party components, but the lifecycle layer (detect, classify, route, remediate, verify, close) reads against the same record the rest of the AppSec programme already uses. The handoff between SCA detection and the engineering owner is a routing event on the security record rather than a parallel comment in a scanner UI.
How does AI report generation handle dependency CVE narratives?
AI-generated reports derive the dependency-CVE narrative from the live engagement record. The detection event, the reachability classification, the prioritisation rationale, the routing decision, the closure path (upgrade, workaround, or exception), and the verification scan result land in the report draft as derived narrative rather than reauthored prose. The release owner edits the draft instead of writing from a blank page, and the headline numbers always reconcile to the underlying record because the report is generated from the same record the events live on.
How it works in SecPortal
A streamlined workflow from start to finish.
Detect dependency CVEs through code scanning on the connected repository
SecPortal connects to GitHub, GitLab, or Bitbucket through OAuth and runs SCA against the lockfile and manifest of the repository on every code scan. Findings land on the engagement record with the affected package, the version range that introduces the vulnerability, the CVE identifier, the fixed version, the dependency path (direct or transitive), and the CVSS score from the upstream advisory. The detection is the start of a triage clock that does not stop until the finding is classified, routed, remediated, and verified.
Classify each finding by reachability and exposure
Not every dependency CVE is reachable from the application. The triage step records whether the vulnerable function is called from the codebase, whether the dependency is loaded only in a test or build profile, whether the deployed runtime exposes the affected surface, and whether the asset is internet-facing. The classification lands on the finding with the named triager, the rationale, and the timestamp so the next quarter does not re-litigate the same call from scratch. Findings classified as not reachable land in a separate queue with a documented exception expiry rather than dissolving into a backlog.
Prioritise the queue with CVSS plus EPSS plus KEV plus asset context
Severity from CVSS alone is not enough to queue dependency CVEs. The prioritisation step combines CVSS for impact severity, EPSS for exploitation probability, the CISA KEV catalog for known exploited vulnerabilities, and the asset criticality on the engagement for blast radius. The combined priority lands on the finding so the queue reads as a defensible ordering rather than as a CVSS-only list that buries the actually dangerous CVEs under a wave of unreachable mediums.
Route findings to the named owner of the affected dependency
The asset-to-owner mapping on the engagement resolves which engineering team owns the dependency. Direct dependencies route to the application owner. Transitive dependencies route to the owner of the closest direct ancestor. Shared platform dependencies route to the platform team. The routing event lands on the finding with the named owner, the inheritance rationale, and the SLA so the work crosses the seam from AppSec triage into engineering on a deliberate routing decision rather than dissolving in a hallway conversation.
Drive the upgrade, the workaround, or the documented exception
Three closure paths converge on the same record. An upgrade to the fixed version is the default path; the named owner ships the bump and the activity log captures the commit reference. A workaround (configuration mitigation, runtime control, dependency replacement) is recorded with the rationale and the residual risk. A documented exception (no fix available upstream, the cost of the upgrade exceeds the benefit, the vulnerable code path is genuinely unreachable) lands in the exception register with an expiry, a review trigger, and the named approver. Each path produces evidence the audit can read; the difference is the path the finding actually took, not whether the closure was recorded.
Verify the closure with a re-scan against the upgraded branch
A follow-up code scan against the upgraded branch confirms the dependency CVE no longer reports. The verification scan attaches to the same finding as a state event and the closure moves to verified closed. Closure on plan does not satisfy the rule; only closure on a re-scan that ran after the upgrade landed on the target branch. Closures that did not survive the re-scan (the upgrade was reverted, the lockfile was not regenerated, a transitive pin still pulls the vulnerable version) stay open with the reopen reason captured so the next remediation cycle starts from the same record.
Features that power this workflow
Run dependency vulnerability triage on the engagement record
Detect SCA findings with Semgrep, classify reachability, prioritise with CVSS plus EPSS plus KEV plus asset context, route to a named owner, drive the upgrade or the documented exception, and verify the closure with a re-scan. One record, one trail, one proof. Start free.
No credit card required. Free plan available forever.