Run the free analyzer. Then find out what it cannot see.

The free analyzer is a bundle of engines run by one command: an open-source Apex rule library, a linter for the Lightning and JavaScript side, and the Salesforce Graph Engine, which walks paths through the code to decide whether an access check is enforced before a record operation. That last part matters and is often misdescribed: the free stack does have path-based analysis. Its constraints are real too. The Graph Engine needs a complete, compilable project and a Java runtime, it costs materially more time than the pattern rules, and it is aimed at the access-check family rather than at every rule class. The pattern rules that cover the rest judge a statement on its own, which is why the classic Apex result is a long list of “add a check here” on lines where a check already exists three frames up the stack.

Vulkro for Salesforce is one engine over the whole project. The same pass reads Apex, Lightning, Aura, Visualforce, Flow and the metadata layer, and follows what a caller sent from the doors the platform opens, the @AuraEnabled, @HttpPost and @InvocableMethod entry points, through as many as five further methods, across instance and static field writes, in and out of collections, and through dynamic dispatch into the candidate implementations in scope. Every rule family sees that path, not only the access-check one, so injection, mass assignment, insecure deserialization and personal data reaching a log are all decided on the resolved route rather than on the shape of one line. It runs on the tree as it is on disk, with no compile step and no JVM.

The bound belongs with the claim. This is a cross-method engine rather than a general cross-file Apex trace, and the named path that crosses a file and a language boundary is the Lightning Web Component to Apex bridge.

The second difference is not about code at all. A permission set edited in Setup last Tuesday, a connected app somebody approved, a session policy relaxed for one integration and a managed package installed two releases ago are not in your repository, so no source analyzer can see them. They are also where a great deal of real Salesforce risk lives. The live-org audit runs through the Salesforce CLI login your team already has, reads definition objects and settings rather than customer records, and reports each check as pass, gap, or not evaluated.

The pattern that works is simple. The free analyzer stays on every pull request as the always-on baseline: it costs nothing, it catches real defects, and its vocabulary is the one your team and your reviewers already share. Vulkro for Salesforce runs where the stakes justify a second opinion: before a submission, before handing an org back to a client, and on a schedule against the running org, which no source analyzer reads.

Both are command-line tools that exit non-zero on findings, so two steps in one job is the whole integration. The Salesforce edition can also be told to fail only on findings that are new against a base ref, which keeps a long-standing backlog from blocking an unrelated change while still catching what the current change introduced.

If the submission is the reason you are here, run the readiness verdict early rather than the week before you queue. It groups everything the scan found into the published requirement categories, marks each one pass, gap or not evaluated, and prints the gate table your pipeline can fail on. The readiness checklist, item by item walks the same ground by hand, and how ISVs run this before a submission is the longer version.