"It's Not My Code"

Jessy Lang: Welcome back to Security Dialogues. I'm Jessy, and this is episode five. Last time, the closing line was: what happens when the vulnerability isn't in code either of them wrote, but in a component three suppliers deep in something shipped five years ago. Today that's not a thought experiment. Priya Raman is here, and she didn't apply for this — Marcus found her.

Marcus Hale: I found her because I had to. A client's incident review kept hitting a dead end at a vendor who kept pointing at another vendor, who pointed at a library none of us had heard of. It took four days to work out that the library was Priya's, and about four minutes after that to realise she had no idea any of this existed.

Priya Raman: I had no idea any of it existed. Four days is also generous — most companies never find out. You're the first PSIRT that's ever actually called me instead of filing a ticket and walking away.

Jessy Lang: Marcus, Tess — this is where tonight starts.

— I. The Trail That Led to Priya —

Tess Calder: Walk me through the four days. Where did it actually go wrong?

Marcus Hale: The client's own dependency file named a package. That package depended on three others. One of those hadn't been updated on the client's side in two years, which meant the version pinned in their lockfile wasn't the version with the fix — except there was no record anywhere of what "the fix" even was, because nobody had generated a bill of materials for any of this. I was reading changelogs by hand, on GitHub, trying to work out which commit was the security-relevant one, because nothing declared it.

Priya Raman: I declared it. It's in the changelog. Line four: "hardened input validation." I didn't write "SECURITY FIX" in capital letters, because I didn't think of it as a security fix when I wrote it — I thought of it as fixing a bug a user reported.

Marcus Hale: Which is exactly the problem. From where you sat, it was Tuesday. From where I sat, four days in, it was the only sentence in the world I needed and I nearly scrolled past it twice.

Tess Calder: So the information existed. It just existed in a place nobody was reading, in language nobody had agreed meant "drop everything."

Priya Raman: Correct. I don't get to know, when I fix a bug, whether it's "someone's afternoon" or "someone's four-day incident." I fix the bug I can see, in front of me, with the information I have. Nobody downstream ever told me what was riding on it.

— II. Nobody Told Her She Was Infrastructure —

Jessy Lang: Take us back further. How did a personal project end up under a hospital's patient-intake system?

Priya Raman: Nine years ago I needed a small piece of functionality for my own project, couldn't find a library that did it cleanly, wrote forty lines that did, and published them because that's what you do. I didn't market it. I didn't name it "enterprise-ready" anything. Somebody used it. Somebody else's tooling picked it up as a transitive dependency of that. I found out I was inside a hospital's intake system from a stranger's GitHub issue, three years ago, who mentioned it in passing like I'd obviously know.

Marcus Hale: You didn't know.

Priya Raman: I did not know. Nobody tells you. There's no notification that says "congratulations, forty lines you wrote to solve your own problem are now load-bearing for a system where lives are on the line if it goes down." You find out sideways, from someone who assumes you're already aware, because from their side, of course you'd know — you're the maintainer.

Tess Calder: From my side, that's the most useful sentence in this whole conversation. When I'm scoping an engagement, I ask what a target depends on, and I get a list of names nobody in the room can explain. Nobody knows who's behind half of it, whether that person is a company, a team, or one person doing this at eleven at night after a day job. I've never once had a client be able to tell me which of their dependencies are maintained by somebody like you.

Priya Raman: Which is the gap Marcus spent four days falling into. And it's not just the client's gap — it's mine too, in the other direction. I don't know who's downstream of me either. I have download counts. I don't have names. I couldn't tell you today whether a bank is running my code, or a power utility, or a toy. The visibility problem runs both ways, and right now neither side of it exists.

Marcus Hale: So when I called you, that was new information for both of us at once.

Priya Raman: It was. I'd never had a company call and say "here's what you're inside of." Normally I find out from an angry issue, or a security researcher who assumes I already know, or — this once — a stranger's GitHub comment that mentioned "the intake system" like it was small talk.

— III. The Reports That Aren't Real —

Marcus Hale: Since episode four apparently reached you — did the "zero-day" thing land?

