Cloudflare and Salesloft expose why vendor credentials are the real target

At a glance

What this is: This is Nightfall’s analysis of the Cloudflare and Salesloft breach chain, which shows how a vendor compromise exposed 104 API tokens and created downstream access risk.

Why it matters: It matters because IAM, PAM, NHI, and third-party access teams must treat vendor integrations as credential-bearing assets, not just procurement or compliance relationships.

By the numbers:

• Cloudflare confirmed that attackers accessed 104 API tokens through the Salesloft Drift breach.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Nightfall's analysis of the Cloudflare and Salesloft breach chain

Context

Supply chain security fails when organisations treat third-party risk as a paperwork exercise instead of a live credential-management problem. In this incident, a compromise in one SaaS service propagated into customer environments through API tokens, which is exactly where identity governance and secrets control intersect.

Cloudflare is a strong example of a broader enterprise pattern: integrations multiply faster than most security teams can inventory them, and credentials often move through collaboration tools, support systems, and automation paths that fall outside traditional review cycles. That makes the breach a representative warning for organisations with dense SaaS and NHI estates.

The article is centred on supply chain exposure, but its governance lesson is broader than vendor management alone. When vendor systems hold tokens, passwords, and access keys, every downstream identity control inherits that exposure window.

Key questions

Q: What breaks when a vendor stores or relays my organisation’s credentials?

A: The trust boundary breaks first, because a vendor compromise can turn stored tokens, API keys, or passwords into reusable access paths into your environment. That creates secondary risk in cloud, SaaS, and VPN systems even when your own perimeter is intact. Security teams need inventory, lineage, and revocation paths that work across all connected services.

Q: Why do third-party integrations increase identity risk so quickly?

A: Third-party integrations increase identity risk because they extend trust through credentials, tokens, and delegated access rather than through direct human oversight. Once the supplier has standing access, your programme inherits the supplier’s governance quality. That is why inventory, expiry, and revocation discipline matter as much as vendor due diligence.

Q: How do security teams know if build-time secret exposure is actually contained?

A: Containment is real only when the exposed identities are revoked, not merely detected. Teams should verify that CI tokens, cloud access keys, registry secrets, and any signing or wallet material tied to the affected runner have been rotated and that no remaining pipeline can still use them.

Q: Who is accountable when a supplier breach exposes customer API tokens?

A: Accountability usually sits with both the supplier and the customer because one party manages the compromised system while the other owns downstream access governance. That means contracts alone are not enough. Security, IAM, and risk teams must define who can revoke, who must notify, and how exposure is measured across shared integrations.

Technical breakdown

How a SaaS compromise becomes downstream credential exposure

The attack chain begins when a trusted SaaS platform is compromised and attacker access extends into connected customer environments through delegated integrations. In this case, the important mechanism is not direct exploitation of Cloudflare but the privilege inherited through third-party connectivity and stored tokens. Once an attacker can pivot through the integration layer, exposed secrets become the most valuable object because they can unlock cloud, VPN, or data-platform access without triggering normal login flows. The security failure is therefore architectural: integrations were trusted as transport paths for credentials rather than treated as governed identity surfaces.

Practical implication: Map every third-party integration that can read, store, or relay tokens, and apply explicit lifecycle controls to those credentials.

Why credentials embedded in collaboration tools evade normal control points

Modern secrets rarely live only in code repositories. They appear in Slack messages, Jira tickets, documentation, support threads, and AI prompts, which means control based only on repository scanning misses a large part of the exposure surface. The core issue is context: a string that looks harmless in one location may be a live credential in another. Traditional DLP and pattern matching often fail because they cannot reliably infer whether the token is active, where it is used, or who can replay it. That is why exposed secrets tend to persist long after discovery if revocation is not automated.

Practical implication: Extend secret discovery beyond code and pair detection with immediate revocation workflows for every confirmed token.

Why real-time response matters more than periodic vendor reviews

Quarterly questionnaires and annual certifications do not match the speed at which attackers exploit exposed credentials. Once a token is reachable, the question becomes how quickly defenders can detect misuse, revoke access, and verify whether the token was replicated elsewhere. This is where secrets management, IAM, and NHI governance converge: the control objective is not only to find the secret, but to constrain its blast radius across every system that accepts it. In supply chain incidents, latency is itself a security weakness.

Practical implication: Build continuous monitoring for token exposure and rehearse revocation paths that work across all connected systems.

Threat narrative

Attacker objective: The attacker objective was to collect high-value credentials that could enable broader intrusion into customer cloud and enterprise environments.

1. Entry occurred through the Salesloft Drift compromise, which gave attackers a foothold in a trusted SaaS layer connected to customer environments.
2. Escalation happened when the attackers used that access path to reach customer Salesforce instances and harvest operational credentials such as AWS keys, passwords, Snowflake access credentials, and VPN keys.
3. Impact followed as downstream organisations faced the risk of lateral movement and deeper infrastructure compromise through exposed tokens and reused secrets.

