The Platform Was Not Breached. The Delegated Key Was.

The SaaS platform can remain intact while a trusted application identity becomes the attack path.

That is the important distinction in the recent BigCommerce and Ribon incident. BigCommerce told BleepingComputer that credentials belonging to the third-party Ribon and Ribon 1.5 applications were compromised. According to the statement, the credentials were used to inject malicious scripts into a small number of merchant storefronts. The reporting also says attackers accessed shopper data between September 13 and September 17, 2026.

BigCommerce said its systems and platform were not breached.

That does not make this a minor incident. It makes it a useful example of a modern containment problem.

An application key is a non-human identity. Once a merchant authorizes that identity, the application can operate through legitimate APIs and platform functions. The requests can be correctly authenticated while the intent behind them is hostile.

This is lateral movement through delegated trust.

The Marketplace App Is Inside The Trust Boundary

Organizations still tend to classify SaaS integrations as procurement objects: approved vendor, approved contract, approved app.

The runtime reality is different. A connected app is an active principal with permissions, credentials, data paths, and the ability to perform operations without a human being present. Its access may persist for months or years. Its credential may be stored and operated by a third party. One vendor compromise can therefore expose many customer environments through already authorized paths.

The Cloud Security Alliance’s July 2026 paper, Defining Non-Human Identity, identifies excessive permissions, static-secret exposure, weak ownership, and limited visibility as core non-human identity risks. It recommends ownership assignment, least privilege, continuous monitoring, and credential lifecycle controls.

Those are necessary controls. They become much stronger when treated as microsegmentation.

Network microsegmentation asks which workload may communicate with which resource, over which protocol, and for what purpose. SaaS identity microsegmentation asks the equivalent questions:

Which application identity may access which tenant?
Which data objects may it read?
Which configuration or content may it change?
Which operations may it combine in the same session?
What volume and sequence of activity are normal?
Who can revoke its access without depending on the application vendor?

The goal is the same: keep one compromised principal from turning into broad reach.

Separate Data Access From Storefront Execution

The most important detail in the incident is not only that customer data was reportedly accessed. BigCommerce also said the stolen application credentials were used to inject malicious scripts into storefronts.

These are different capabilities with different consequences.

Reading customer records affects confidentiality. Changing storefront scripts affects integrity and can create a path into shopper browsers. Combining both capabilities under one long-lived application identity increases the useful blast radius of a single credential.

BigCommerce’s own REST Management API documentation exposes separate resource families for customer operations and storefront scripts. That separation should continue into the authorization model and the operational design.

A safer pattern is:

Give the integration a distinct identity per tenant.
Separate read-only data access from content or script modification.
Require a different credential and explicit approval for write-capable functions.
Deny script creation or modification to applications that do not require it for their core purpose.
Treat any later scope expansion as a new trust decision, not a routine update.

If one business function truly requires both data and code-changing permissions, bind them to separate execution paths and monitor their use independently. Convenience is not a reason to merge high-impact capabilities.

Contain Each Merchant Independently

Multi-tenant integrations create a dangerous multiplier when one credential, backend worker, or control plane can operate across many customer environments.

The containment objective is simple: compromise associated with tenant A must not provide an authorized path into tenants B through Z.

That means avoiding shared, globally powerful secrets wherever the platform supports a more granular model. Each tenant authorization should produce an independently identifiable and independently revocable relationship. Application-side storage should preserve that separation. Runtime workers should receive only the tenant credential required for the current job, not a database containing every customer’s active token.

NIST’s SP 800-207A applies Zero Trust to cloud-native applications by using application and service identities, granular policy, and enforcement independent of service location. The paper’s core idea translates directly to SaaS integrations: identity is not the final authorization decision. It is an input to a narrow, continuously enforced policy.

For a third-party application, enforceable tenant boundaries should include:

a unique installation or service identity per customer environment;
tenant-scoped authorization and secrets;
no cross-tenant administrative API available to ordinary runtime workers;
separate production, support, migration, and analytics identities;
tenant-specific audit records that the customer can retrieve;
revocation that disables one tenant without waiting for a global vendor action.

A vendor compromise may still affect several tenants. It should have to compromise each authorization boundary, rather than inherit all of them from one key.

Make Revocation A Customer Control

The incident was contained after the affected credentials were revoked and the applications were removed, according to BleepingComputer’s reporting.

Revocation is often treated as cleanup. It should be designed as a primary containment control.

Every customer needs to know:

