An end-of-life PDF parsing library in a claims-intake pipeline has an unfixable memory-corruption flaw. What compensating controls do you deploy?
answer
- no patch is coming, so design for permanence
- shrink what the parser ever sees
- assume compromise, bound the loot
- one document per short-lived process
- a crash is a detection signal
basics
~20 sCut the attack path and the blast radius: pre-filter or transcode documents before the parser sees them, run it unprivileged, network-denied and resource-capped one document at a time, alert on crashes, and give the control an owner and a review date.
solid answer
~50 sNo patch is ever coming, so this is architecture, not a stopgap. Attacker-controlled bytes reach a native parser, so assume the parser will eventually be owned and work on two axes. Shrink what reaches it: cap size and page count, reject or strip the exotic features your pipeline never needs, and where possible normalise documents through a maintained component first so the fragile parser sees a narrower input language. Shrink what an exploit gains: run it as a short-lived unprivileged process per document, with no network egress, no database credentials, no long-lived secrets, a read-only filesystem and hard memory and time limits, so compromise yields one claimant's document rather than the store. Then treat crashes as a detection signal rather than noise, and register the residual risk with a named owner and a scheduled reassessment. A control nobody owns and nobody dates is how a temporary decision becomes permanent.
go deeper
Know the two ideas: reduce what the vulnerable code is exposed to, and reduce what an attacker gains if it fails. Be able to say why customer-supplied files count as untrusted input.
Explain the concrete controls and what each one blocks: input limits and feature stripping on one side, unprivileged short-lived processes without network or credentials on the other. Say why containment is stronger evidence than filtering.
Show you would design for permanence rather than a stopgap, isolate per document, treat crashes as a signal, and attach an owner and expiry to the accepted risk. Interviewers want to hear you distinguish controls you can demonstrate from ones you merely hope work.
Own the framing: what residual risk the business is signing for on regulated personal data, who signs it, and how you prevent every unfixable component in the estate from acquiring its own bespoke, undocumented containment.
## Frame the problem correctly first Two facts define this case. The input is attacker-controlled: anyone who can file a claim can hand you a crafted document. And the flaw is unfixable, because the component is end-of-life with nobody upstream. So this is not "mitigate until the patch lands"; there is no patch, and whatever you build has to be something you are prepared to run for years. The asset at stake is claimants' personal data plus whatever else the parsing host can reach. Memory corruption in a native parser is the worst case for containment reasoning, because a successful exploit usually means arbitrary code execution as that process. So plan for two independent questions: can the attacker reach the flaw at all, and if they do, what do they get? ## Axis one: narrow what reaches the vulnerable code - **Bound the input.** Maximum file size, page count, embedded object count, nesting depth, decompression ratio. Many parser flaws need pathological structure that legitimate claim documents never have. - **Strip or reject features you never need.** Embedded scripts, attachments, external references, exotic encodings, unusual filters. A document pipeline that only needs rendered text and images does not need most of the format. - **Normalise upstream of the fragile component.** If a maintained tool can convert or re-serialise the document first, the end-of-life parser sees output from a program you trust rather than bytes from a stranger. This is the single most effective narrowing available, and it is often overlooked because it looks like extra work in the happy path. - **Do not confuse this with trust.** "Documents come from our customers" is not a control. A customer account is exactly the position an attacker wants, and it is cheap to obtain. Narrowing input is not a fix. It shrinks the reachable subset of the flaw; you do not know how much, and you cannot prove it is zero. ## Axis two: bound what a successful exploit gains This is the axis that actually survives an unknown bypass, so it matters more than the first. - **Isolate per document, not per worker.** A long-lived worker that has already processed a thousand claims holds those documents, its database credentials and its network reach. One malicious file turns all of it over. A short-lived process handling exactly one document caps the loot to that document and the lifetime to that job. - **Drop everything the parser does not need.** No network egress, no credentials in the environment, no mounted data store, an unprivileged user, a read-only filesystem apart from a scratch area, and hard memory, CPU and wall-clock limits. The parser should receive bytes and return structured output over a narrow channel and nothing else. - **Make the output untrusted too.** Whatever comes back from the parser is attacker-influenced; validate it before it reaches the rest of the pipeline. ## Axis three: detect A parser that crashes on real customer input is either badly written or being attacked, and on an unfixable component you want to know either way. Surface crash counts, timeouts and resource-limit kills as monitored signals with the document identifier attached, so you can retrieve the input that caused it. This is the closest thing to an early warning you will get. ## Axis four: govern the decision A compensating control is an accepted risk with engineering attached, and it needs the paperwork of an accepted risk: - the component and why no fix exists; - the specific attack step each control blocks; - the residual risk you are accepting after the controls; - a named owner, and a review date; - the triggers that pull the review forward: a public exploit appearing, a control being bypassed or removed, the pipeline being extended to handle a new document source. Write the expiry down even though it feels arbitrary. Undated mitigations outlive the people who understood why they existed, and the next engineer removes the "weird extra process boundary" during a refactor because nothing told them it was load-bearing. ## What separates a real control from a comforting one Ask four things of anything you propose. Does it break a **specific** step in the attack path, describable in one sentence? Is it **on by default**, enforced by the platform rather than by a convention a future contributor can drop? Does it **survive a restart, a redeploy and a refactor**? Can you **demonstrate** it, ideally by showing a document that would previously have reached the parser and now does not? Controls that fail those tests include: suppressing the scanner finding, adding a log line, documenting that developers should be careful, and pinning the version. None of them change what an attacker can do. ## The exit that is still on the table Even here, keep asking the cheaper questions. Does the pipeline need this format at all? Is a maintained parser available if you accept a fidelity loss? Can this stage move to a managed service whose operator patches it? Containment is what you do while the answer to all of those is no, and it should be reviewed each time one of them changes.
- How do you tell a real compensating control from a comforting one?It breaks a specific, nameable step in the attack path; it is enforced by default rather than by convention; it survives restarts, redeploys and refactors; and you can demonstrate it, ideally by showing an input that used to reach the vulnerable code and now does not. Log lines, warnings in a README and scanner suppressions fail all four.
- Why isolate per document rather than per pipeline worker?Memory corruption hands the attacker the process. A long-lived worker holds many claimants' documents, its credentials and its network reach, so one malicious file yields all of it. A short-lived process per document caps what an exploit can read and how long it survives, which is the difference between one leaked claim and the claims store.
- What do you write down when you accept the residual risk?The component and why no fix exists, each control and the attack step it blocks, the residual risk after those controls, a named owner, a review date, and the triggers that pull the review forward, such as a public exploit or a new document source. Without the owner and the date, the exception silently becomes the permanent design.
You cannot repair the pressure vessel, so you reduce what you put in it and you move it into a blast cell. The cell matters more than the filter, because the filter is the part you cannot prove.
saying these in an interview costs you the question
- Calls a scanner suppression a compensating control
- Treats customer-submitted documents as trusted input
- Adds controls with no owner and no review date
- Assumes the parser is safe because it has never crashed
- Relies on input filtering alone with no containment