NHI Mgmt Group analysis

Vendor compromise is now a credential problem, not only a procurement problem. The Cloudflare and Salesloft chain shows that third-party risk becomes operational the moment tokens, API keys, or password-bearing workflows cross organisational boundaries. Security teams that still treat vendor review as a compliance artefact are missing the real attack surface. The governance question is not whether the vendor passed review, but whether its integrations can propagate access into your environment. Practitioners should manage vendors as identity-bearing extensions of the enterprise.

Standing credential exposure window: this incident class exists because secrets often remain valid long after the trust relationship that created them has changed. That creates a standing exposure window in which one compromise can be reused across multiple downstream systems. The failure mode is familiar in NHI governance: a secret is created once, copied many times, and never fully retired. Organisations need to treat every externally reachable token as a short-lived privilege object, not as static configuration.

Supply chain security and data security are converging into one control domain. Nightfall’s analysis rightly frames the issue as data movement, but the identity lesson is equally important: if a vendor can store or relay your credentials, then access control has already expanded outside the perimeter. This is where OWASP Non-Human Identity Top 10 guidance and NIST Zero Trust thinking intersect with third-party governance. Practitioners should assume that every integration expands the identity attack surface unless it is explicitly constrained.

Real-time detection is becoming the minimum viable control for secrets exposure. The article shows why quarterly reviews cannot meaningfully reduce risk once adversaries are actively searching for high-value credentials in collaboration tools and SaaS workflows. Security programmes need detection, lineage, and revocation to operate as one control loop. In practice, that means folding secret discovery into incident response, access governance, and supplier offboarding rather than treating them as separate processes.

What this signals

Supply-chain credential abuse is now a governance problem for every identity programme. When third-party platforms can relay API tokens into customer environments, the practical boundary is no longer the supplier contract but the revocation loop. Teams should align supplier oversight with NIST Zero Trust thinking and the OWASP Non-Human Identity Top 10, because trust assumptions do not survive integration sprawl.

Secrets discovery and revocation must operate as a single control. The operational signal to watch is whether your team can find a token, prove where it exists, and disable it everywhere before attackers reuse it. If those steps sit in separate teams or tools, your exposure window is probably wider than you think.

Credential lineage will become a board-level resilience issue. As SaaS ecosystems expand, organisations will need evidence of where secrets live, who can touch them, and how quickly they can be retired after supplier compromise. That is the practical shift this incident reinforces for IAM, PAM, and NHI owners.

For practitioners

• Inventory credential-bearing integrations Identify every third-party platform that can store, relay, or access API tokens, passwords, or access keys, then classify each integration by blast radius and revocation path.
• Expand secret discovery beyond code Scan Slack, Jira, Confluence, support tickets, documentation, and AI prompt workflows for live secrets, because repository-only scanning misses a large share of exposure.
• Automate token revocation on exposure Connect detection to revocation so confirmed tokens are disabled immediately across cloud, SaaS, and VPN systems instead of waiting for manual triage.
• Review third-party offboarding and rotation Reassess supplier offboarding, token rotation, and integration cleanup so a vendor compromise does not leave lingering credentials active in customer systems.
• Test incident paths for supplier compromise Run exercises that start with a breached SaaS supplier and measure how fast your team can locate affected tokens, revoke them, and verify downstream containment.

Key takeaways

• The breach shows that vendor compromise can become downstream credential compromise within minutes, not days.
• The impact is not limited to exposed data. API tokens, passwords, and VPN keys can turn a supplier incident into lateral movement risk.
• The control gap is lifecycle governance. Organisations need continuous discovery, immediate revocation, and supplier offboarding that reaches every integration.

Key terms

• Standing Credential Exposure Window: A standing credential exposure window is the period during which a long-lived secret remains usable after it has been created, exposed, or forgotten. The longer that window stays open, the more likely an attacker can reuse the credential for access, lateral movement, or persistence before the organisation notices.
• Identity Lineage: Identity lineage is the traceable relationship between a human owner and the non-human identities that person creates, authorises, or depends on. It allows security teams to connect service accounts, API keys, tokens, and AI agents back to accountable ownership for review, audit, and retirement decisions.
• Third-Party Access: Third-party access is access granted to vendors, contractors, or support partners who are not direct employees of the organisation. It is higher risk than internal access because accountability, device assurance, and access duration are harder to control, so it usually requires tighter time limits and stronger auditability.

What's in the full article

Nightfall's full report covers the operational detail this post intentionally leaves for the source:

• How Nightfall maps data exfiltration paths across SaaS, collaboration tools, and Shadow AI workflows
• The report's product-level explanation of Data Detection & Response and Data Exfiltration Prevention in vendor environments
• Implementation detail for identifying exposed secrets in unstructured content and automating response
• The report's data lineage angle for tracing which vendors can access sensitive credentials

👉 Nightfall's full post covers the vendor compromise path, exposed token types, and the response controls it recommends.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security and identity practitioners a practical foundation for governing credentials across modern SaaS and cloud estates.