A vendor-managed runtime pins a vulnerable library and the vendor's fix is two quarters out — how do you decide what to do?

## Why this case is different Every other blocked-upgrade answer assumes you own the build. Override the version, exclude and declare it yourself, get the constraint raised upstream — all of these require that you are the one running the resolver. When the vulnerable library is baked into a vendor-managed runtime, that assumption fails. You cannot edit the image, the vendor's release train is theirs, and rebuilding the runtime yourself typically puts you outside the support agreement, which trades a security finding for an operational one. So the decision leaves engineering. That is the whole point of the question: an interviewer is checking whether you know how to hand a risk you cannot technically remediate to the people whose job it is to carry it, without either panicking or quietly hiding it. ## Step one: exposure, not score Before any decision, establish whether this matters *here*: - **Is the vulnerable code path used at all?** Many findings inside a broad runtime concern components your workloads never touch. - **What would an attacker have to control?** For a deserialization-class flaw in a data platform, the answer is usually the ingested data — so the question becomes whose data lands in those jobs, and whether it crosses a trust boundary before it does. - **What is actually at stake if it goes wrong?** In this setting it is not customer web sessions; it is the contents of the data lake, the credentials the runtime holds, and the derived models or analytics that are often the organisation's most sensitive intellectual property. A compromise here is a lateral-movement and exfiltration problem, and the blast radius is the credential scope the runtime carries. This assessment is what makes every subsequent conversation credible. "Critical severity" is an input; "this job only processes data we produced ourselves, in a workspace whose credentials reach one bucket" is an argument. ## Step two: the three real options **Reduce exposure.** Shrink what a successful exploit would reach: run the affected workload in its own workspace with its own narrowly scoped credentials, constrain egress so the runtime cannot call out, keep untrusted inputs away from the vulnerable path. This does not clear the finding, and you must not describe it as a fix, but it can convert a serious risk into an acceptable one on a defensible basis. **Move the workload.** If exposure is genuinely high, the honest engineering answer may be that this workload should not run on that platform until it is patched. That is expensive and slow, which is exactly why it is a leadership decision rather than a team one — and why having the exposure assessment first matters. **Accept the risk formally.** Often correct, and it is the option most candidates get wrong by treating it as "do nothing." A risk acceptance that survives an audit has four parts: a **named accountable individual** with the authority to carry it, not a team name; a **written justification** grounded in the exposure assessment rather than in inconvenience; an **expiry** aligned to the vendor's committed date; and a **review trigger** — new evidence of exploitation in the wild, or a change to which data those jobs process — that reopens the decision early. An acceptance without an expiry is not a decision, it is an abandonment. ## Step three: pressure the vendor properly You are a customer, and this is a contractual conversation as much as a technical one. File through the support channel so it exists in writing, ask for a **committed date** rather than a roadmap gesture, and find out whether a patched runtime version already exists on a track you are not on — sometimes the fix is available and the block is your own pinned platform version, which is a much easier problem. Aggregate with other customers where a user group exists. If your renewal or expansion is near, that is legitimate leverage, and security teams that never use it are leaving the strongest tool unused. ## Step four: what you say externally Customers, auditors and questionnaires will ask. The answer is that the component is present, unpatched, with a vendor fix committed for a date, that you have assessed exposure and applied specific containment, and that acceptance is owned by a named person with a review date. That answer holds up. Claiming it is patched does not survive the first scan of your environment, and it converts a manageable finding into a trust problem. ## What separates a principal answer The judgment being tested is not technical cleverness — the technical options are few and obvious. It is whether you know that an unpatchable risk must land on a named owner with an expiry, that containment and remediation are different words you must not blur when talking to a customer, and that vendor lock-in has a security cost which belongs in the next platform decision rather than only in this quarter's findings report.