1. Executive Summary¶
This whitepaper was developed in the context of federal agency Salesforce deployments and the consulting organizations that support them. The governance architecture, pipeline patterns, and implementation recommendations it describes apply equally to private sector organizations running Salesforce at scale; the security gaps, metadata governance risks, and DevSecOps design principles described here are not specific to any regulatory domain.
The Challenge¶
Federal agencies operating Salesforce at scale face a security and governance challenge that their existing frameworks were not designed to address. The responsibility falls directly on CISOs, CIOs, and CTOs: ensuring the integrity of every system their agencies depend on, including not just the platforms themselves but the pipelines that promote changes into them, the credentials that authenticate those pipelines, and the configuration metadata that defines how those platforms behave. Each of these surfaces is a point of exposure, and a penetration of any of these could have catastrophic, and possibly life-threatening, consequences.
This is not a hypothetical concern. In 2025, a federal agency intercepted unreviewed Salesforce packages that had traveled nearly the full length of the deployment pipeline before being caught - a near-miss that exposed a fundamental weakness in change control. The packages were not malicious; they were simply unreviewed. The controls that should have prevented their advance were present on paper and absent in enforcement. What that incident revealed is what this whitepaper addresses: the gap between believing a governance architecture is in place and having one that actually holds.
The threat environment has grown more acute. On March 31, 2026, the widely used Axios JavaScript HTTP client, present in the dependency trees of countless enterprise applications, was compromised in a supply chain attack (detailed in Section 7). A malicious update introduced a remote access trojan affecting Windows, macOS, and Linux systems, distributed silently through a trusted package that millions of developers had configured their tools to install automatically. Axios is one package. The same attack pattern applies to every package in every dependency tree, including those used only during development, packages that run locally on a developer's machine while that developer is authenticated to a Salesforce org. A compromised local tool does not need a path to production. It already has access to the session.
These are not edge cases. They are the current operating environment.
The Symptoms¶
Your Salesforce system is critical to your business, but it's probably not as secure or reliable as you think. Here's why:
Most companies catch only half the risks. They monitor what developers write in code, but they miss the changes made by clicking buttons in the system itself, such as permission adjustments, workflow changes, or security settings. These "point-and-click" changes happen all the time and often bypass your safety controls entirely.
Changes accumulate without tracking. Over time, modifications pile up in production without being recorded or reviewed. When something breaks, no one knows exactly what changed or why. Recovery becomes slow and risky.
Security breaches can slip through. Hackers look for exposed credentials, misconfigured access controls, and outdated components. Without comprehensive oversight, these vulnerabilities go undetected until they become headlines.
Deployments fail under pressure. When teams rush to release new features, insufficient testing and validation cause production outages, data corruption, and compliance violations.
The Root Cause¶
Standard security frameworks treat Salesforce like traditional software, but Salesforce isn't traditional. It's unique: People build business logic through both code and configuration. Most oversight systems only cover the code side, leaving the configuration side exposed.
Partial controls create false confidence. If you catch some problems but not others, you think you're protected when you're not. You find out the truth only when something goes wrong.
The Solution¶
This paper outlines a complete control system that:
1. Catches all changes, not just code
- Every modification (code or configuration) flows through a review and approval process
- Nothing bypasses the safety gates
- Changes are tracked and auditable
2. Prevents problems before production
- Automatic scanning for security vulnerabilities
- Mandatory testing to catch bugs early
- Validation that changes won't break dependent systems
- Verification that credentials aren't exposed
3. Makes controls non-negotiable
- Rules are enforced by the system, not by human discipline
- Standards apply equally to all teams
- Exceptions are rare, deliberate, and fully documented
4. Protects your protection systems
- The security tools themselves are hardened against attack
- Credentials are encrypted and never visible in code
- Access to control systems is restricted to authorized personnel only
5. Supports your business pace
- Automated controls don't slow you down
- You deploy as frequently as your business needs
- However, every deployment, whether daily or quarterly, must pass all safety checks
Business Benefits¶
| What You Get | What It Prevents |
|---|---|
| Reduced security breaches | Data exposure, compliance violations, ransomware |
| Fewer production outages | Revenue loss, customer frustration, brand damage |
| Faster incident recovery | When something does go wrong, you know exactly what changed and can fix it quickly |
| Audit readiness | Compliance investigations show exactly who changed what, when, and why |
| Faster deployments | Developers spend less time testing manually because automated checks catch problems instantly |
| Retained knowledge | Every change is documented and tracked, so you don't lose critical information when people leave |
| Lower technical debt | Problems are caught early rather than accumulating into costly messes |
What This Covers¶
This paper provides a complete, step-by-step blueprint to implement these controls using GitHub (the platform where your code lives) and automated scanning tools. It includes:
- Architecture and design principles
- Setup instructions and configuration templates
- Security best practices
- How to govern changes across multiple teams and systems
- How to measure whether your controls are actually working
- A phased rollout plan so you can implement it without disrupting your business
Key Principle¶
Your controls are only as good as your weakest link. If developers can bypass safety checks, they will, not out of malice, but under deadline pressure. The system must make the safe path the only easy path.
This isn't about slower releases or annoying developers. It's about automation that catches problems instantly and fixes them before they reach production. When done right, it actually makes teams faster because they spend less time debugging production failures.
Bottom Line: For organizations running Salesforce at scale, comprehensive change control isn't optional. It's essential for security, stability, and speed. This paper shows you exactly how to build it.