Software supply chain security for B2B SaaS: rules, incidents, 90 days

For a B2B SaaS company, software supply chain security means three things: knowing every open source package, base image, CI action and third party integration that ends up in the product you sell, being able to prove it to the customers and auditors who ask, and answering "are we affected?" in hours when the next poisoned package or stolen integration token is in the news. In the US most of the pressure arrives through contracts, the SOC 2 report customers demand and SEC disclosure rules for listed companies; for EU sales, the Cyber Resilience Act now reaches the parts of your product that customers install, and its reporting duties have applied since 11 September 2026. A focused 90 day program takes most SaaS teams from scanner output and questionnaire spreadsheets to a working inventory, enforced build rules and evidence a customer can read.

This guide covers the software a SaaS company runs and ships, the rules and frameworks that apply with their current status, the public incidents of the last three years, who owns which part of the problem, and a 30/60/90 day plan that works with whatever tools you have. Safeguard appears only in the section called "How Safeguard does this". Nothing here is legal, regulatory or audit advice; read the primary texts linked in Sources before you rely on a summary.

Key takeaways

• A SaaS vendor's supply chain is wider than its package manifest: open source libraries, base images, CI actions and runners, infrastructure as code, the SDKs and agents you ship, AI components, and every OAuth integration your customers connect.
• SOC 2 is still the document most deals turn on. The Trust Services Criteria never say "SBOM", but CC6.8, CC7.1, CC8.1 and CC9.2 are where supply chain evidence lands.
• The EU Cyber Resilience Act covers products with digital elements and their remote data processing solutions. For a SaaS vendor that usually means the CLI, SDKs, agents, apps and self hosted editions you place on the EU market. Article 14 reporting has applied since 11 September 2026; the rest applies from 11 December 2027.
• OMB M-26-05 (23 January 2026) rescinded the federal attestation memos but lets agencies require an SBOM on request, and for a cloud platform it says that SBOM should cover the runtime production environment.
• The incidents that hurt SaaS companies most since 2024 came through the build and integration layers: a backdoored compression library, a compromised CI action, a self replicating npm worm and stolen OAuth tokens from a connected app.
• Every Safeguard capability in this post is generally available (GA): SBOM generation and analysis, SCA with deep transitive dependency scanning, vulnerability management with EPSS and CISA KEV enrichment, reachability analysis and prioritization, policies, gates and guardrails, license compliance, autonomous remediation (which ships switched off, every category set to Manual), the Portal SBOM Repository and sharing, CSAF and VEX upload, the compliance and GRC suite, the Trust Center, TPRM, the CLI and the local runner.

The situation

The trigger in a SaaS company is rarely a regulator. It is a deal. A prospect's security team sends a long questionnaire, asks for your SOC 2 Type II report under NDA, and adds a newer line: provide an SBOM for the product in scope and describe how you track vulnerabilities in third party components. Sales wants the answer by Friday.

The second trigger comes from outside. A widely used npm package is reported compromised on a Monday morning. By lunch, enterprise customers are asking whether you ship the affected versions, and a bank customer points to the incident notice clause in your contract. The CISO needs a yes or no, with evidence, by the end of the day.

The third trigger is the SOC 2 audit window, with a request list for production changes, scan history and vendor assessments. A bad week is all three at once, each needing the same facts (what is in the product, what is vulnerable, what changed and who approved it), assembled by hand.

What software does a B2B SaaS company run?

A SaaS vendor is both a software producer and a heavy software consumer, and the supply chain question covers both directions.

The product you build and run. Application code with hundreds to thousands of direct and transitive open source dependencies per service, container base images and their operating system packages, infrastructure as code, browser scripts and, increasingly, AI components such as model weights, inference SDKs and agent tool definitions.

The build and delivery system. CI and CD pipelines, runners, the third party actions each pipeline calls, registries, and the signing keys and deployment credentials those pipelines can reach.

