Dependency and Supply Chain Recon for SaaS Targets

Dependency and supply chain recon for SaaS targets maps the libraries, build systems, integrations, and cloud services a product trusts before an exploit is attempted. Its central conclusion is blunt. A perimeter-only pen test cannot cover this surface. A thorough assessment needs whitebox access to follow those trust relationships from public clues to internal permissions and prove where a compromise could spread.

Why SaaS attack surfaces now extend deep into the dependency graph

An attacker can compromise a shared upstream component instead of breaking into each SaaS customer separately. That changes the economics of an attack. Modern SaaS products depend on dozens or hundreds of outside components, including authentication providers, analytics tools, cloud platforms, open-source libraries, and CI/CD plugins. A single compromised dependency can open paths into many downstream customers because each has already agreed to trust it.

The application perimeter is therefore only part of the target. The code a product imports, the tools that build it, and the services allowed to access its data all extend its attack surface. These relationships grant access for legitimate work, but an attacker can inherit that access. A test confined to public endpoints misses much of what a sophisticated adversary would investigate first.

What dependency and supply chain recon means in practice, and how it differs from a standard external scan

Supply chain recon begins with external surface mapping. It collects domains, subdomains, exposed APIs, authentication mechanisms, and visible integrations, then moves into dependency graph extraction, CI/CD pipeline fingerprinting, OAuth enumeration, and credential discovery. Each layer informs the next part of the assessment. An integration visible from outside becomes a trust relationship to investigate.

The objective is to establish what the target trusts and which relationships could be exploited. Public package manifests, workflow files, and container metadata can reveal parts of that structure without internal access. Software Composition Analysis, or SCA, supplies the defender-side view by scanning codebases for components and dependencies and tracking security and license risks. Supply chain recon connects that inventory to the systems that install, build, deploy, and authorize those components.

Mapping the open-source dependency graph: where recon starts before an attacker touches the target

Public artifacts expose much of a target’s dependency graph. npm package.json files and Python requirements.txt files reveal dependencies, while job postings, public issues, repositories, and Docker layer metadata can expose private package names. Those names become leads for package poisoning. Typosquatting uses close-name impostors on public registries, with malicious postinstall hooks that can steal environment variables and SSH keys. Dependency confusion uses an internal package name on a public registry, which can bring in malicious code without changes to the target’s own repository.

Generative code assistants invent package names, and attackers register those names before developers try to install them. A USENIX Security 2025 study found that a significant share of AI-recommended packages did not exist and that most invented names appeared again in at least one additional run.

The Shai-Hulud npm worm showed how package trust can spread a compromise. Its September and November 2025 campaigns began with phishing that impersonated npm and propagated by injecting code into packages compromised maintainers could publish. It stole npm and GitHub tokens, with AWS, GCP, and other cloud credential theft most broadly documented in the November wave. The package graph was also a propagation route.

CI/CD pipeline fingerprinting: how build infrastructure becomes an attack path

Build pipelines concentrate source access, secrets, and cloud credentials. Public GitHub Actions workflows can show which third-party actions are trusted, which secrets the jobs reference, and which cloud providers they authenticate to. Recon follows those clues into build-time package installs, OIDC federation, container registries, GitOps sync loops, and exposed build artifacts. The assessment checks job permissions, secret scope, image signing and verification, and how tightly cloud trust policies limit access.

The UNC6426 case in 2025 connects these layers directly. A compromised npm package, nx, delivered the QUIETVAULT credential stealer, which stole a developer’s GitHub token. The actor then abused GitHub-to-AWS OIDC trust to create a new administrator role and get full cloud admin access within days. The stolen GitHub token became a route to cloud administration without a cloud password.

The LiteLLM incident on March 24, 2026 exposed another pipeline dependency. TeamPCP used the previously compromised Trivy scanner running inside LiteLLM’s CI/CD pipeline to steal its PyPI publishing token. LiteLLM routes requests across LLM providers, so its publishing access had downstream value. A tool placed inside the build for security became the foothold for compromising a distributed library.

OAuth and connected-app enumeration: mapping delegated trust across the SaaS integration layer

OAuth moves the trust problem into running services. Grants can be over-scoped, stay active after an integration is abandoned, and let stolen refresh tokens create new session tokens that look like legitimate use. Recon therefore examines connected applications, their scopes, dormant grants, and the security of the third parties holding that access. A working integration is not evidence of a safe grant.

The Salesloft-Drift OAuth cascade illustrates the reach of inherited access. From August 8–18, 2025, UNC6395 used stolen OAuth and refresh tokens to query and export Salesforce data from hundreds of organizations. Salesloft’s disclosure described earlier GitHub access as a stepping stone into Drift’s AWS environment, where the attacker obtained integration tokens. The attacker did not need to break each customer’s authentication.

Other incidents expose related third-party footholds without proving identical chains. Vercel’s security bulletin described a Context.ai compromise that enabled takeover of an employee’s individual Vercel Google Workspace account. Klue’s investigation summary said that a previously compromised GitHub personal access token was used on June 11, 2026 to add unauthorized code to its integration service. These entry points differ, but each shows why the assessment must cover integration access along with the target’s login page when it tests the authentication boundary.