Priya Raman: It landed so hard I emailed Jessy asking to come on. I get, on average, one report a month calling itself "critical, immediate action required" for a code path that isn't reachable in any configuration anyone actually ships. Full severity score, no proof of concept, no attempt to check whether the function is even called from outside the library. I have to read every single one closely enough to prove it's nothing, because the one time I don't is the time it's real.

Tess Calder: That's the same shape as Marcus's rate-limit report. Somebody reaching for the loudest word instead of checking whether there was anything under it.

Priya Raman: Except when it lands on Marcus, it's an afternoon out of a paid job. When it lands on me, it's an evening I don't get back, unpaid, on top of the day job that actually pays my rent. I got one of these during a family emergency two years ago — three follow-up emails in one day, "please respond, this is urgent," about a report that turned out to reference a function that doesn't exist in any version I've shipped.

Marcus Hale: Nobody owes you nothing back for that. That's not a process gap. That's just cruelty with a CVSS score stapled to it.

Priya Raman: The worst one wasn't even hostile. A large vendor's automated scanner flags my library every quarter for a vulnerability that was fixed four years ago, in a dependency I dropped three years ago, that isn't even in the current package. Every quarter, a different junior analyst opens a new ticket, because their tool doesn't know I removed it, and every quarter I write the same three-sentence reply. I've started keeping a saved response just for that one. Nobody on their end has ever fixed the scanner.

Tess Calder: So even the "professional" version of this costs you the same attention as the malicious version, just spread out and dressed up as due diligence.

Priya Raman: I've stopped expecting an apology. I'd take a checkbox that says "have you confirmed this is reachable" before the form lets you type the word critical.

— IV. The One That Was Real —

Jessy Lang: Was there ever one that actually was real?

Priya Raman: Once. I found it myself, actually — not a report, my own review, a Tuesday afternoon I'd set aside because I try to read through the parsing logic every year or so. A real injection path, genuinely exploitable, in a function most consumers call without knowing they're calling it. I fixed it, wrote a two-line changelog entry, tagged a release, and moved on. No advisory with my name in lights. No conference talk.

Marcus Hale: Did anyone request a CVE for it?

Priya Raman: I requested one myself, because I'd learned by then that if I don't, someone downstream eventually will, badly, months later, and I'd rather control the description. It has a CVE number. It has almost no readers. I checked the download stats after and traffic didn't move.

Tess Calder: That's the same asymmetry Marcus described with the logging library — a real, quiet, well-handled fix gets no attention, and a fake, loud, badly-checked report gets four days of a PSIRT's time.

Priya Raman: The industry rewards the shape of a crisis, not the fact of one. I found out early that doing this well and doing this loudly are two completely different skills, and only one of them was ever going to help me sleep at night.

— V. Whose Fault, Exactly —

Marcus Hale: I want to say the honest, uncomfortable thing out loud, because it's the reason I invited you rather than just quietly patching and moving on. When this incident closed, the client's first instinct was to ask why they were running unvetted third-party code. Which is a real question. But it landed like an accusation aimed at you, and you weren't in the room to push back.

Priya Raman: I've heard that sentence before, secondhand, and it's the one that actually makes me angry, not the fake reports. "Unvetted" implies someone was supposed to vet it and didn't. I never signed up to be vetted. I published forty lines under a license that says, in plain words, no warranty, use at your own risk. Nobody forced your client to depend on me. They found something free that solved their problem and never once asked whether I had the capacity to be their vendor, because they weren't thinking of me as a vendor. They were thinking of me as a resource.

Tess Calder: From the attacker's side, "whose fault" has never once been an interesting question. I don't care who's supposed to own a dependency. I care whether it's reachable and whether it's been touched since the last disclosure. Blame is a conversation people have after I've already been in and out.

Marcus Hale: So "it's not my code" isn't a defence a client gets to make after the fact. But I don't think "it's my code" gets Priya out of it either, and I don't think she's claiming it should.

Priya Raman: I'm not. I'll own what I actually control: the code, the fixes, being honest in a changelog. I will not own a company's decision to build a product on a dependency they never once looked at, maintained by someone they never once funded, and I will not accept being the person who apologises for that decision after the fact.