What you ship into customers' environments. The part many SaaS teams forget. Most SaaS products ship something customers install: a CLI, SDKs, an on premises agent, a browser extension, mobile or desktop apps, or a self hosted edition. In the EU each can be a product with digital elements under the CRA.

The services you depend on. Cloud, identity, payments, messaging, observability, support and CRM platforms and AI model APIs, many of them subprocessors you list for customers and assess under SOC 2 CC9.2.

The integrations your customers connect. OAuth apps, API keys and webhooks that let your product into customers' other platforms, or other vendors' apps into yours. These tokens are long lived and privileged, and the 2025 incidents below show they lead straight to customer data.

Which regulations and frameworks apply to SaaS software?

Most US SaaS vendors are not regulated as software makers. Obligations reach them through three channels: assurance reports and contracts their customers require, rules that bind their customers and flow down by contract, and a few rules that apply to the vendor directly (SEC disclosure for listed companies, and the CRA and NIS2 for EU business).

SOC 2 and the Trust Services Criteria

SOC 2 is an attestation report issued by a CPA firm against the AICPA's 2017 Trust Services Criteria (points of focus revised in 2022). It is not a law, but for a B2B SaaS vendor it is close to a licence to sell to enterprises. The criteria never mention an SBOM, but four common criteria carry most supply chain evidence:

• CC6.8: the entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software.
• CC7.1: the entity uses detection and monitoring procedures to identify configuration changes that introduce vulnerabilities and susceptibilities to newly discovered vulnerabilities. Dependency and image scanning, and how fast you act on new CVEs, are tested here.
• CC8.1: changes to infrastructure, data, software and procedures are authorized, designed or acquired, configured, documented, tested, approved and implemented. A dependency upgrade and a CI configuration change are both changes.
• CC9.2: the entity assesses and manages risks associated with vendors and business partners.

The auditor asks for changes with review and test evidence, scan output with remediation dates measured against your own SLA, vendor reviews, and exceptions with approvals. If your policy says critical vulnerabilities are fixed in 15 days, the auditor samples critical findings and checks the dates.

Many SaaS vendors selling outside the US also hold ISO/IEC 27001:2022 certification. Its Annex A covers supplier relationships and the ICT supply chain (controls 5.19 to 5.23), technical vulnerability management (8.8), secure coding (8.28) and outsourced development (8.30), so the same evidence serves both.

The EU Cyber Resilience Act (Regulation (EU) 2024/2847)

The CRA sets cybersecurity requirements for products with digital elements made available on the EU market. It entered into force on 10 December 2024. Chapter IV, on notifying conformity assessment bodies, applied from 11 June 2026; the Article 14 reporting obligations applied from 11 September 2026; and the regulation is fully applicable from 11 December 2027. Products already on the market before that date are covered only if they undergo a substantial modification, but the reporting obligations apply to them too.

Scope matters most for SaaS. A product with digital elements is a software or hardware product and its remote data processing solutions, meaning processing at a distance whose software the manufacturer designs and develops (or has developed under its responsibility) and without which the product could not perform one of its functions. In practice, a hosted application that is not the backend of an installed product is generally outside the CRA and, where the provider is in scope, under NIS2. Software customers install (CLI, SDKs, agents, apps, browser extensions, self hosted editions) is generally inside it, together with the cloud backend it needs to function.

For in scope products, Annex I Part II point (1) requires manufacturers to identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used, machine readable format covering at the very least the top level dependencies. The SBOM sits in the technical documentation for market surveillance authorities; there is no duty to publish it. Manufacturers that integrate third party components, including open source, must exercise due diligence so those components do not compromise the product.

Article 14 is already live. Manufacturers notify actively exploited vulnerabilities and severe incidents through ENISA's Single Reporting Platform, to the CSIRT of their main establishment and to ENISA: an early warning within 24 hours, a notification within 72 hours, and a final report no later than 14 days after a corrective or mitigating measure is available (for a vulnerability) or within one month of the 72 hour notification (for a severe incident). Penalties are set at national level, and the Commission's summary notes that micro and small enterprises cannot be fined for missing the 24 hour deadline.