SSRF and cloud metadata exploitation: how dependency recon translates into credential access

Server-Side Request Forgery, or SSRF, can turn the trust map into cloud credential access. A service that accepts URLs, such as a document converter, webhook endpoint, or image processor, may be redirected toward the cloud provider’s internal metadata endpoint. That endpoint can return temporary IAM credentials for the workload’s attached role. Recon identifies which workloads and permissions make this path dangerous.

A documented escalation pattern involved a document conversion service on EC2 with an administrator IAM role. SSRF exposed metadata credentials with AdministratorAccess, allowing compromise of the AWS account through a small number of application-layer requests. The same class of flaw can lead to account compromise, cross-account access, or infrastructure takeover, depending on the IAM permissions and pivots that are available. Testing the URL-handling flaw without examining the role leaves its actual impact unresolved.

Hardcoded and leaked secrets in public artifacts: the passive recon layer most tests miss

Some credential exposure requires no application exploit at all. Committed.env files, failed-build logs that print environment variables, Docker layer history, npm tarballs containing configuration files, and decompiled mobile binaries can expose secrets. Passive recon searches these artifacts because access may already be available to anyone who finds the credential. The Shai-Hulud worm used TruffleHog to hunt for more secrets after compromise, showing that attackers use defensive scanning tools too.

In the Vercel/Context.ai case, a customer reported an OpenAI leaked-key notification for a key stored only in Vercel environment variables. That report is single-source. An assessment needs to examine where credentials are stored, who can reach them, and whether they appear in source code.

Container and orchestration layer recon: what the Kubernetes and registry surface reveals

The contents of an image can expose base image CVEs, bundled credentials, and build-time secrets left in layers, while registry permissions control who can change the images that are distributed. With Kubernetes, recon also needs to check RBAC roles, service account token scope, network policies, and admission controller configuration. These controls shape what a compromised workload can reach beyond its own process.

A compromised pod may reach cluster-admin through misconfigured RBAC or an exposed kubelet API. For a multi-tenant SaaS platform, that means a review of orchestration is part of checking tenant isolation and the impact on the whole platform. The LiteLLM compromise reached approximately 430,000 CI/CD pipelines, with container build and distribution infrastructure serving as a propagation mechanism. Registry integrity and image signing therefore belong in recon, rather than being left as deployment details outside the application test.

Why whitebox access is the only way to perform dependency and supply chain recon completely

Private package names may leak, but external recon cannot find every internal dependency. Private workflows hide build permissions and secret handling, while OAuth inventories reveal scopes and last-use information unavailable from public endpoints. IAM assignments, private image layers, and private repositories create further gaps. Whitebox access is what makes those areas inspectable.

A greybox engagement may expose selected parts, but the assessment still needs source code, pipeline configuration, cloud configuration, and integration records to connect the layers. Cycode’s Supply Chain Security feature tracks dependencies, build processes, and deployment pipelines for signs of tampering or malicious activity. Those functions depend on internal visibility.

Gartner’s application security testing product-market definition lists source evaluation, runtime tests, and supply chain inspection as some of the ways that products find risk. Still, it reflects the same distinction between testing application behavior and inspecting what produces and supports it. An external-only test can uncover exposed clues, but it cannot establish complete coverage of the internal trust relationships described here.

How to structure a dependency and supply chain recon engagement: what a thorough assessment covers

Technical founders and technology leaders should require the assessment to make clear how it covers each layer. The engagement should begin with SCA across package manifests, resolve transitive dependencies, and assess known malicious packages, typosquatting, and confusion risk. It should then review pipeline workflows, build secrets, OIDC policies, permissions, and image signing. OAuth enumeration follows, including grant scopes, dormant integrations, refresh token lifetime, and revocation.

The next stages should pair passive searches of public artifacts with internal secrets scanning, then check containers and orchestration. That review includes private repositories, CI logs, image layers, environment configurations, registry controls, Kubernetes RBAC, network policies, service accounts, and admission controls. Active SSRF testing should cover services that accept URLs or fetch remote content, with IAM analysis establishing the potential impact. Every reported finding should go beyond noting an outdated dependency and have a working exploit that proves reachability, exploitability, and a specific consequence.

A vendor conversation can test this scope directly. Does the engagement include whitebox access to CI/CD configuration and cloud IAM? Will it enumerate OAuth grants and test dormant integrations? Does dependency assessment cover confusion and typosquatting, or only known CVEs? Are container registries and image signing included? The report should account for every layer and show the attack paths found.

The work should close with remediation and retesting. A periodic deep assessment then needs continuous pull-request scanning as its operational complement. A dependency added three weeks after an annual test can introduce the same risk that the test would have caught. Retesting addresses the known fixes, while continuous scanning watches for changes between assessments. The trust graph keeps changing after the report is delivered.