Prioritize vulnerable dependencies from actual exposure

A dependency alert is a starting point for investigation. Confirm the package identity, affected version range and where that version is deployed. A vulnerable version in a lockfile may be absent from the running artifact, or it may appear transitively through another package. Both situations need evidence.

Read the source-owner advisory when available. Identify the affected function, preconditions, impact and fixed version or mitigation. A severity score is useful context, but it does not describe every deployment. A public unauthenticated parser can have different exposure from the same library in an isolated offline tool.

Do not turn 'we do not call that function' into an unsupported dismissal. Trace actual reachability, including framework defaults, optional features and transitive use. If evidence is incomplete, record uncertainty and choose a bounded mitigation or faster review. A documented exception should have an owner, expiry and a condition that triggers reassessment.

Remediation can include upgrading, disabling an affected feature, restricting exposure or replacing the dependency. Prefer a supported fix when feasible and test the affected application behavior. A temporary network restriction can reduce exposure while a patch is prepared, but it should not become an undocumented permanent substitute.

An interview answer should compare two concrete alerts and explain why one comes first. It should also say what evidence would change the order. The objective is to reduce real risk while preserving service, not simply to make a scanner's count reach zero.

Teaching inventory has three findings with invented advisory identifiers. Finding A affects parser-lib 1.2 in a public file-upload service. The vulnerable parser function is called on untrusted uploads, and a supported fixed version exists. Finding B affects archive-lib 3.0 in a developer-only conversion tool that reads trusted local test files. Reachability to the vulnerable path is uncertain. Finding C affects auth-helper 2.4 in a production service, but the built artifact contains a vendor-patched backport whose status needs verification.

A is the clearest immediate exposure. C may also be urgent because authentication impact is material and the backport claim is not yet evidence. B still deserves an owner; 'developer-only' does not mean no risk, especially if the tool later processes untrusted files or runs in CI with secrets.

The table does not prescribe universal deadlines. The organization must choose response targets from its risk policy and incident context. The teaching decision is about the evidence needed to prioritize, not a legal or compliance schedule.

For A, trace request upload through validation into the parser call. A file-extension check does not prove the vulnerable parser cannot be reached; the parser may inspect content after that check. Test the patched behavior with safe regression fixtures in a disposable environment. The course does not require running public exploit code against a live service.

For B, inspect whether the tool is packaged into production images or invoked by CI on external contributions. A repository path labelled tools can still run with sensitive credentials. Verify actual execution context. If it is truly isolated and only processes trusted fixtures, a lower immediate priority can be defensible with a documented owner and review date.

For C, identify the exact deployed package build and vendor advisory. A version string can remain unchanged when a distribution backports a fix. Conversely, a claimed backport may not cover the reported issue. Preserve package provenance and advisory references. Do not suppress the scanner solely because a comment says 'patched.'

A successful dependency update requires more than changing the manifest. Confirm the lockfile or resolved dependency graph, rebuild the artifact, verify the deployed digest and test the affected behavior. A stale container image can keep the vulnerable code running after the repository is fixed. Use the artifact identity practices from the previous lesson.

A regression test should exercise the supported feature around the fixed boundary. Include a valid upload to ensure the patch did not disable all functionality, and a safe invalid fixture that checks the intended rejection. If the fix changes API behavior, update callers through a controlled release. A rushed patch that breaks authentication can create an availability incident, so service checks remain necessary.

For temporary mitigation, record its scope and limit. Disabling public uploads can remove the immediate path while retaining the vulnerable library. A later product change that re-enables uploads must trigger review. The exception record should say what remains, why the temporary control is believed effective and when the supported update will replace it.

Finally, measure closure at deployed scope. One alert may affect several services and environments. Closing the repository ticket after updating one service can leave others exposed. Link each deployment to its fixed artifact or documented exception. This creates evidence that risk changed, rather than a smaller scanner dashboard alone.

Teaching decision record for A: affected parser is in deployed digest D12 and reachable from public upload. Temporarily restrict the upload route under the approved incident plan, update to the supported fixed dependency, rebuild as D13, run valid/invalid fixture tests and deploy D13 through the normal release path. Confirm every active replica uses D13 and restore the route only after checks pass. Record that this is an invented advisory scenario, not a claim about a real package.

A manifest is updated to a fixed version, but production still runs yesterday's image. The scanner on the source repository is green. Is the deployed issue closed? List the evidence needed and one temporary control if the affected feature is public.

No. Source state does not prove deployed state. Verify the resolved dependency in the built artifact, its digest, the active deployment and the affected feature's regression checks. If the public feature is the confirmed entry path, an approved temporary restriction or feature disable can reduce exposure while the fixed artifact rolls out. Record the service impact and expiry. Do not claim remediation from the repository scan alone.

Score out of four: one point for the correct result, one for showing the intermediate reasoning, one for identifying the stated failure case, and one for a verification that could disprove the answer. Do not award the reasoning point for a tool name alone.

Misconception 1: every high-severity alert has identical priority in every environment. Actual deployment, reachability and impact affect the decision. Misconception 2: changing the package manifest closes the issue. The fixed dependency must reach the running artifact and pass relevant checks.

Evidence class: recommended. Original practice.

How do you decide whether to patch an alert immediately or investigate first?

Strong answer: I confirm affected deployed versions and the vulnerable path, assess exposure and impact, check supported fixes and temporary controls, and state uncertainty. I prioritize confirmed reachable high-impact paths while assigning owners to unresolved cases.

Follow-up: How would you validate a vendor's claim that a fix was backported without changing the upstream version string?

Weak answer indicators: Severity-only sorting; unverified reachability dismissals; source-only closure; exceptions without expiry or owner.

Technical references: OWASP vulnerable dependency management; SLSA provenance. Sources support the documented mechanisms. The numbers, decisions, rubrics and interview prompts in this lesson are original teaching examples, not measurements or employer question claims.