— VI. The SBOM That Didn't Exist —

Marcus Hale: Here's the part that made this a four-day incident instead of a four-hour one. The client had no software bill of materials. Not a bad one — none. Day one was spent just getting the vendor to admit which of their vendors was involved, because their own contract with that vendor didn't require disclosure of sub-dependencies either. Day two, I had a package name and no version history. Day three, I was diffing GitHub tags by hand, trying to match a commit hash buried in a lockfile against a changelog that used different language every release. Day four, I finally had the sentence Priya wrote about "hardened input validation" and could confirm the client's pinned version predated it. If an SBOM had existed at any layer of that chain, the moment we knew the vulnerable function's identity, a tool tells us in seconds which products contain it and which version. Instead I reconstructed it by hand, with a search engine, over four days, while a customer asked me hourly what was happening.

Priya Raman: Which is a client failure, not mine. I can't generate an SBOM for your product. I can barely keep one for my own library's own dependencies, and even that's an evening's work I have to carve out on purpose.

Tess Calder: Do you?

Priya Raman: I started two years ago, after the hospital thing. I don't get thanked for it either, but at least when someone asks me what my library depends on, I can answer in one file instead of an afternoon.

Marcus Hale: Which is exactly what an SBOM is for. Not to interrogate you. To let the company that built on top of you answer, in one file, what they actually shipped — so the next time this happens, it's my four minutes, not my four days.

— VII. Who Profits, Who Pays —

Priya Raman: Can I put a number on the table, because I think it clarifies the room. I checked, once, roughly how many companies had my library somewhere in their stack, directly or transitively. It was in the low thousands. I checked how many had ever paid me anything — a sponsorship, a one-time thank-you, a support contract. Four.

Tess Calder: Four.

Priya Raman: Four. One of the companies not in that number has a marketing page listing my library, by name, as one of their "enterprise-grade security features." I have screenshotted it. I have not decided what to do with the screenshot.

Marcus Hale: That's not a gap. That's an extraction. Somebody is generating revenue off unpaid labour and calling the labour a feature of their own product.

Priya Raman: I don't think most of the companies on that list are malicious about it. I think most of them never once thought about it, because nothing in their process ever asked them to. Not their procurement, not their security review, not their board deck. The dependency was free, it worked, they shipped it, and the person who wrote it never crossed their mind again.

Tess Calder: Which is precisely why I don't blame companies for not paying you out of goodness. Goodness doesn't survive a budget cycle. It has to become a line item somebody's accountable for, or it doesn't happen at all.

— VIII. "It's My Code" Doesn't Scale Either —

Priya Raman: I want to be fair to the other side of this too, because it's tempting to end the story with "and if everyone just paid maintainers, we'd be fine," and that's not true either. Even with money, I'm one person. I cannot personally provide the guarantees a thousand companies need. I cannot review every consumer's usage pattern. I cannot promise a four-hour response time to a security report at two in the morning. If a company needs that, "pay Priya more" is not actually the product they're buying, because I don't scale into an SLA no matter how well-funded I am.

Marcus Hale: So even the fair version of this — Priya funded, Priya respected — still leaves a company that genuinely can't tell you, in an emergency, what it's running.

Priya Raman: Right. Paying me fixes the unfairness. It does not fix the blindness. Those are two different problems wearing the same argument, and I've watched companies solve the first one and act surprised the second one is still there. One sponsor of mine funds me generously, genuinely no complaints, and still emailed me in a panic eighteen months ago asking if they were affected by a vulnerability in a completely different library — because paying me didn't give them an inventory of everything else they were running either. Money bought goodwill. It didn't buy visibility.

Tess Calder: And the blindness is the one I actually exploit. I don't care if a maintainer's well-funded. I care whether the company running the code knows it's there.

— IX. What an SBOM Actually Buys —

Marcus Hale: So let me say precisely what I'd change, now that I've lived through the four days it costs not to have one. An SBOM isn't a document I generate to interrogate Priya. It's not even really about Priya at all — it never touches her inbox, never adds to her workload. It's a list my client keeps of exactly what they shipped, version by version, transitively, so that when a vulnerability is disclosed anywhere in that tree, the question "are we affected, and where" is a lookup, not an investigation.

