Supply Chain Attacks: How to Detect Third-Party Compromise in Your SaaS Stack
Supply chain attacks are now the #1 threat vector for SaaS companies. Learn how to identify compromised dependencies, rogue OAuth apps, and malicious integrations before they cause a breach.

In December 2020, SolarWinds shipped a software update containing malicious code that backdoored 18,000 organizations — including multiple US federal agencies. The attackers didn't break in through the front door. They poisoned the supply chain.
Six years later, supply chain attacks have become the dominant threat vector for SaaS companies. The 2025 CISA Threat Landscape Report identified third-party software and service compromise as the leading initial access technique — surpassing phishing for the first time.
The reason is simple: attacking the supply chain is a force multiplier. Compromise one widely-used package or OAuth integration and you get access to thousands of downstream targets simultaneously.
This post covers the specific attack patterns, the security events that reveal them, and how to build detection into your platform using LiteSOC.
What "Supply Chain" Means for SaaS
For a SaaS company, "supply chain" isn't just npm packages. It's every external component that executes code or handles data on your behalf:
- npm/PyPI/Composer packages — third-party code running in your application
- OAuth integrations — apps with delegated access to your users' accounts
- Webhooks & outgoing requests — calls to external services that could be hijacked
- CI/CD pipelines — build systems with access to secrets and production environments
- SaaS-to-SaaS connections — Zapier, n8n, Slack, Salesforce integrations
Each of these is a potential entry point. And unlike direct attacks, supply chain compromises are invisible to traditional perimeter security because the malicious code arrives pre-authenticated.
The 4 Supply Chain Attack Patterns
1. Dependency Confusion & Typosquatting
An attacker publishes a malicious package to npm with the same name as an internal package, or a name one character off from a popular library (lodahs instead of lodash). When a developer installs it — or when a scoped package lookup falls through to the public registry — the malicious code executes.
What malicious packages do:
- Exfiltrate environment variables (API keys, database URLs) at install time
- Add backdoors that beacon out to attacker-controlled servers at runtime
- Modify build outputs to inject scripts into your production bundle
Detection approach:
Log and alert whenever a new package version enters your production build:
// In your CI/CD pipeline post-install hook
await litesoc.track({
event_name: "admin.configuration_changed",
actor_id: "ci-system",
actor_type: "service",
metadata: {
change_type: "dependency_added",
package_name: pkg.name,
package_version: pkg.version,
registry: pkg.resolved,
is_scoped: pkg.name.startsWith("@"),
},
});
Alert rule: Any package installed from an unexpected registry (e.g., public npm for a scoped @yourcompany/ package) should immediately trigger a Critical alert and halt the build.
2. Rogue OAuth Application Authorization
A user in your organization is tricked into authorizing a malicious OAuth application that requests broad scopes (read:all, write:files, admin) under a legitimate-sounding name like "Google Drive Sync Pro" or "Slack Productivity Tools."
Once authorized, the rogue app has persistent API access that survives password resets and MFA changes — because it holds a valid OAuth token, not credentials.
This is exactly how hundreds of corporate Google Workspace and Microsoft 365 accounts are compromised every month.
Log every OAuth authorization in your platform:
await litesoc.track({
event_name: "auth.oauth_app_authorized",
actor_id: session.userId,
metadata: {
app_name: oauthApp.name,
app_client_id: oauthApp.clientId,
scopes_granted: oauthApp.scopes,
app_publisher: oauthApp.publisherDomain,
is_verified_publisher: oauthApp.isVerified,
},
});
Alert rule: Any OAuth app granted admin or write:* scopes by more than 3 users within 24 hours → flag for review. Unverified publishers requesting sensitive scopes → always alert.
Log revocations too:
await litesoc.track({
event_name: "auth.oauth_app_revoked",
actor_id: session.userId,
metadata: {
app_client_id: revokedApp.clientId,
revocation_reason: "user_initiated" | "admin_force" | "security_review",
},
});
3. CI/CD Pipeline Poisoning
Attackers target your build infrastructure — GitHub Actions workflows, CircleCI configs, Dockerfile base images — to intercept secrets or inject malicious code into production builds.
Common vectors:
- Compromised GitHub Actions — a trusted action (
actions/checkout@v3) gets its SHA hijacked - Malicious pull requests — PRs from forks that modify CI config to exfiltrate
GITHUB_TOKEN - Poisoned base Docker images —
node:18-alpinepulled from Docker Hub contains unexpected layers
Detection: pin your Actions by commit SHA, not tag:
# ❌ Vulnerable — tag can be moved to point to malicious code
- uses: actions/checkout@v3
# ✅ Safe — immutable reference
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
Log every production deployment with artifact provenance:
await litesoc.track({
event_name: "admin.system_setting_changed",
actor_id: deploymentPipeline.actorId,
metadata: {
change_type: "production_deployment",
git_sha: process.env.VERCEL_GIT_COMMIT_SHA,
git_branch: process.env.VERCEL_GIT_COMMIT_REF,
triggered_by: process.env.CI_ACTOR,
build_id: process.env.VERCEL_DEPLOYMENT_ID,
},
});
Any deployment where git_branch is not main or where triggered_by is not a known service account should trigger an out-of-band alert.
4. Compromised SaaS Integration Credentials
Your n8n workflow, Zapier zap, or Make scenario has an API key embedded in it. If that integration platform is compromised — or if an employee's integration account is taken over — the attacker inherits all the permissions of every connected service.
Signals to watch in LiteSOC:
// Log every action taken via an integration token separately
await litesoc.track({
event_name: "data.record_accessed",
actor_id: integrationToken.id,
actor_type: "integration",
metadata: {
integration_name: "n8n",
workflow_id: workflowId,
records_accessed: recordIds.length,
access_type: "automated",
},
});
Alert rule: Integration token accessing record types it has never accessed before → Medium. Integration token volume exceeding its 30-day p99 baseline by 3x → High.
Building a Supply Chain Security Posture
Step 1: Inventory Your Attack Surface
Before you can detect anomalies, you need a baseline. Audit and log all of the following:
| Component | What to Track |
|---|---|
| npm/pip/composer packages | Name, version, registry source, install date |
| OAuth apps | App name, scopes, publisher domain, authorizing users |
| CI/CD actions | SHA pins, allowed triggering actors |
| API keys issued to integrations | Creation date, last used, scopes |
| Outbound webhook URLs | Registered URL, validation status, last delivery |
Use LiteSOC's admin.configuration_changed event for any change to this inventory.
Step 2: Establish Baselines
Supply chain attacks are hard to detect with static rules because the malicious component often behaves normally at first. Behavioral detection requires knowing what normal looks like:
- What endpoints does each integration token typically call?
- What volume of records does each automated actor access per hour?
- Which OAuth apps are authorized by >5 users in your org?
- What is the typical deployment cadence (days between production pushes)?
LiteSOC builds these baselines automatically from your event history and flags statistically significant deviations.
Step 3: Monitor for Exfiltration Patterns
When a supply chain compromise does execute, it almost always attempts data exfiltration. These patterns are detectable:
// Unusual outbound data volume from a service account
await litesoc.track({
event_name: "data.bulk_export",
actor_id: serviceAccount.id,
actor_type: "service",
metadata: {
destination: sanitizedDestination,
record_count: exportedCount,
data_classification: "sensitive",
},
});
// First-time access to a sensitive resource type
await litesoc.track({
event_name: "data.record_accessed",
actor_id: session.actorId,
metadata: {
resource_type: "api_keys", // Service has never accessed this before
is_first_access_for_actor: true,
resource_id: resourceId,
},
});
Responding to a Supply Chain Incident
When LiteSOC fires a supply chain-related alert, the response playbook differs from a standard credential compromise:
1. Immediate containment (within 15 minutes)
- Revoke all tokens associated with the compromised component
- Rotate any secrets that may have been exposed (env vars, API keys, DB credentials)
- Disable the compromised integration or workflow
- Log the revocation action for your SOC 2 auditors
2. Scope assessment (within 1 hour) Use the LiteSOC forensics view to pull every action performed by the compromised actor since it was first authorized:
curl -X GET "https://api.litesoc.io/events?actor_id=<compromised_token>&limit=1000" \
-H "X-API-Key: lsoc_live_yourkey" \
-H "X-Project-ID: your-project-id"
Map the full timeline: when did the behavior change? What data was touched? Who else was affected?
3. Notification (within 4 hours)
If customer data was accessed, your SOC 2 obligations (and most breach notification laws) require customer notification. Every LiteSOC alert resolution generates an immutable audit record with timestamps — exactly what your legal team needs for breach notification letters.
The Uncomfortable Truth About Supply Chain Risk
You cannot eliminate supply chain risk. Every SaaS application has hundreds of transitive dependencies and dozens of third-party integrations. The attack surface is irreducible.
What you can do is shrink your detection window. The difference between a catastrophic breach and a contained incident is almost always time — how quickly did you notice the anomaly?
The organizations that came out of SolarWinds and XZ Utils relatively unscathed were not the ones with the best prevention. They were the ones with the best detection: structured event logs, behavioral baselines, and alert rules that fired within minutes of the first anomaly.
LiteSOC gives you that detection layer in 2 minutes of integration time. The events you log today are the forensic record that saves you tomorrow.
Stay Updated
Get the latest security insights and product updates delivered to your inbox. No spam, unsubscribe anytime.