Static analysis reviews source without executing it. A Salesforce scanner can trace methods, query construction, and some data flows to identify code that merits inspection. Typical findings include dynamic SOQL built from unchecked input, absent or unsuitable sharing declarations, and database operations that do not appear to account for object or field permissions. A finding is a lead, not proof of a vulnerability. A documented control may exist outside the file, or a value may be constrained earlier in the request path. The Apex Code Scanner should therefore provide evidence for review, not encourage blind rule suppression or automatic fixes.
Sharing, CRUD, and FLS answer different questions. A class marked with sharing can respect record visibility while still exposing an object or field the user should not access. CRUD covers create, read, update, and delete permission for an object. Field-level security, or FLS, governs individual fields such as account numbers or health information. Reviewers should trace the full path: may this user reach the record, use the object, and receive each returned field? A practical test matrix includes a restricted business profile, not only an administrator. Checking the permission set and the serialized response often reveals gaps that a class declaration hides.
Imagine an endpoint receiving an account identifier from a browser request. If code concatenates that value into dynamic SOQL, altered input may change the query’s meaning. Binding variables, validating the expected identifier format, and selecting only required fields reduce the exposure. A scanner can flag string concatenation or suspicious query assembly, but a developer must verify whether the input is truly controlled and why the query is dynamic. The response deserves equal attention. Returning a safe query result with unnecessary fields can still disclose information. Reproducing the request with a low-privilege user is a useful follow-up step.
Scanning has more value before deployment than after an incident. A CI/CD job can run when a pull request changes Apex, metadata, permission sets, or connected automation. The result should name the class, method, rule, and code evidence that triggered the finding. Teams also need a documented decision for false positives, accepted risk, and findings that block release. A short review note explaining a compensating control prevents the next engineer from reopening the same question. Adding salesforce security scanning guidance to the workflow can help distinguish an exposed service from a low-impact cleanup item without treating every warning as an emergency.
A report that only counts violations creates work without much direction. A useful report connects the finding to the endpoint, object, field, or integration involved and explains the likely consequence. A missing access check in a partner-facing service deserves more attention than the same pattern in an unused test helper. Prioritization should consider reachable functionality, data sensitivity, external exposure, and how easily an attacker could influence the path. Keep the review record with the pull request, including the evidence examined and the reason for any exception. That small habit preserves context after the original reviewer moves on.
The operating routine should combine scanning with targeted human review. Establish a baseline, remove repeat findings through shared query helpers and secure coding patterns, then rerun the scan after remediation. Compare the new report with the previous one rather than treating a clean result as proof that the application is secure. Inspect asynchronous jobs, APIs, custom objects, and managed package boundaries because data may travel through paths a single class review misses. Tests for restricted users should cover both direct queries and serialized responses. Clear ownership turns findings into release decisions, while human review handles business rules that static analysis cannot infer.
