Salesforce code is only part of the attack surface. Apex, Lightning components, flows, permissions, connected apps, custom objects, and configuration metadata can affect what users and integrations are allowed to do. Metadata is the platform description that tells Salesforce how these pieces behave, so a risky setting may not look like a traditional coding flaw. For example, an Apex class might validate input correctly while a permissive sharing rule still reveals customer records. Reviewing both executable code and configuration gives teams a more realistic view of exposure.
Static application security testing, often called SAST, examines source code for patterns associated with vulnerabilities before deployment. It can identify issues such as unsafe queries or missing access checks, but a general-purpose scanner may misunderstand Salesforce syntax and produce noisy results. Noise matters because developers stop trusting tools that report large numbers of irrelevant findings. A Salesforce-aware analysis can interpret platform-specific objects, APIs, and metadata more accurately. It should still be treated as an aid rather than an oracle: developers need clear explanations, reproducible findings, and a way to mark an accepted risk with an owner and review date.
Secrets deserve a separate check. A secret is a credential, token, or private key that grants access to another system. It can appear in Apex, a configuration file, a deployment script, or a connected application setting. Consider a developer who places a test integration token in a repository, assuming the repository is private. A later permission change or copied branch can expand its audience. Scanning for exposed secrets, rotating any that are found, and storing replacements in an approved vault reduces the chance that source control becomes an accidental credential store.
The pipeline should also test authorization, not just whether the build passes. Least privilege means giving a user, integration, or service only the access needed for its job. In Salesforce, that requires attention to profiles, permission sets, sharing rules, object permissions, and field-level access. A support user may need to update a case but not export every customer field. A deployment gate can flag unexpected privilege changes for review, while routine tests confirm that permitted users can complete their work and restricted users cannot bypass the boundary.
Security checks work best when ownership is explicit. A pull request can trigger code and metadata analysis, secret detection, dependency review, and tests for access behavior. Findings should then be routed according to severity and context, rather than blocking every change automatically. A low-risk naming issue may wait for normal cleanup, while a credential exposure or broad permission change deserves immediate attention. Teams should define who triages findings, how exceptions expire, and what evidence is required before a release proceeds. These decisions keep the process practical for both developers and security staff.
No tool removes the need for judgment. Automated analysis can miss a business rule that is dangerous only when several legitimate features interact, such as a flow that updates ownership before an integration exports records. A focused review of high-impact changes remains valuable, especially for identity, payments, customer data, and external connections. Teams comparing approaches can also consult salesforce security insights while shaping their process. The sensible goal is not to inspect everything in the same way, but to detect common flaws early, investigate meaningful exceptions, and make secure releases repeatable.
