Margin of Safety #54: Code Security, TPRM, and the SaaS Visibility Problem

Mythos put code vulnerabilities on everyone’s radar. The harder question is whose code we should actually be worried about

The Mythos/Glasswing announcement put code security at the top of a lot of security teams’ agendas. We’ve written about the ITAR implications and the limits of Glasswing’s scope. But the question it mostly left unanswered is the one that actually keeps TPRM teams up at night: what do you do about the vendors you can’t audit for code security, and especially the ones you can’t replace either?

Every IT or TPRM team can identify vendors that are impossible to replace: ones whose products run critical business processes or infrastructure (EHR, ERP, IdP, etc). Many are legacy incumbents, deeply entrenched and carrying the technical debt that comes with it. That’s manageable when assessments catch minor gaps, but it becomes a structural problem if the threat model shifts to code-level exploitation. In that world, those untouchable vendors are exactly where the debt accumulates. Some fraction would not pass a rigorous code security assessment. The CSRB’s findings on Microsoft’s Storm-0558 intrusion illustrate the point. While we believe that many smart people have subsequently worked to improve Microsoft’s posture, there’s no reason to think Microsoft is uniquely susceptible to insecure practices.

The code you don’t own (or see) is still risk surface

Take a mid-sized enterprise — a financial services firm with a few hundred engineers. They produce a meaningful amount of code internally. But then count what they consume: dozens of SaaS applications, each running hundreds of thousands (millions for the big ones) of lines of code the enterprise has never seen and cannot audit. Add those vendors’ own dependencies, some of them also SaaS. The total exposure surface from code the organization doesn’t touch almost certainly dwarfs what it does own.

Security programs treat this inconsistently. Application security resources concentrate on code the organization controls. TPRM evaluates vendors through questionnaires, SOC 2 reports, and pen test attestations — tools designed to assess whether a vendor has reasonable security practices, not whether their codebase contains exploitable vulnerabilities right now.[1]

The shift from packaged software to SaaS makes this harder. With on-premise software, a vulnerability was scoped to a specific version an organization could patch on its own timeline, and potentially scan with its own tooling. SaaS doesn’t work that way. The vendor ships continuously [2]; the enterprise can’t scan versions, pin them, or even necessarily know when a version changes. There’s no choice but to fully trust the vendor’s development and deployment practices.

Where the actual threat actors are

Today, no major threat actors are focused on this exact problem. Cl0p and similar groups have demonstrated real sophistication in supply chain attacks, but their campaigns — MOVEit, GoAnywhere, Accellion — consistently target distributed software. The actors who target the SaaS supply chain — Scattered Spider, ShinyHunters — generally don’t exploit code vulnerabilities. They go through identity: phishing, credential theft, MFA fatigue, help desk social engineering. Each group has developed institutional capabilities that don’t transfer cleanly to a model where initial access requires finding software vulnerabilities in code they can’t see.

The scenario that changes this

How much code vulnerabilities become a first-order SaaS risk depends on whether threat actors get creative about discovery. If models get meaningfully better at identifying vulnerabilities from partial information [3], then some creative attack group may decide to experiment with new access methods. We’re not predicting this imminently. But it’s a reasonable planning assumption over three to five years. Organizations that built TPRM programs entirely on questionnaires and attestations will find themselves with little useful visibility into their actual exposure.

The trusted intermediary opportunity — and its uncomfortable ceiling

There’s a real tension facing SaaS vendors. Enterprise customers would benefit from genuine visibility into vendor code security posture — not self-attested SOC 2s, but actual evidence about code quality, vulnerability density, and security engineering practices. But SaaS vendors have legitimate reasons to resist. A mature product’s business logic is a core asset. Exposing it to external customer security reviews creates impossible levels of IP risk, and at scale it’s operationally infeasible.

The SaaSPocalypse sharpens this. Vendors under consolidation pressure need to win deals. Enterprises reducing vendor footprints are doing more diligence per vendor. AI-era procurement now includes questions about AI-generated code, model data access, and development security practices that weren’t on standard templates two years ago.

This looks like a structural opening for security providers as trusted intermediaries — analogous to financial auditors. An independent party with the technical access to assess code security rigorously, contractual incentives to protect vendor IP, and credibility to issue attestations procurement teams can rely on. Vendor submits to assessment; assessor issues a time-bounded attestation; enterprise uses it without ever seeing the underlying code.

SOC 2 is the obvious comparison and the obvious objection: it already covers security controls. But SOC 2 answers “does the organization have a vulnerability management program,” not “are there currently exploitable vulnerabilities in this application.” If the threat model shifts toward code-level exploitation, that distinction matters.

Here’s the cynical version of why this is hard to build: any attestation framework worth trusting has to be willing to fail vendors. That runs directly into a problem TPRM programs have quietly lived with for years. Every enterprise has two or three vendors so deeply embedded that no realistic security finding could trigger a migration. The EHR vendor that owns your clinical data. The ERP every finance process runs through. The identity provider that would take three years to replace. Many are multi-billion-dollar incumbents with decades of technical debt and acquisition-era code that was never fully audited. Some fraction would not pass a genuinely rigorous code security assessment.

If the answer to a failed attestation is always “noted, added to risk register, relationship continues,” the framework becomes another checkbox — better-informed than a questionnaire, but equally toothless. The financial audit analogy holds here too: auditors don’t walk away from systemically important clients. The question for a code security intermediary is whether it can find a middle path — compensating control requirements, time-bound remediation commitments — that creates genuine pressure without demanding the operationally impossible. That’s a harder product design problem than the technical assessment itself.

What we’re watching for

Current threat actor patterns — identity-focused attacks on SaaS, code-focused attacks on distributed software — remain the more pressing operational concern. Fixing MFA coverage and monitoring for credential-based anomalies still matters more than solving code attestation for most teams.

But for organizations refreshing TPRM frameworks, it’s worth assuming code security visibility will become a standard vendor evaluation dimension, not an advanced-tier ask. And for security vendors: the intermediary role is underbuilt. SOC 2 didn’t emerge from a regulatory mandate — the market needed a tractable mechanism for trust and created one. The market needs one again, and it’s not obvious who provides it. What’s clear is that whoever tries has to decide early whether they’re building a real attestation standard or a better-looking questionnaire. The #SectorGiantFoo problem is the forcing function that separates one from the other.

If you’re building in this space, we’d like to hear from you.

Feel free to reach out to jpark@forgepointcap.com and kshih@forgepointcap.com.

This blog is also published on Margin of Safety, Jimmy and Kathryn’s Substack, as they research the practical sides of security + AI so you don’t have to.