Trusted VPC, Shared Credentials, Two SBOMs

No. CVSS base score describes the vulnerability in the abstract, not the risk in this system. Priority comes from reachability and exposure.

The questions that actually decide the ranking:

• Is the vulnerable code reachable? "The feature is not enabled" is a recollection, not evidence. Verify against the actual serialization configuration, any framework defaults that enable it implicitly, and the runtime classpath of the deployed artifact.
• Who can reach the input? If the deserialization path only consumes internal, schema-validated messages, exposure is lower than if it touches user-supplied JSON. Trace every call site.
• What does compromise yield? The service's privileges decide blast radius. If the process holds broad database or cloud credentials, a lower-probability exploit still ranks high.
• Is there an exploit in the wild? Active exploitation changes urgency more than a score delta does.

Also treat the vendor SBOM discrepancy as a finding in its own right. 40 components reported versus 61 observed means the SBOM is not generated from the artifact and cannot be relied on for any other component. Do not resolve that gap by trusting the smaller number.

Document the verification, because "we checked and it is not reachable" is only an acceptable answer when it is reproducible by the next reviewer.

First, inventory reality rather than intent. Build a list of all 14 services with: the exact resolved version, whether the vulnerable path is reachable, whether the service is internet-facing, and what credentials the process holds. Reachability plus exposure plus privilege gives the ranking; the CVSS score does not.

Then split the fleet into three tiers.

• Tier 1: reachable and internet-facing or holding high privilege. Patch, upgrade, or disable the vulnerable feature with an explicit config assertion and a regression test in the next 24-48 hours. If no fixed version exists, apply a compensating control: block the feature at the deserializer level, tighten input schema validation, or add a rule at the edge.
• Tier 2: reachable but internal-only. Fix in the immediate cycle, before the release.
• Tier 3: proven unreachable. Record the evidence, schedule the upgrade in the normal cycle, and add a test that fails if the vulnerable configuration is later enabled.

Do not let the five-day release dictate the security timeline; instead, decide whether the release can ship with Tier 1 fixed and Tiers 2-3 tracked. Shipping 14 services on the old library because the release date is fixed converts a known problem into 14 known problems.

The root cause is that the build trusts whatever the public repository returns at resolution time, so the artifact is not reproducible and the SBOM does not describe what shipped.

Pipeline controls:

• Resolve dependencies through an internal proxy registry that mirrors only approved versions, so an upstream deletion or hijack cannot silently change what builds.
• Pin exact versions and record a lockfile in source control, with hash verification on every resolved artifact. Without hashes, a same-version content swap is invisible.
• Generate the SBOM from the built artifact as a build step, not from a manifest. That is precisely the gap that produced 40 versus 61. Fail the build if the SBOM cannot be produced or if a component has no version.
• Keep dependency scanning in the build gate with a policy for severity and reachability, plus a periodic re-scan of already-deployed artifacts, since new CVEs appear against unchanged code.
• Require an owner for every dependency and a rule for abandoned components: last release older than a defined threshold triggers a replacement review.

Contractual and process controls: an exit or handover requirement so contractor-introduced dependencies are documented, and an acceptance clause requiring suppliers to provide machine-readable SBOMs with the artifact, not summaries. Track the 14 consumers as a single ownership unit so the next finding does not require a rediscovery exercise.