NIS2 (Directive (EU) 2022/2555)

NIS2 is the rule that covers hosted SaaS in the EU when the provider sits in a listed sector and meets the size threshold. The Commission's FAQ lists cloud computing service providers and data centre providers under digital infrastructure, and managed service providers and managed security service providers under ICT service management. Article 21(2)(d) requires essential and important entities to address supply chain security, including security aspects of their relationships with direct suppliers and service providers, and Article 21(3) asks them to weigh each direct supplier's vulnerabilities and the quality of its products and secure development practices. Incident reporting starts with an early warning within 24 hours. Member States had until 17 October 2024 to transpose the directive, and national laws still differ, so check the law where you are established.

For cloud and managed service providers, Commission Implementing Regulation (EU) 2024/2690 adds technical requirements, including a supply chain security policy and supplier contract terms.

DORA (Regulation (EU) 2022/2554)

If you sell to EU banks, insurers, investment firms or payment institutions, DORA reaches you as an ICT third party service provider; it has applied since 17 January 2025. Article 30 requires those contracts to be written in one document with service levels, and to cover the services, subcontracting, where data is processed and notice duties, with more terms for critical or important functions. Expect addenda and questionnaires built from it.

US rules that reach SaaS vendors

SEC cybersecurity disclosure. For SaaS companies that are SEC registrants, the rules adopted in July 2023 require a Form 8-K Item 1.05 filing generally within four business days of determining that a cybersecurity incident is material, and annual disclosure under Regulation S-K Item 106 of processes for assessing, identifying and managing material cybersecurity risks. Most registrants had to comply with Item 1.05 from 18 December 2023. An incident that starts at a vendor or in a dependency is still your incident if it is material to you.

Federal sales. OMB M-26-05, "Adopting a Risk-based Approach to Software and Hardware Security" (23 January 2026), rescinded M-22-18 and M-23-16 and with them the government wide self attestation requirement. Agencies may still use the Secure Software Development Attestation Form and may require a current SBOM on request; for a cloud platform, the memo's footnote says that SBOM should cover the runtime production environment. NIST SP 800-218, the Secure Software Development Framework (version 1.1, February 2022), remains a reference the memo names.

SBOM content. On 29 July 2026 CISA, NSA, FBI and international partners released the 2026 Minimum Elements for a Software Bill of Materials, building on the NTIA 2021 elements. It adds Component Hash, License, SBOM Tool Name and SBOM Generation Context, covers open source, AI and SaaS software, and notes that SaaS in cloud environments may need additional elements.

