Salesforce DevSecOps

Enforcing code and metadata quality with version control governance.

This site is a complete primer on Salesforce DevSecOps: my philosophy, developed through years of building and hardening delivery pipelines for Salesforce orgs, on how to make quality and security properties of the system rather than aspirations of the team.

The core idea

Salesforce is unusual among enterprise platforms: business logic is built through both code and configuration. Most governance frameworks cover only the code side, which means most organisations catch only half their risks. A permission set changed in production, a validation rule deactivated by hand, a connected app added without review: none of these show up in a pipeline that only watches Apex.

The position this primer takes is that every change, code or metadata, flows through the same reviewed, tested, and audited path, and that the controls enforcing this are applied by the system itself: branch rulesets, required checks, and workflows that cannot be skipped. Rules enforced by human discipline degrade under deadline pressure. Rules enforced by the platform do not.

How to read this primer

The primer is organised as a progression. Sections 1 and 2 summarise the problem and the solution for executive and technical readers respectively. Sections 3 through 9 build the argument in depth: why Salesforce needs its own DevSecOps treatment, how to architect GitHub workflows for it, how to run static analysis and tests for Apex and LWC, how to govern metadata with risk classification, how to manage secrets, how to scale governance across many orgs and teams, and how to measure maturity. Section 10 closes with recommendations and a phased roadmap.

The appendices are the reference layer: complete, working configuration you can adapt. That includes full GitHub Actions workflow YAML, a metadata risk classification matrix, GitHub rulesets configuration, a centralised configuration repository structure, a Salesforce Code Analyzer engine reference, and a PMD ruleset for Salesforce.

Start with the executive summary, or jump straight to the workflow YAML if you want to see the implementation first.

Who this is for

The primary audience is Salesforce Architects designing or defending a delivery pipeline. Engineering Managers and CTOs evaluating the security posture of their Salesforce delivery process are the secondary audience, and Sections 1, 9, and 10 are written with them in mind.

About the author

I'm David Schach, a Salesforce Technical Architect. Code quality and pipeline security are the two threads that run through everything I build. More on the about page.