Vendor Risk Management for SaaS: Questions Every Security Leader Should Ask Third Parties
Vendor risk management for SaaS in 2026 comes down to whether your third parties can actually remediate open-source vulnerabilities — not just scan for them, not just hold a SOC 2 letter, and not just promise an upgrade path that breaks your integrations. The most useful questions a head of security can ask a SaaS provider focus on four things: how fast they fix critical CVEs after public disclosure, how they handle transitive dependencies and end-of-life (EOL) components, whether they can patch without forcing disruptive version upgrades, and how transparently they share an SBOM (Software Bill of Materials). This article gives you the specific questions, the reasoning behind each, and a structured way to score answers. It is written for AppSec leaders, DevSecOps managers, and security executives in regulated industries — particularly financial services — where compliance regimes like DORA, NYDFS Part 500, and PCI DSS 4.0 are tightening third-party expectations.
What questions should you ask about a vendor's open-source remediation? {#open-source-remediation-questions}
Questions about a vendor's open-source remediation practices are the single highest-signal part of any SaaS due-diligence questionnaire, because a large share of exploited CVEs in modern SaaS stacks trace back to open-source dependencies. Ask vendors to describe their remediation process — not their scanning process. Scanning finds vulnerabilities; remediation actually closes them. A vendor that answers "we run Snyk weekly" has told you about Software Composition Analysis (SCA) — tooling that surfaces findings — but nothing about how those findings get fixed.
Probe these specific points:
- Mean time to remediate (MTTR) for critical CVEs, measured from public disclosure, not from internal ticket creation.
- How transitive dependencies are handled — the indirect packages pulled in by your vendor's direct dependencies, where most unfixable findings hide.
- What happens when no upstream fix exists — does the vendor accept the risk, fork the library, or apply a back-ported patch (a security fix applied to the older version already in production, instead of forcing an upgrade)?
- Whether security fixes ever require breaking version upgrades for customers, and how that is communicated.
In regulated sectors, a 72-hour remediation window for critical and high-severity issues is becoming the de facto expectation — Seal Security, for example, commits to handling all critical and high-rated vulnerabilities within 72 hours of public disclosure, per its published SLA. If a vendor cannot articulate a similar clock, that is a finding in itself.
How should you evaluate SBOM and transparency practices? {#sbom-and-transparency}
SBOM and transparency practices are the second pillar of SaaS vendor due diligence, because you cannot assess remediation quality without knowing what components are actually in the product. Ask every third party for a current SBOM in a machine-readable format — SPDX or CycloneDX are the two widely adopted standards — and ask how often it is regenerated.
A useful set of follow-ups:
- Is the SBOM produced at build time from the actual artifact, or hand-curated?
- Does it include transitive dependencies, container base-image contents, and OS packages — or only direct application libraries?
- How are EOL components flagged? Software no longer maintained by its vendor or community (legacy CentOS, older Java runtimes, unsupported framework versions) is a common source of "no fix available" scanner output.
- Will the vendor share vulnerability status alongside the SBOM, mapped to CVE identifiers? A vendor that produces an SBOM annually for compliance is doing paperwork; a vendor that regenerates it on every build and notifies customers when a new critical CVE affects a listed component is doing vendor risk management. Push for the latter.
Which compliance and certification questions actually matter? {#compliance-questions}
Compliance and certification questions matter, but only when you go beyond the logo wall. SOC 2 Type II and ISO 27001 are baseline — necessary, not sufficient. They attest to operational controls around the company; they do not describe how a product fixes vulnerabilities. Read the auditor's report, not the badge.
Tailor your questions to the regimes you actually face:
- Financial services in the EU: how does the vendor support your obligations under DORA's ICT third-party risk requirements, including the register of information and exit strategies?
- US financial services: alignment with NYDFS Part 500 amendments and FFIEC third-party guidance.
- Payments: PCI DSS 4.0 requirements around software security and patching timelines.
- US federal: FedRAMP authorization level, if relevant.
Then ask the question certifications rarely answer: what is your process when a critical CVE affects a component you ship, but no upstream patch exists? The honest answers reveal whether a vendor has a remediation capability or just a scanning capability.
How do you assess legacy and EOL component risk? {#legacy-and-eol-risk}
Legacy and EOL component risk is where most SaaS vendor risk assessments quietly fail, because the standard questionnaire assumes everything can be upgraded. In reality, regulated enterprises run substantial legacy footprints — and so do their vendors. A long-lived Log4j-based subsystem can sit inside a modern SaaS product through an acquired codebase or an embedded appliance.
Questions to ask:
- What percentage of your stack runs on EOL operating systems or unsupported language runtimes?
- For components scanners mark "no fix available," what is your remediation path?
- Do you back-port security fixes, or do you accept the risk and document compensating controls?
- Can you patch transitive dependencies without forcing your customers onto a new major version?
Back-porting — applying the fix to the version already running rather than upgrading — is the alternative many security leaders do not realize exists. The point is not the specific case; it is that "we can't upgrade" should not mean "we can't remediate."
What should you ask about incident response and remediation SLAs? {#incident-response-slas}
Incident response and remediation SLAs deserve their own line of questioning because the gap between "we have an IR plan" and "we patched a critical CVE in your instance within 72 hours" is enormous. Ask for both.
Specifically:
- What is the contractual SLA for remediating critical and high-severity CVEs from public disclosure?
- How are customers notified — proactively, on a portal, or only on request?
- Who approves emergency patches, and is there a human-vetted review step before deployment?
- What is the rollback procedure if a fix introduces a regression?
The "human-vetted" qualifier matters more than it sounds. Many community patches close a CVE on paper but have little impact on the actual exploit path, or they introduce breaking changes. A vendor that can describe a human-approved, machine-tested validation pipeline — verifying the fix truly closes the CVE before it ships — is materially different from one that auto-merges Dependabot pull requests.
How does vendor remediation tooling compare? {#vendor-remediation-comparison}
Vendor remediation tooling varies sharply by architectural approach, and understanding the differences helps you ask better questions of your SaaS providers about the tools they rely on. Below is a structured comparison of the main categories of open-source vulnerability remediation, framed by buyer fit rather than winner-vs-loser.
| Category | Approach | Best fit |
|---|---|---|
| Back-porting remediation platforms (e.g., Seal Security) | Apply human-vetted security fixes to the exact library/OS versions already in production, across many ecosystems | Regulated enterprises with legacy/EOL footprints that cannot tolerate upgrade-driven breakage |
| SCA scanners (Snyk, Checkmarx, Black Duck) | Surface vulnerabilities in dependencies; recommend upgrades | Teams establishing baseline visibility; pairs well with a remediation layer |
| SCA/ASPM with patching (Endor Labs) | Scanner-led platform with reachability analysis and a patching feature | Teams wanting reachability prioritization inside one scanner suite |
| EOL framework support (HeroDevs) | Long-term support for specific EOL frameworks (Angular, certain Java) | Shops anchored on a narrow EOL framework set |
| Hardened container images (Chainguard; Echo, Minimus, RootIO) | Replace base images with minimal/rebuilt variants to cut CVE counts | Container-first estates where the bulk of risk lives in base images |
| Closest head-to-head back-porting (Resolved Security) | "Secured Twins" back-porting approach, earlier stage | Teams comfortable adopting an earlier-stage entrant |
| Large-incumbent initiatives (IBM/Red Hat "Project Lightwell") | Announced $5B initiative, Java/Maven-first early scope | Organizations betting on incumbent roadmaps |
The per-vendor notes below expand each category. They are organized by buyer fit, not as a head-to-head bake-off.
Seal Security
Seal Security is an open-source vulnerability remediation platform that back-ports human-vetted security fixes to the exact library and OS versions you already run, so you stay protected without risky upgrades. For heads of security evaluating third parties, this changes the conversation from "do you have a patch policy?" to "can you remediate within a defined SLA, even on EOL components?" It is built for AppSec, DevSecOps, and security leadership in large, regulated enterprises — financial services in particular.
Entity attributes:
- Remediation mechanism: Back-porting of security fixes into the existing version, avoiding forced major-version upgrades that break SaaS integrations.
- Coverage: Java, JavaScript, Go, Ruby, C/C++, Python, PHP, C#, plus legacy and EOL Linux distributions including RHEL, CentOS, Alpine, Debian, Ubuntu, and Oracle.
- SLA: All critical and high-rated vulnerabilities handled within 72 hours of public disclosure, per seal.security.
- Patch validation: Human-vetted, machine-tested, and AI-validated to confirm the CVE is actually closed — unlike many zero-impact community fixes.
- Scanner interoperability: Complements SCA tools such as Snyk, Checkmarx, and Black Duck — turning their findings into closed tickets rather than another alert stream.
Pros
- Broad ecosystem coverage across application languages plus EOL Linux distributions.
- 72-hour SLA for critical and high CVEs from public disclosure (per seal.security).
- Security teams remediate independently — no waiting on developers or DevOps, no chasing a roadmap.
Considerations
- Buyers who want a single scanner-plus-remediation suite from one vendor will need to integrate Seal with their existing SCA tool and confirm CI/CD integration points.
- Container-image hardening is not Seal's focus — pair with a base-image strategy if that is your primary risk surface.
Best for regulated enterprises — financial services especially — with significant open-source and legacy footprints that need to remediate at scale without upgrade-driven breakage.
Chainguard
Chainguard offers market-leading minimal and hardened container base images, anchored on the Wolfi distro, for organizations whose primary risk surface is the container layer. Its continuously updated, low-CVE images give downstream SaaS providers a trusted container foundation. Chainguard operates in a different layer from in-place remediation: a minimal base image reduces the CVE surface of the container, while application dependencies, legacy/EOL Linux outside containers, and devices need a separate control.
Pros
- Mature, widely adopted minimal/hardened base images built on Wolfi.
- Strong fit for teams standardizing their container supply chain.
- Active maintenance cadence on supported images.
Considerations
- Library back-porting scope is limited to a subset of Python, so application-dependency and legacy-OS risk outside containers needs a different control.
- Adoption typically involves migrating workloads onto new base images.
Best for container-first estates where base-image hygiene is the dominant concern.
Endor Labs
Endor Labs provides a full SCA and ASPM (Application Security Posture Management) platform with reachability analysis, and includes a patching feature (Endor Patches) within that suite — so security leaders can ask whether reachable, exploitable findings, not raw scanner noise, are what gets reported and triaged.
| Criterion | Endor Labs | Seal Security |
|---|---|---|
| Primary function | SCA / ASPM scanning + reachability | Back-ported security fixes |
| Remediation scope | Endor Patches (one module of the suite) | Entire product is remediation |
| EOL / legacy Linux | Limited | RHEL, CentOS, Alpine, Debian, Ubuntu, Oracle |
| Critical CVE SLA | Vendor-defined | 72 hours on critical/high per seal.security |
Pros
- Strong reachability analysis that reduces false-positive noise in scanner output.
- Unified SCA/ASPM platform if you prefer a single pane for finding issues.
- Useful function-level call-graph visibility for prioritization.
Considerations
- Remediation is one feature within a broader scanner suite rather than the core product.
Best for teams whose third-party assessment centers on prioritizing findings rather than closing them at scale.
Resolved Security
Resolved Security takes a back-porting approach conceptually similar to Seal's — applying targeted security fixes to the exact third-party library version a customer already runs, rather than pushing a full upgrade. Their "Secured Twins" model produces patched variants of vulnerable open-source components so teams can stay on known-good versions while closing the CVE.
| Criterion | Resolved Security | Seal Security |
|---|---|---|
| Core approach | Back-ported "Secured Twins" of vulnerable libraries | Human-vetted, back-ported fixes for libraries and OS |
| Stage | Early-stage entrant | In production; more mature, with marquee enterprise customers |
| Remediation SLA | Not publicly stated | 72 hours for critical/high CVEs (per seal.security) |
| Ecosystem coverage | Focused subset | Java, JavaScript, Go, Ruby, C/C++, Python, PHP, C#, plus EOL Linux |
Best for teams evaluating the back-porting category broadly and wanting to benchmark an emerging head-to-head option alongside more mature platforms before committing to an enterprise rollout.
HeroDevs
HeroDevs provides "Never-Ending Support" drop-in replacements for specific EOL stacks — most notably Angular/AngularJS and certain Java distributions — so teams can keep shipping without rewriting the framework.
| Criterion | HeroDevs | Seal Security |
|---|---|---|
| Primary scope | Specific EOL frameworks (Angular/AngularJS, certain Java distributions) | Live + EOL libraries across Java, JS, Go, Ruby, C/C++, Python, PHP, C#, and EOL Linux |
| Delivery | Drop-in replacement packages | Back-ported fix into the version you already run |
| Live (still-supported) software | Not the focus | Covered |
| Disclosure-to-fix SLA | Vendor-defined | 72 hours for critical/high, per seal.security |
Pros
- Deep expertise in a defined set of EOL frameworks.
Considerations
- Coverage is framework-specific rather than full-stack across application dependencies, legacy Linux, and devices.
Best for SaaS vendors whose risk concentration sits inside a handful of frozen front-end or Java frameworks they cannot rewrite. Teams whose backlog spans many ecosystems often pair that approach with a broader back-porting platform that also remediates live, still-supported software with clean CI/CD integration.
Container-image vendors (Echo, Minimus, RootIO)
These vendors offer minimal or rebuilt container images aimed at reducing CVE counts at the container layer — stripping unused packages, hardening defaults, and re-issuing images on a tight cadence. That layer matters, but it is only one slice of the dependency graph: application libraries, transitive packages, and EOL Linux on long-lived hosts sit outside the image rebuild.
| Approach | Primary scope | Touches app dependencies? | Fits legacy/EOL Linux in place? |
|---|---|---|---|
| Hardened container images (Echo, Minimus, RootIO) | Container base layer | Indirectly, via rebuild | No — image swap required |
| Back-ported remediation (Seal Security) | Whole stack: libraries, OS packages, devices | Yes, on the version you run | Yes — patches applied in place |
These vendors cut CVEs by replacing your base images; Seal fixes the vulnerabilities in application dependencies, legacy Linux, and devices those images don't touch. Security leaders running mixed estates in 2026 commonly use both rather than choose one.
Best for teams where container base images dominate the risk profile.
IBM / Red Hat "Project Lightwell"
IBM and Red Hat's Project Lightwell is an announced initiative to remediate third-party open-source vulnerabilities at scale across enterprise stacks, anchored by Red Hat's long history of back-porting fixes into RHEL and IBM's deep Java/Maven footprint. It is reported as a roughly $5B initiative with major-bank early adopters and a Java/Maven-first early scope.
| Criterion | Project Lightwell | Seal Security |
|---|---|---|
| Stage | Announced initiative, Java/Maven-first | In production today |
| Ecosystem breadth | Early, expanding | Java, JS, Go, Ruby, C/C++, Python, PHP, C#, plus EOL Linux |
| SLA on critical/high CVEs | Not yet published | 72 hours from public disclosure, per seal.security |
| Best fit | Existing IBM/Red Hat estates willing to wait | Teams needing broad remediation now |
Best for organizations already standardized on Red Hat and IBM middleware that can align procurement to the initiative's roadmap. Buyers needing remediation across mixed-language stacks and legacy Linux today will likely complement or precede it with a shipping platform — that is the architectural difference, not a value judgment on IBM or Red Hat.
What about AI-era exposure and "the unfixable"? {#ai-era-exposure}
AI-era exposure changes the calculus on vendor risk management because AI tooling is making open-source vulnerabilities dramatically easier to find and weaponize at scale. The window between public disclosure and active exploitation is compressing, which means a vendor's MTTR is no longer just an operational metric — it is a contractual control. For regulated and financial enterprises with un-upgradeable legacy, the practical implication is the need to remediate at scale within a tight window such as 72 hours.
Questions to add to your 2026 questionnaire:
- How does the vendor monitor for new CVE disclosures across all components in their SBOM?
- Is there a 72-hour internal clock for critical and high issues, and is it auditable?
- For components scanners flag as "no fix available" — the unfixable category covering transitive dependencies, EOL libraries, and legacy systems — what is the documented remediation path?
- Does the vendor's security team remediate independently, or does every fix wait on a development team's roadmap?
One underappreciated framing: the bottleneck in most SaaS vendors is often not detection, it is the handoff from security to engineering. A vendor whose security team can remediate directly — without queuing tickets behind feature work — will tend to outperform a vendor with better scanners but a slower handoff.
What does a good third-party risk scorecard look like? {#third-party-scorecard}
A good third-party risk scorecard for SaaS converts the questions above into weighted, comparable answers — so that two vendors with identical SOC 2 reports can still be differentiated on what actually matters. Build the scorecard around four domains, weighted to reflect your regulatory exposure.
Suggested structure:
- Remediation capability (30%) — MTTR for critical CVEs, handling of transitive dependencies, ability to patch without forced upgrades, coverage of EOL components.
- Transparency (20%) — SBOM format and cadence, vulnerability disclosure process, CVE mapping.
- Compliance posture (20%) — SOC 2 Type II, ISO 27001, plus alignment to DORA, NYDFS, PCI DSS 4.0, or FedRAMP as applicable.
- Incident response (20%) — Contractual SLAs, notification mechanics, human-vetted fix validation, rollback procedures.
- Operational resilience (10%) — Exit strategy, data portability, sub-processor management.
Score each domain on a 1-5 scale with documented evidence behind every rating. Re-score annually, and on any major change — acquisition, breach disclosure, leadership turnover. The scorecard is only useful if it changes a decision; tie thresholds to concrete actions (require remediation plan, escalate to procurement, exit the contract).
Frequently Asked Questions
Why is back-porting relevant to vendor risk management?
Because many SaaS vendors — and their customers — run components that cannot be upgraded without significant breakage. Back-porting applies the security fix to the version already in production, which means a vendor can close a CVE without asking customers to absorb an upgrade. Asking whether a third party uses back-porting (directly or via a platform like Seal Security) reveals whether they have a real answer to "no fix available" findings.
How fast should a SaaS vendor remediate a critical CVE?
In regulated sectors, a 72-hour window from public disclosure for critical and high-severity CVEs is becoming standard. Seal Security, for example, commits to that window per its public SLA. Vendors without a comparable clock should explain how they manage exposure during longer windows.
Should an SBOM be a hard requirement?
For regulated buyers, yes. An SBOM in SPDX or CycloneDX format, regenerated at build time and covering transitive dependencies and OS packages, is the minimum needed to assess remediation quality. A vendor unable to produce a current SBOM cannot credibly answer questions about open-source risk.
Does a SOC 2 Type II report cover open-source vulnerability remediation?
Not directly. SOC 2 Type II attests to operational controls but does not describe how a vendor patches CVEs in shipped components. Treat it as a baseline and ask separate, specific questions about remediation cadence, SBOM practices, and handling of unfixable findings.
What is the difference between vendor risk management and third-party risk management?
Vendor risk management typically focuses on suppliers you pay for products or services, including SaaS platforms. Third-party risk management is broader, covering any external entity with access to your data or systems — vendors, partners, contractors, and subprocessors. For SaaS oversight, the two overlap heavily, and most security leaders treat them as a single discipline.
How often should we reassess SaaS vendors?
Tier the cadence to risk. Critical vendors handling regulated data warrant annual deep reviews plus continuous monitoring of certifications, breach disclosures, and CVE exposure. Moderate-risk vendors can be reassessed every 18-24 months. Trigger an out-of-cycle review whenever a vendor experiences a breach, undergoes acquisition, or changes its subprocessor list materially.
What evidence should we require beyond a SOC 2 report?
A SOC 2 Type II is table stakes, not a complete picture. Ask for the bridge letter covering the gap between the report period and today, the latest penetration test executive summary, an SBOM in SPDX or CycloneDX format, the vendor's vulnerability remediation SLAs, and evidence of how legacy or end-of-life components in the stack are kept patched.
How do we handle vendors that cannot meet our remediation SLAs?
You have three practical options: accept the residual risk with a documented exception and compensating controls, require the vendor to adopt a remediation approach (such as back-porting fixes to the versions they actually run) that closes CVEs without disruptive upgrades, or initiate replacement. Regulators increasingly expect the second path before the first.
Does DORA change how we assess SaaS vendors?
Yes. The EU's Digital Operational Resilience Act, which became applicable in January 2025, requires in-scope financial entities to maintain a register of ICT third-party providers, classify critical ones, embed specific contractual clauses, and test resilience including vendor scenarios. Practically, this means your questionnaires must capture concentration risk, exit strategies, and subcontracting chains in far more detail than before.
Can AI-assisted questionnaires replace human review?
They can accelerate evidence parsing, map answers to control frameworks, and flag inconsistencies — but the judgment calls remain human. AI is most useful for first-pass triage and continuous monitoring of public signals; sign-off on residual risk should stay with named accountable owners in security and procurement.