Start by mapping what actually changes in each deployment. Include Apex classes and triggers, Visualforce or Lightning components, flows, object definitions, permission sets, profiles, and connected integrations. This inventory matters because a secure class can still expose sensitive records through an overly broad permission set. Treat metadata as part of the application, not as background administration. Version control provides the record of who changed what, while separate environments let a team test a correction without disrupting live users. Clear ownership also answers a practical question: who must review a risky change before it moves forward?
The next step is static application security testing, often called SAST. It examines source code and configuration without running the application, looking for patterns such as unsafe queries, inadequate access checks, hard-coded secrets, or data flowing into a risky operation. General-purpose analyzers may not understand Salesforce-specific metadata and execution behavior, so their results can be noisy or incomplete. A purpose-built approach can connect findings to the relevant Apex, object, or permission definition. Developers then receive a useful explanation and location instead of a vague warning that requires security specialists to interpret.
Consider an Apex controller that accepts an account identifier from a user interface and builds a query around it. A scanner should help the team recognize both injection risk and the separate question of whether the user is authorized to view the returned records. These are different concepts: input validation limits harmful values, while authorization determines whether an action is allowed. A second example involves a deployment package that grants read access to an object for convenience. The release may pass functional testing, yet the permission change could expose fields to a wider audience than intended. Security review must examine behavior and access together.
Checks belong in the continuous integration and continuous delivery pipeline, the automated path that builds, tests, and promotes changes. A pull request can trigger code analysis, metadata validation, unit tests, and a review of security findings before a merge. Teams should classify results by practical risk and define a documented rule for stopping a release, while allowing low-risk findings to proceed with an owner and due date. This is the shift-left concept: move detection toward the moment of creation, when the developer still has context and remediation costs less effort.
Secrets require special handling because API keys, tokens, and certificates can be copied from source files, logs, or deployment settings. Store them in an approved secret manager or protected pipeline variable, rotate them when exposure is suspected, and prevent them from entering version control. Least privilege provides a second safeguard. Give users, integration accounts, and deployment identities only the permissions their tasks require, then test those boundaries with realistic roles. Teams can use Salesforce DevSecOps guidance to connect these practices with code and metadata delivery.
A useful operating model continues after deployment. Record the finding, affected component, severity rationale, owner, and fix version so recurring issues can be traced rather than rediscovered. Review scanner rules as Salesforce customizations and integrations change, and watch for false positives that train developers to ignore alerts. A release dashboard can show open critical issues, aging exceptions, and coverage across repositories without turning security into a contest of raw counts. For additional context on application protection, teams can consult salesforce security insights while adapting controls to their own architecture, data classification, and change process.
