Damiano Bianda

The vendor-as-back-door pattern keeps recurring because the controls we apply to vendors are documentary while the access we grant them is operational. A security questionnaire is a point-in-time attestation; the vendor's VPN account is a live credential that works every night of the year. The pragmatic shift is to stop trying to audit the vendor into safety and instead minimize what their compromise can reach: vendor accounts in the same joiner-mover-leaver lifecycle as employees (most aren't - nobody tells you when their contractor changed jobs), just-in-time elevation instead of standing access, session recording on vendor paths the way you would for your own privileged admins, and network segmentation that assumes the maintenance account is already in hostile hands. The contractual lever that matters most is also the least used: an incident-notification SLA with teeth, because in these cases the hours between the vendor knowing and you knowing are where the money leaves.

The "no patch, no CVE name yet" situation is where network hygiene earns its keep, because the only controls left are architectural. Three that work even against unnamed bugs: put the management plane on its own VLAN with an ACL that only the admin jump host can reach - most of these switch flaws are only exploitable if you can talk to the management interface at all; turn off remote administration and UPnP-style conveniences, since the factory defaults are exactly what mass scanners enumerate; and treat the box as untrusted even inside your perimeter - 802.1X or at least MAC awareness on downstream ports limits what a compromised switch can be used to reach. The deeper problem is procurement math: a switch bought for a ten-year building lifecycle has a firmware support window of maybe five, so every organization is quietly accumulating a fleet of unpatchable packet-movers. An asset register with an end-of-support date per device is unglamorous, but it is the difference between knowing your exposure and discovering it in someone else's botnet census.

Good walkthrough of an underused header. One boundary worth stating explicitly, because it decides whether the control actually protects you: Permissions-Policy governs features per browsing context, so it is excellent at constraining what an embedded iframe may do, but it does nothing against a third-party script you loaded into the top document itself. A tag-manager script running in your own origin can still call getUserMedia regardless of the header; the only thing that mitigates that is script governance (SRI where possible, CSP script-src with strict allowlists, and ideally not giving the third party your origin at all). The other pairing that matters: Permissions-Policy and CSP frame-ancestors answer different questions - the first says "what may my embedded content do," the second says "who may embed me" - and you need both, because an attacker who can iframe your authenticated page has a clickjacking channel that camera/mic/geo lockdowns never touch. Two headers, two threat models.

The execution gap framing is accurate, and I'd argue the 24-hour early-warning duty is the single most diagnostic requirement in NIS 2, because it converts "do you have security?" into "can you see an incident, classify it, and decide who signs the notification within one day?" Paperwork passes that test only if the monitoring behind it actually works. Two practical consequences worth naming: management-body liability means the person signing needs evidence they asked the right questions, so board-level reporting shifts from posture summaries to detection coverage and mean time to triage; and the supply-chain scope quietly pulls in small vendors who never budgeted for any of this, so their first NIS 2 expense is usually not a tool but discovering which of their customers' contracts now make them an essential or important entity by proxy.

The "funds were not affected" line deserves exactly the skepticism you give it. Crypto can be made whole; identity data can't be rotated. A leaked KYC record - name, address, document image - is a permanent asset for whoever holds it, and its most immediate use is precision phishing: someone who knows you hold a specific card, knows your name, and can cite a real incident has everything needed to craft the follow-up "verify your account" email that actually lands. One thing worth adding to the response checklist for fintech breaches: a pre-planned user-communication channel that does not rely on email, because email is precisely the channel attackers will imitate in the days after the announcement. The first line of these statements tells you about the ledger. The second line tells you about the next six months of phishing.

The framing of spreadsheets as production decisions is the right one, and I'd push it one step further: a critical workbook is unmanaged production code. It has inputs, logic, and a deployment artifact (the file people actually open), and in most organizations none of the three goes through the controls we'd demand from a Python script doing the same calculation: no review of the formulas, no change log, no named owner. The version problem is the nastiest in practice because the file silently forks every time it gets emailed. One cheap control that helps: keep the logic in a read-only master, distribute only a link to it, and record a hash of the version you audited, so later you can tell whether the workbook that made the decision is the workbook you approved. EUC inventories are also becoming an audit topic under operational-resilience rules, so the spreadsheet register has a second life as compliance evidence.

The 'note vs check' framing maps onto a much older security idea: the confused deputy. Anything the model can influence is output, not policy - so the boundary has to live where the model has no write access. In practice that means the harness: an egress proxy with an allowlist, headers constructed by fixed code outside the model's reach, tool schemas that don't accept free-text header fields at all. There's also an asymmetry worth stating plainly: a program check has to work every time, a sentence only has to be outweighed once. And the check is testable - you can write a regression test that fails if the User-Agent ever contains the user's email. You cannot unit-test a paragraph in AGENTS.md. Keep the notes for taste and conventions; keep secrets and PII behind code.

Solid methodology - logging XHR/fetch/sendBeacon with a Resource Timing cross-check is exactly how to settle this question. Two additions worth considering for the next round: embed a unique canary URL or tracking pixel inside the test PDF, so any later server-side access (thumbnail generation, AV scanning, someone opening it) shows up after the upload itself, which is where retention claims actually get tested; and run a second pass for the client-side tools with connectivity blocked after page load - if the tool still processes the file with the network cut, 'runs in your browser' is proven rather than asserted. Agreed that an upload is not automatically malicious: the questions that matter are retention window, deletion SLA, and whether the result URL is unguessable without auth.

Nice walkthrough. One thing worth adding when applying STRIDE to a data flow: the trust boundary does most of the work. Threats cluster where data crosses a boundary you don't control (client to server, service to third party), so enumerating boundaries first and then running STRIDE per crossing keeps the exercise bounded instead of combinatorial. Also, repudiation is the letter teams most often wave away - concretely it's just 'do you have logs that would survive a dispute', and it usually folds into tampering controls like append-only audit logs. Treating it as a logging requirement rather than an abstract threat makes the output actionable.

Good catch on the 'no matching route' detail - that's the part most write-ups skip. A request that never reaches a handler still passes through the global middleware stack, so a parser bug becomes a pre-routing crash, which is why path-based WAF rules don't help here. Two cheap complements to patching: pin the fixed versions in package-lock (transitive pulls of body-parser through older Express releases are the usual way this stays vulnerable), and run the process under a supervisor with a restart limit - otherwise a crash loop turns a recoverable DoS into a permanent outage. Updating the library is the fix; the rest just decides how loud the failure is while you deploy it.