Salesloft GitHub Account Compromise Triggered Drift Supply‑Chain Breach, Mandiant Says

Summary of the incident

Salesloft has disclosed that the chain of events behind a data breach tied to its Drift application began with the compromise of a Salesloft GitHub account. Google-owned Mandiant, which investigated the incident, reported that the threat actor tracked as UNC6395 accessed the Salesloft GitHub account from March through June 2025. So far, 22 companies have confirmed they were impacted by the resulting supply‑chain breach.

“The threat actor, tracked as UNC6395, accessed the Salesloft GitHub account from March through June 2025.” — Mandiant (reported)

Background and context: why this matters

Supply‑chain attacks target trusted software providers, libraries, build systems or repositories to reach many downstream customers through a single intrusion. When an attacker gains access to a vendor or a vendor’s developer resources — including source code, CI/CD pipelines, configuration files or deployment keys — they can modify builds, insert malicious code, exfiltrate secrets or widen access to other environments. That amplifies the attacker’s reach: a single compromised repository or integration point can affect dozens or hundreds of customers.

High‑profile supply‑chain incidents in recent years have shown the systemic risk these compromises pose. Attackers who access developer accounts or build infrastructure can exploit automation and trust relationships that organizations rely on to move code quickly into production.

Technical implications and expert analysis for practitioners

Based on the facts Mandiant reported — namely sustained GitHub access by UNC6395 over multiple months — there are several technical implications practitioners should consider, even in the absence of full public disclosure about exact technique or artifacts:

• Persistence and reconnaissance: An attacker on a repository over a multi‑month period has time to explore source trees, read or exfiltrate configuration and secrets, and map CI/CD workflows and deployment targets.
• Build‑time tampering: Access to a repository or its CI configuration can allow modification of build scripts, Dockerfiles, package manifests or published artifacts to introduce malicious code that is distributed to customers.
• Credential exposure and lateral movement: Repositories often contain tokens, deploy keys or references to secrets. Compromised tokens can be reused to access cloud accounts, third‑party services or other repositories unless properly rotated and scoped.
• Supply‑chain downstream impact: When a vendor’s component is integrated into customer systems (for example, a messaging or sales‑automation app used in many organizations), the breach can cascade to customers who rely on that component’s integrity.

These are not hypothetical outcomes — they reflect the attack patterns observed in prior supply‑chain incidents where attacker access to code or build systems enabled widespread impact.

Comparable cases and broader trends

While every incident has unique elements, the Salesloft case fits a broader pattern of supply‑chain and repository compromise incidents that have shaped vendor security posture in recent years:

• SolarWinds (2020): A backdoor inserted into the build process of a widely used network management product led to compromises of many government and private entities and highlighted the risks of trust in software updates.
• Codecov (2021): Attackers exploited credentials in CI scripts to modify uploader tools and exfiltrate credentials, affecting a large number of Codecov customers and emphasizing the danger of secrets and tokens in build artifacts.
• Ongoing trend: Security teams and national authorities have consistently warned that supply‑chain attacks are high‑impact and harder to detect because they exploit legitimate update and deployment mechanisms.

These cases demonstrate recurring root causes: excessive privileges for developer tools, hard‑coded or long‑lived credentials, insufficient verification of build artifacts, and limited telemetry of CI/CD activity.

Potential risks and recommended actions

For vendors, customers and security teams, the Salesloft disclosure underscores operational and strategic priorities. Below are practical, prioritized recommendations security teams can implement quickly and over the mid term.

• Immediately after detection
  • Revoke and rotate compromised tokens, deploy keys and credentials associated with the affected GitHub account. Assume any token accessible from the repo is compromised until proven otherwise.
  • Audit recent commits, CI runs and release artifacts for unauthorized changes; compare signed artifacts to previous baseline builds where available.
  • Notify downstream customers and partners promptly with actionable details on scope and remediation steps.
• Short‑term controls (weeks)
  • Enforce multi‑factor authentication (MFA) and hardware security keys for all developer and service accounts with repository and CI access.
  • Apply least privilege: limit repository and organization permissions to the minimal required roles, and use short‑lived credential mechanisms where supported.
  • Enable secret scanning and remove secrets from source control; where secrets must exist, use vaults or ephemeral credentials injected at runtime.
  • Harden CI/CD: lock down build environments, require signed commits and enforce reproducible builds and artifact signing where feasible.
• Longer‑term programmatic defenses
  • Adopt a software bill of materials (SBOM) and component provenance tracking to make it easier to identify affected customers and impacted components when a vendor incident occurs.
  • Implement continuous dependency and supply‑chain risk monitoring, including SCA (software composition analysis) and tamper detection on pipelines.
  • Incorporate vendor risk assessments and contractual obligations for secure development practices, incident notification timelines and artifact signing into procurement and third‑party management programs.
  • Exercise incident response plans that explicitly address supply‑chain scenarios, including communications with downstream customers and regulators.

Operational and legal considerations for vendors and customers

Beyond technical remediation, a supply‑chain breach raises operational and legal issues. Vendors should prepare to support impacted customers with forensic findings, timelines, and recommended mitigations. Maintaining a clear, timely communications channel — including release of indicators of compromise (IOCs) and guidance — limits customer confusion and aids containment.

Customers should also update their threat models and risk registers to account for vendor compromise, prioritize rotation of any vendor‑provided credentials in their environments, and consider compensating controls such as network segmentation and stricter inbound verification of third‑party component behavior.

Conclusion

The Salesloft incident — a GitHub account compromise and subsequent supply‑chain impact affecting at least 22 companies — is a reminder that developer accounts and build infrastructure are high‑value targets. Attackers who gain sustained access to repositories can exploit trust baked into modern CI/CD and distribution systems to reach downstream customers. Organizations must treat repository access, secrets, and CI/CD pipelines as crown jewels: enforce MFA and least privilege, remove secrets from source control, sign and verify artifacts, and maintain plans for rapid token rotation and customer notification. The collective lesson from Salesloft and earlier cases like SolarWinds and Codecov is that supply‑chain security requires both technical controls and operational readiness across vendors and consumers of software.

Source: thehackernews.com