Priya Raman: I'd add one thing to that, from my side. An SBOM also means the next company that finds a real problem in my library can tell, instantly, whether it's worth escalating — because they can see it's a hospital's intake system on the other end, not a hobby project. Visibility runs both directions. It's not just "know what you depend on." It's "know what depends on you," if you're on my end of it.

Tess Calder: Which changes triage on both sides. I'd stop treating every finding against an unpinned dependency the same, because the SBOM tells me which of those dependencies actually reaches something valuable and which one is decorative.

Marcus Hale: It also means the next incident doesn't start with an accusation. If the SBOM already says "yes, we depend on Priya's library, version X, here's why," nobody's first instinct is to ask why an unvetted dependency was running. They already decided to depend on it, on the record, and they own that decision going in, not after.

— X. Paying For It —

Jessy Lang: Practically — who's actually supposed to fund any of this? The SBOM tooling, the maintainer, all of it?

Marcus Hale: The SBOM tooling is the easy half. It's mostly automatable, mostly the client's job, and increasingly a CRA expectation for anyone selling software with digital elements in the EU — not optional much longer either way.

Priya Raman: The maintainer half is the part nobody's solved cleanly. Some of us get by on sponsorship platforms. Some get picked up by a foundation that provides a little funding and a lot of legitimacy. Some get a support contract from exactly one company that actually asked what I needed instead of what they wanted. None of it scales the way the free-download number does. I have low thousands of companies depending on me and four paying me, and that ratio is the whole story in two digits.

Tess Calder: What would actually move that ratio, in your experience — not the ideal answer, the one that's worked even once.

Priya Raman: The one time it worked, a company's security team found me, not procurement — found me because they'd built an SBOM, saw my library load-bearing in three products, and came to me directly with a support contract instead of a bug report. They didn't wait for an incident. They went looking on a quiet day, precisely the kind of day Marcus and Tess keep telling you matters more than the loud one.

Marcus Hale: So the SBOM didn't just shorten my incident. Used properly, it's the thing that finds you before the emergency does.

— XI. Unpaid Trust —

Marcus Hale: Then let's name what this actually was, because I think we've been circling it from three different jobs tonight. Call it unpaid trust — every company in that low-thousands list extended trust to Priya's code without ever agreeing to be her customer, without funding her, most of them without even knowing her name. The trust was real. The relationship never was.

Priya Raman: And an SBOM doesn't fix unpaid trust. I want to be precise about that, because I don't want this to end sounding tidier than it is. It doesn't get me paid. It doesn't stop the next fake critical report landing at midnight. What it does is stop everyone pretending the trust wasn't there in the first place — so the company that depends on me at least knows it, on a quiet Tuesday, instead of finding out on Marcus's fourth day.

Tess Calder: And it gives me, from the other side, one clean question to ask on every engagement from now on: not "is this patched," not "is this a zero-day" — just, does anyone here know Priya's name. If the answer's no, I already know where I'm going first.

Marcus Hale: I'll take that trade. Four minutes instead of four days, and a conversation with a name attached instead of an accusation aimed at no one in particular.

Priya Raman: I'll take being found on a Tuesday instead of during a family emergency. That's a low bar. I'd still call it progress.

— Outro —

Jessy Lang: Unpaid trust — and the fact that the fix for it was never "pay Priya more," even though that would help. It was "stop being surprised she exists." Priya, thank you for coming on to say the parts that don't sound grateful, because I think they're the parts that needed saying. If you maintain something you never meant to become load-bearing, or if you're the PSIRT who's spent four days finding out you depend on someone like Priya, tell us. We read everything. Subscribe wherever you're listening to this, and leave us a rating if you've ever screenshotted a company calling your unpaid labour one of their features. Next time, it's back to just the two of them, and Tess is bringing something she genuinely didn't see coming: one of Marcus's clients swapped out their entire encryption scheme, cleanly, in a week, after she flagged a weakness — and for once, she's not the one with the answers. Until then.