where all installed applications are inventoried;
which scopes and data each application can access;
which owner approved the connection;
when the identity last performed an operation;
how to disable access immediately;
what business process will fail after revocation;
how to preserve logs before removing the integration.

Do not make emergency revocation dependent on opening a support ticket with the same vendor whose environment may be compromised. The SaaS customer, platform operator, or both should be able to terminate the authorization directly.

Plan degraded operating modes as well. A retailer may accept a temporary loss of personalization or merchandising functionality to stop customer-data reads and storefront changes. That decision becomes much easier when the dependency and rollback path have already been documented.

The equivalent in network containment is a quarantine policy. You do not design it during the incident.

Monitor Valid Requests For Hostile Behavior

A stolen application credential may not generate failed logins. It may produce successful API calls from infrastructure that resembles the legitimate vendor.

Detection must therefore examine behavior after authentication.

Useful signals include:

bulk customer-record reads that exceed the integration’s normal volume;
first-time access to a resource family;
script creation or modification by an application that rarely changes storefront code;
data reads followed by content changes in the same tenant;
activity across many tenants in a short period;
a new source network, region, runtime identity, or user agent;
use of a dormant integration;
operations outside the application’s documented business workflow;
scope changes followed immediately by sensitive actions.

Alerting on a compromised credential’s location alone is weak. The vendor may legitimately use cloud infrastructure and change addresses. Baseline the combination of tenant, operation, object, rate, sequence, and application identity.

The platform should also make those events visible to the customer. A SaaS audit log that records only human administrator actions leaves a major blind spot when applications can read data or change executable storefront content.

Restrict The Vendor’s Own Runtime

The platform’s authorization model is only one layer. The application provider must also contain the systems that hold and use delegated credentials.

The worker that renders recommendations does not need interactive access to the token vault. The support portal does not need direct database reach. A CI/CD runner does not need production customer credentials. A reporting job should not be able to change storefront scripts.

Apply workload microsegmentation around the integration backend:

isolate credential storage behind a dedicated broker or secrets service;
issue short-lived credentials to runtime workers where the platform supports them;
allow each workload to call only the required SaaS API endpoints;
separate customer-data processing from content-deployment functions;
deny general outbound Internet access from credential-bearing workers;
isolate support and engineering access through a controlled management path;
stream audit evidence to a system the application workers cannot rewrite;
prevent build systems and test environments from reaching production tokens.

CISA’s microsegmentation guidance frames microsegmentation as a way to reduce attack surface, constrain lateral movement, and improve visibility by isolating smaller groups of resources. The same discipline should surround the backend that operates SaaS application identities.

If the vendor’s control plane is compromised, the attacker should still encounter smaller boundaries around credentials, tenants, functions, and egress.

A Practical Review For Every Connected App

Start with the integrations that can read regulated data, alter executable content, administer identities, approve transactions, or operate across multiple business units.

For each application, answer these questions with evidence:

Identity: Is the application represented by a unique, attributable non-human identity?
Owner: Which internal person owns the business need and the access decision?
Scope: Are permissions limited to the exact objects and operations required?
Separation: Are read, write, administrative, and code-changing capabilities split where practical?
Tenant boundary: Can one credential or worker access multiple customer or business environments?
Lifetime: How long does the credential remain valid, and where is it stored?
Monitoring: Can you see every sensitive operation performed by the application?
Revocation: Can your team disable the integration immediately and independently?
Failure mode: What breaks when access is revoked, and is there a safe degraded mode?
Proof: Have you tested that removed scopes, revoked credentials, and tenant boundaries actually deny access?

Do not accept “the vendor is trusted” as an answer to any of them.

Trust is why the integration works. Containment is what limits the damage when that trust is abused.

Segment The Permission Graph

The Ribon incident is not primarily a story about whether BigCommerce itself was breached. It is a story about what a valid third-party identity could do after its credential was compromised.

That distinction matters across every SaaS platform. OAuth applications, marketplace integrations, service accounts, API keys, automation bots, and AI agents can all become lateral movement paths through the permission graph.

Microsegmentation must follow that graph.

Use a separate identity per tenant. Keep data access apart from code-changing permissions. Make scope expansion visible. Detect hostile behavior inside successful sessions. Give customers independent revocation. Contain the vendor workloads that hold the credentials.

The login can be valid. The API call can be authorized. The platform can be uncompromised.

The blast radius can still be unacceptable.

Sources

This article was generated with the assistance of AI and reviewed by the author.

microsegment.io