DevOps: the overlooked attack surface
DevOps is usually celebrated as the engine of modern software delivery — a way to automate, accelerate, and scale. But attackers see it differently. To them, pipelines, credential vaults, and automation scripts aren’t just convenient tools; they’re a high-leverage attack surface that links directly into business-critical SaaS platforms such as Salesforce.
In today’s supply chain attacks, DevOps compromise is often the starting point, with Salesforce the end target. And while many organizations focus on securing Salesforce itself, few look upstream. If your CI/CD stack isn’t hardened, you’ve effectively left the back door wide open.
The modern supply chain attack doesn’t start with Salesforce — it ends there
In 2025, adversaries no longer rely on brute force or noisy exploits. Instead, they compromise trusted systems upstream and patiently let access flow downstream until it reaches the SaaS platforms that matter most.
Once a DevOps tool or automation server is breached, attackers move methodically. They lift tokens, secrets, and API keys — credentials that often point directly into Salesforce. With those in hand, they can move laterally into business-critical environments, where malicious files, scripts, or record injections are quietly delivered. From there, Salesforce executes the attacker’s payload as if it were part of normal operations, sometimes even triggering agentic AI actions or automated workflows.
The result is a compromise that looks indistinguishable from trusted behaviour — precisely because it is.
The attack path is rarely a straight line. Compromise begins upstream in DevOps and cascades until Salesforce is executing on the attacker’s behalf.

Watch how this plays out in practice: In this short video, we walk through how a DevOps compromise can cascade downstream and end with Salesforce executing on an attacker’s behalf.

If DevOps can touch Salesforce, it’s a privileged user
Too often, pipelines and automation tools are treated as internal-only, almost invisible to security teams. In practice, they are anything but.
A pipeline can store and reuse credentials, push data, call APIs, and upload content — all without human oversight. That makes it one of the most powerful “users” in your Salesforce environment, even if it never logs in through the UI.
In a Zero Trust model, no identity or system is exempt from scrutiny. DevOps pipelines should be treated with the same controls and monitoring as your most privileged human administrators. When those identities are left out of access governance, you’re not just underestimating the risk — you’re giving attackers the kind of blind spot they rely on.
Real-world risks we’re seeing
The risks aren’t hypothetical — they’re happening in real environments. One of the most common mistakes we encounter is hard-coding Salesforce credentials into deployment scripts, which are easily harvested if a repo is compromised. It was exactly this kind of exposure that turned the Codecov supply chain breach into such a wide-ranging incident, as attackers quietly siphoned secrets from pipelines over many months.
Even when credentials are managed properly, pipelines can still introduce risk. We’ve seen CI tools automatically upload test files or reports into Salesforce with no malware inspection.
Misconfigured automation has pushed malformed or even malicious records into Experience Cloud environments, where they become visible to external users. And API-driven content delivery creates another blind spot: files are uploaded directly into Salesforce but never scanned.
None of these activities trigger endpoint or email security alerts, because they arrive through trusted automation. Once inside the SaaS layer, they move largely unnoticed — blending into the very processes designed to keep business moving fast. For more on how these trends are shaping the broader threat picture, see our Salesforce attacks in 2025 analysis.
Closing the DevOps–SaaS security gap
Practical steps can dramatically reduce the risk of DevOps pipelines becoming an attacker’s entry point into Salesforce. The same Zero Trust principles that guide SaaS security apply equally here:
- Use scoped tokens — Replace broad, long-lived credentials with time-limited, narrowly scoped tokens for Salesforce integrations.
- Scan everything pipelines deliver — Treat every file, record, or asset pushed into Salesforce as if it came from an external user.
- Remove secrets from code — Store API keys and credentials in secrets managers or vaults, never in plain text.
- Log automation separately — Tag and trace pipeline activity independently from human users to make anomalies easier to spot.
- Limit pipeline permissions — Avoid giving full CRUD rights unless absolutely necessary, and review privileges regularly.
Securing the pipes
Supply chain attacks don’t just target software vendors. They exploit the trust we extend to our own tools. And DevOps pipelines — now responsible for access, automation, and content delivery across the enterprise — are a perfect example.
Attackers don’t need new malware to compromise Salesforce. They simply need the access pipelines already hold. If you aren’t watching how those systems are being used, you’re handing adversaries the cleanest path into one of your most valuable business platforms.
The lesson is simple: you’ve worked hard to secure the cloud itself. Now it’s time to apply the same discipline to the pipes leading into it.
For a deeper look at how these risks are evolving, explore our Salesforce Threat Landscape H1 2025 analysis.