Flow down from regulated customers. Fintech, bank, health and payments customers carry their own third party oversight duties (the FTC Safeguards Rule, financial regulators' rules, HIPAA business associate agreements, PCI DSS), and those end up in your contracts.

CISA Secure by Design Pledge. The pledge is voluntary and explicitly covers SaaS. Signers make a good faith effort over one year toward seven goals, such as more multi factor authentication, fewer default passwords and a published vulnerability disclosure policy. Customers ask whether you signed it.

How the rules line up

What happened in real SaaS supply chain incidents in the last three years?

The incidents below come from official advisories and are described only as far as the source describes them. None of this is a judgement on the organizations involved.

The xz utils backdoor, March 2024

On 29 March 2024 CISA reported that malicious code had been embedded in XZ Utils versions 5.6.0 and 5.6.1, a compression library present in Linux distributions, and that it may allow unauthorized access to affected systems. It was assigned CVE-2024-3094. CISA recommended downgrading to an uncompromised version such as 5.4.6 and hunting for malicious activity. For SaaS teams the question that day was concrete: which base images and build hosts carried those versions.

Customer accounts on a cloud data platform, June 2024

On 3 June 2024 CISA published an alert that Snowflake had indicated a recent increase in cyber threat activity targeting customer accounts on its cloud data platform and had issued instructions for customers to query for unusual activity and prevent unauthorized user access. CISA encouraged users and administrators to hunt for malicious activity and report positive findings. For SaaS vendors with customer data on such a platform, a subprocessor's notice became a same day hunting task.

A compromised CI action, March 2025

CISA reported that the popular third party GitHub Action tj-actions/changed-files had been compromised (CVE-2025-30066), allowing disclosure of secrets including access keys, GitHub personal access tokens, npm tokens and private RSA keys. An update on 19 March 2025 said the compromise was potentially enabled by a compromise of another action, reviewdog/action-setup@v1 (CVE-2025-30154), and on 26 March 2025 CISA added both CVEs to its Known Exploited Vulnerabilities catalog. For SaaS build teams, the layer is the lesson: a third party CI step running with access to deployment credentials.

Stolen OAuth tokens from a connected app, August 2025

On 12 September 2025 the FBI released FLASH-20250912-001 on two criminal groups, UNC6040 and UNC6395, compromising Salesforce instances for data theft and extortion. According to the FLASH, since October 2024 UNC6040 used voice phishing to get support staff to authorize malicious connected apps, often a modified version of Salesforce's Data Loader. In August 2025 UNC6395 exploited compromised OAuth tokens for the Salesloft Drift application, an AI chatbot that integrates with Salesforce, to access victims' instances and exfiltrate data. The FBI states that on 20 August 2025 Salesloft, with Salesforce, revoked all active access and refresh tokens for the Drift application. For B2B SaaS this is the integration layer of the supply chain: your app's tokens in customers' systems, and other vendors' tokens in yours.

The npm worm, September 2025

On 23 September 2025 CISA reported a widespread supply chain compromise of npmjs.com in which a self replicating worm, publicly known as "Shai-Hulud", had compromised over 500 packages. The actor harvested GitHub tokens and cloud API keys and used compromised developers' npm credentials to publish infected versions of other packages. CISA recommended a dependency review including nested dependencies, a search of artifact caches for affected versions, credential rotation and pinning to known safe versions.

What these incidents have in common

• The build and integration layers were the target, not the vendors' own application code.
• The first question was always inventory: which images, workflows, services or connected apps are affected.
• Credentials were the prize, in build environments and in OAuth tokens.
• Customers asked before regulators did, usually within a day.

Who owns software supply chain risk in a SaaS company?

The problem spans engineering, security, compliance and the revenue team. Each owner needs something different, on a different clock.

The CISO or head of security

The CISO owns the board's risk statement and the answer top customers get during an incident. They need one view of exposure, an SLA with evidence it is met, and "affected or not" with proof within hours. Their clock is board meetings, incidents, renewals and, if listed, the annual Item 106 disclosure. Give them trend lines, open exceptions and time to answer.

The VP or director of engineering or platform

Engineering owns the build system, dependency choices and the time spent on security work. They need one set of build rules enforced in CI instead of four review processes, fix pull requests instead of tickets, and fewer questionnaires landing on engineers' desks. Their clock is every sprint, every release and every blocked deal.

The head of AppSec or product security

AppSec turns findings into fixes. They need a backlog that separates vulnerable code the application actually calls from the noise, burn down metrics they can defend, and policies they encode once. Their clock is weekly triage, the monthly metrics review and every critical CVE that trends.

The GRC or compliance lead

The GRC lead owns SOC 2, ISO 27001 and now CRA readiness. They need evidence by control, collected continuously, with a trail of exceptions and approvals; a current subprocessor list; and a place to publish posture that customers can read without a call. Their clock is the audit window, the request list, every questionnaire and every EU contract with a DORA or NIS2 addendum.

Procurement and vendor risk

This often sits inside security or GRC and works both ways: assessing your subprocessors and answering customers' vendor risk teams. They need a tiered vendor list, a record of what each vendor was asked, and SBOMs from vendors whose software you embed. Their clock is onboarding, renewal and the day after a vendor incident.

The startup CTO who also owns compliance

In a company of a few dozen people, all of the above is one person. What is enough at this stage is usually a SOC 2 Type II plan, a written and met vulnerability SLA, an SBOM per release of anything you ship, and a published security page, kept in one place. Their clock is the first enterprise deal that requires SOC 2 and the first EU customer that asks about the CRA.

How do you secure SaaS software in 90 days?

The plan assumes a team of one to five people with part time help from engineering. It works with or without any particular product.

Days 1 to 30: know what you ship and what it depends on

1. List products and shipped artifacts. For each product, list the hosted services, the container images and every artifact a customer installs. Mark which are sold in the EU; those are your CRA scope.
2. Generate SBOMs in the pipeline. Use CycloneDX or SPDX, generated at build time from the lockfiles and images that actually ship, one per service and per shipped artifact, stored by version. Record how each was generated, since the 2026 Minimum Elements ask for the generation context.
3. Inventory the build system. Every pipeline, each third party action it calls and whether it is pinned to a commit hash, and the credentials each can reach.
4. Inventory integrations and tokens. The OAuth apps your product offers (scopes, lifetime, storage) and the third party apps connected to your own systems.
5. Build a tiered subprocessor list. Every vendor touching customer data or production, and when you last assessed it.
6. Write the vulnerability SLA. For example: critical and known exploited in 15 days, high in 30, medium in 90, with the CISA KEV catalog and EPSS deciding what jumps the queue. Choose numbers you can meet; the auditor will test them.
7. Run one "are we affected?" drill. Replay the xz backdoor or the npm worm and time the answer. That is your baseline.

Days 31 to 60: put rules on builds and terms on vendors

1. Turn the SLA into build rules. Decide which conditions block a release (for example a known exploited critical vulnerability or an unapproved license), which warn and which only notify, and enforce them in CI for every repository that ships.
2. Create an exception process. Every exception gets a justification, an owner, an expiry date and an approver, recorded where an auditor can sample it. This one step turns many CC7.1 and CC8.1 questions into evidence.
3. Pin and restrict CI. Pin third party actions to full commit hashes, grant least permissions, prefer short lived federated credentials, and separate publishing pipelines from pull request tests.
4. Rank the backlog. Order findings by reachability, KEV status and EPSS, fix the top first and record why the rest waits.
5. Put supply chain terms in vendor contracts. For critical subprocessors: incident notice timelines, SBOMs on request, vulnerability notification and access to their SOC 2 report. For EU financial customers, check subcontractor terms against DORA Article 30.
6. Cut integration scopes. Request only the OAuth scopes features need, set token lifetimes, document revocation, and remove unused connected apps.
7. Prepare the CRA reporting path. Name who decides a vulnerability is actively exploited, who drafts the 24 hour and 72 hour reports, and how you reach the Single Reporting Platform. Publish a coordinated vulnerability disclosure policy.

Days 61 to 90: publish, rehearse and make it routine

1. Publish what customers keep asking for. A trust page with frameworks at their real status, subprocessors, your disclosure policy and a way to request the SOC 2 report under NDA.
2. Share SBOMs under control. Share with customers under contract, prospects under NDA and auditors, with expiry and revocation. For cloud customers, be ready to describe the runtime production environment.
3. Add exploitability statements. For high profile CVEs in your SBOM that do not affect the product, share a VEX statement.
4. Rehearse an incident end to end. Tabletop a compromised dependency: detection, inventory query, customer notice, CRA notification, SEC materiality if listed, and the fix. Time each step.
5. Map evidence to controls. Tie scan history, gate results, exceptions, vendor reviews and SBOMs to CC6.8, CC7.1, CC8.1, CC9.2 and ISO 27001 Annex A.
6. Set the routine. Weekly triage, monthly metrics (time to answer, SLA compliance, open exceptions), quarterly vendor reviews and an SBOM with every release.

A worked example (illustrative scenario)

This is an illustrative scenario with round, invented numbers. A 200 person SaaS company runs 40 services and ships a CLI, two SDKs and an on premises connector. In week one it generates SBOMs for all of them and finds about 6,000 unique open source components. Its first drill, using the xz backdoor, takes two days because image inventories live in three registries.

By day 60, CI blocks known exploited criticals and unapproved licenses and warns on other criticals. Of 400 open critical and high findings, the 60 that are reachable and on KEV or high EPSS go first; the rest join the SLA queue with recorded reasons. By day 90 the company publishes a trust page, shares SBOMs for shipped artifacts under NDA and repeats the drill in under an hour. Your numbers will differ; the measure that matters is the change in time to answer.

How Safeguard does this

Everything above works without Safeguard. If you want the inventory, build rules, fixes, evidence and customer facing posture in one place, this is how the matching flow runs in Safeguard, using only what Safeguard's documentation and offering describe. Every capability named here is generally available (GA).

The capabilities involved are SBOM generation and analysis (GA) in SPDX and CycloneDX; SCA with deep transitive dependency scanning (GA); vulnerability management with EPSS and CISA KEV enrichment (GA); reachability analysis and prioritization (GA); policies, gates and guardrails (GA); license compliance (GA); autonomous remediation with Griffin fix pull requests (GA), which ships switched off with every category set to Manual; the Portal SBOM Repository and sharing (GA); CSAF and VEX upload (GA); the compliance and GRC suite (GA); the Trust Center (GA); and TPRM, the Third-Party Risk Manager (GA).

1. Connect repositories, images and models. On the Integrations page, connect GitHub, GitLab, Bitbucket or a Git URL, container registries such as Amazon ECR or any OCI registry, and Hugging Face models. The same page takes manifest and CSAF or VEX uploads. Each repository becomes a project with a branch or tag and a version.

2. Or scan from the CLI and keep code on your side. The Safeguard CLI (GA) builds an SBOM for a target and matches it against vulnerability databases. The docs show these forms; we did not run them for this post:

   # The current directory
   safeguard scan --dir .
   # A container image
   safeguard scan --image nginx:latest
   # A Git repository
   safeguard scan --repo https://github.com/org/repo
   # An SBOM you already have (SPDX or CycloneDX)
   safeguard scan --sbom sbom.json
   

   Per the docs, safeguard scan does not fail on findings. The local runner (GA) pulls the repository on your own machine, scans it there and uploads the SBOM and findings, never your source, which helps when customer contracts restrict where code goes.

3. Store SBOMs by product and version. In the Portal SBOM Repository, click Create Product and associate SBOMs with it. Compare on two versions shows added and removed components and new and resolved vulnerabilities, and tags can mark the SBOMs of EU shipped artifacts.

4. Rank what matters. Findings carry EPSS and KEV enrichment, and reachability analysis ranks them by whether your application actually calls the vulnerable code, so the first fixes merged are on real code paths. Measure the effect on your own repositories rather than relying on a quoted figure.

5. Write the SLA as policies and enforce it with gates. Under Settings → Policies, click Create Policy, define conditions with the visual builder or YAML, set severity and actions, then save and enable. Documented conditions include vulnerability severity, CVSS, EPSS, license, component age and maintenance, and templates include No Critical Vulnerabilities, License Compliance and No Abandoned Packages. Each policy's action decides what a failure does to the gate: Block fails it, Warn passes it with a warning naming the policy, and Notify passes it and sends a notification. With policy outcomes on for your workspace, the docs show this CI form (not run for this post):

   safeguard ci scan --wait --fail-on-gate <gate>
   

6. Route exceptions through approval, with a trail. A developer clicks Request Exception, selects the policy and finding, gives a business justification and an expiry date, and submits. Approvers are notified and decide, and the audit trail is recorded. Policy reports show compliance by policy, exception history and violation trends, which is the population an auditor samples for CC7.1 and CC8.1.

7. Fix with pull requests at your pace. Autonomous remediation lets Griffin open tested, policy gated pull requests that move a dependency to a safe version, for one repository or in bulk. It ships switched off with every category on Manual; switch on only what you want.

8. Check licenses before you ship. License compliance classifies licenses from permissive to network copyleft, enforces them through policy and generates attribution for the SDKs and agents you distribute.

9. Share SBOMs with customers under control. From the Portal, share with named recipients at View, Download or Full permission, or create a link with expiry, download limit and password. Per SBOM you can require NDA acceptance; tracking shows who accessed what, and Revoke ends access immediately.

10. Map evidence to SOC 2 and the rest. The compliance and GRC suite covers frameworks (SOC 2, ISO/IEC 27001 and PCI DSS among hundreds in its library), controls, evidence, monitoring, tests, questionnaires, risks and vendors. Each framework page says which requirements a scan decides and which need your evidence.

11. Publish your posture in a Trust Center. On Compliance › Trust Center, publish a page with the frameworks you choose at one status each (Compliant, In progress, Not assessed, or Signed for pledges such as Secure by Design), control areas read live from monitoring, policies and subprocessors, an FAQ, and dated updates that can be incidents or security advisories. Restricted documents such as an audit report are released only to visitors who accept your NDA, confirm their email and are approved, with every step recorded.

12. Hold your own vendors to the same standard. In TPRM, add each subprocessor and vendor with its risk tier, request SBOMs with a deadline and monitor vendor risk over time, so your CC9.2 evidence and DORA subcontractor records come from one place.

What Safeguard does not do

• It does not give you a SOC 2 report or an ISO certificate. Only an independent CPA firm issues a SOC 2 report and only an accredited body certifies ISO/IEC 27001. Safeguard organizes evidence and monitoring; the auditor decides. For transparency, Safeguard's own SOC 2 Type II audit is in progress.
• It does not decide CRA scope or file your reports. Whether a product is in scope, which conformity route applies, whether a vulnerability is actively exploited and what goes into the 24 and 72 hour reports are your decisions and your filings.
• It does not secure OAuth grants or your identity provider. The 2025 connected app incidents were about tokens and social engineering. Scopes, token lifetimes, help desk procedures and revocation are product and identity work outside dependency scanning.
• It does not replace code review or your change process. Gates and exceptions enforce and record rules; whether a change was reviewed and tested by the right people is still your process.
• It does not fix software you do not build. When a vulnerability sits in a subprocessor's hosted service, the fix has to come from that vendor; TPRM helps you track it, not patch it.
• It does not make legal judgements. Whether an incident is material for SEC purposes, or a contract term is met, is for your counsel.

Common mistakes

• Treating SOC 2 as the whole program. A narrow scope can leave out the build system, shipped artifacts and integrations customers now ask about.
• Forgetting the software you ship. The CLI, SDKs and agents are the parts the CRA covers.
• Generating SBOMs in the wrong place. Build them in the pipeline from the artifact that ships, not from a laptop.
• An SLA nobody meets. Writing "critical in 7 days" into policy and missing it is a guaranteed audit exception.
• Unpinned CI actions and exceptions without expiry. A mutable tag runs whatever it points to with your credentials, and an exception with no end date is a permanent hole.
• Overclaiming on the trust page. Showing a framework as compliant before the audit is complete is worse than showing it in progress.

FAQ

Does the EU Cyber Resilience Act apply to SaaS companies?

It applies to products with digital elements and their remote data processing solutions. A hosted service that is not the backend of an installed product is generally outside it and, where the provider is in scope, falls under NIS2. Software customers install, such as CLIs, SDKs, agents, apps and self hosted editions placed on the EU market, is generally inside it.

When did CRA reporting obligations start?

Article 14 has applied since 11 September 2026: an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, a notification within 72 hours, and a final report later. Everything else applies from 11 December 2027.

Does SOC 2 require an SBOM?

No. The Trust Services Criteria do not mention SBOMs. But auditors test vulnerability monitoring under CC7.1, change management under CC8.1 and vendor risk under CC9.2, and a current SBOM with scan history is an efficient way to evidence all three.

What should a SaaS vendor send when a customer asks for an SBOM?

A CycloneDX or SPDX SBOM for the product or artifact in scope, generated from the build, with the version it describes, usually shared under NDA with an expiry date. Check the fields against CISA's 2026 Minimum Elements, and add VEX statements for CVEs that appear but do not affect you.

Do federal agencies still require a secure software attestation?

Not government wide. OMB M-26-05 rescinded M-22-18 and M-23-16 in January 2026, but agencies may still use the attestation form and may require a current SBOM on request; for a cloud platform the memo says that SBOM should cover the runtime production environment.

Is a SaaS company covered by NIS2?

If it is a cloud computing, managed service or managed security service provider above the size threshold and serves the EU, it is likely covered, and Article 21(2)(d) requires supply chain security measures. Check the national law where you are established.

What is a reasonable vulnerability SLA for a SaaS company?

No rule sets one number. A common pattern is 15 days for critical and known exploited vulnerabilities, 30 for high and 90 for medium. What auditors check is that yours is written, enforced and met.

What is the fastest way to answer "are we affected?" after a package compromise?

Query a current inventory: SBOMs per service, image and shipped artifact, stored by version, plus the list of CI actions and their pins. Teams with that inventory answer in hours; without it, the fallback is to rebuild everything.

The steps in this post close the visibility, evidence and enforcement gaps. The gap that remains is time, between a fix existing upstream and running in your build, or before any fix exists at all, and that is what the section below covers.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session: install, open the interactive terminal, ask it to fix a lodash CVE in a repository, and watch it read the finding and advisory, ask before any command that changes something, edit package.json, run the install and tests with approval, and print a summary without pushing anything. The same flow applies to a SaaS service repository or to the SDK you ship to customers.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code and scans from the terminal. For a SaaS team whose customer contracts restrict where source code can go, this keeps the code on your side and sends only results.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which Safeguard tools Claude can use. For a GRC lead working through a questionnaire or a CISO answering "are we affected?", it is a way to ask plain language questions of the data Safeguard holds, within the tools you allow.

Click through it at your own pace, or open it full screen.

To try the flow yourself, download Safeguard or read the Safeguard docs.

Quick check

Related reading

• SBOMs for SaaS products
• SOC 2 Type II for SaaS startups in 2026
• Procurement security questionnaires that work
• CRA Article 14: vulnerability reporting in 72 hours
• Third party risk management for fintech SaaS vendors
• Related in this series: software supply chain security for logistics and freight

Sources

• European Commission: Cyber Resilience Act
• European Commission: Cyber Resilience Act summary
• Regulation (EU) 2024/2847, Cyber Resilience Act (EUR-Lex)
• European Commission: NIS2 Directive FAQs
• European Commission: NIS2 Directive
• EBA Interactive Single Rulebook: DORA Article 30
• AICPA: 2017 Trust Services Criteria with revised points of focus (2022)
• SEC: Cybersecurity risk management, strategy, governance and incident disclosure fact sheet
• OMB M-26-05: Adopting a risk-based approach to software and hardware security
• CISA: Updated Minimum Elements for a Software Bill of Materials (bulletin, 29 July 2026)
• NIST SP 800-218, Secure Software Development Framework 1.1
• CISA Secure by Design Pledge
• CISA: Reported supply chain compromise affecting XZ Utils, CVE-2024-3094
• CISA: Snowflake recommends customers take steps to prevent unauthorized access
• CISA: Supply chain compromise of tj-actions/changed-files and reviewdog/action-setup
• FBI FLASH-20250912-001: UNC6040 and UNC6395 compromising Salesforce instances
• CISA: Widespread supply chain compromise impacting npm ecosystem
• Safeguard docs: Trust Center setup
• Safeguard docs: Trust Center access requests
• Safeguard docs: Portal sharing
• Safeguard docs: Portal SBOM Repository
• Safeguard docs: Generate SBOM
• Safeguard docs: Policies and Gates
• Safeguard docs: CLI usage
• Safeguard docs: Compliance
• Safeguard docs: SOC 2 Type 2 framework

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.