TL;DR
- Health Check scores your security settings against Salesforce's baseline. It is the right first look, and the wrong last one: a 95 score says nothing about who holds Modify All Data or what your guest user can read.
- Code Analyzer scans source code. It never looks at the org's configuration.
- AuraInspector tests an Experience Cloud site from the outside, the way an attacker would. It sees nothing else.
- Org Check reviews configuration hygiene, and has picked up much of what Optimizer used to do since Optimizer was retired.
- Security Center is Salesforce's paid posture dashboard for one or many orgs.
- sf-audit is an open-source CLI plugin that audits the whole org read-only, grades it, and links findings into attack paths. That is the tool I build, so weigh this post accordingly.
What You'll Learn
- What Salesforce Health Check actually measures, and the questions it cannot answer
- Which tool answers which security question, without overlap you pay for twice
- A sensible combination for a typical org, and for orgs with public Experience Cloud sites
The Problem
Ask a Salesforce admin how they check their org's security and the answer is usually Health Check. It is built into Setup, it gives you a number, and the number goes in the steering-committee slides.
The trouble starts when that number is taken to mean "secure". Health Check compares your security settings, things like password policy, session timeout and login restrictions, against a baseline Salesforce recommends. It is good at that. But the incidents of the last year were not about password policy. They came through OAuth tokens held by vendors, through guest users whose profile allowed API access, and through permissions nobody remembered granting. I wrote up the four campaigns and their entry routes separately. None of those routes shows up as a low Health Check score.
So the useful question is not "which tool is best". It is "which tool answers the question I actually have".
Common Questions This Article Answers:
- Is Salesforce Health Check enough to audit an org's security?
- What is the difference between Health Check, Code Analyzer and Security Center?
- What replaced Salesforce Optimizer for security reviews?
Quick Answer
| Question you are asking | Tool |
|---|---|
| Are my security settings at Salesforce's recommended baseline? | Health Check |
| Does my Apex, LWC or Flow source contain insecure patterns? | Code Analyzer |
| What can an anonymous visitor pull out of my Experience Cloud site? | AuraInspector, against your own site |
| Is my configuration tidy: profiles, permission sets, unused items? | Org Check |
| I need ongoing posture monitoring across several orgs, with a vendor behind it | Security Center |
| What is the whole org's security posture, which findings chain together, and can I gate CI on it? | sf-audit |
| Did a guest user actually take data during an anomaly? | Event Monitoring logs, read with sf audit incident |
Health Check is a reasonable first step for everyone. For most orgs, the second step is whichever row matches the risk that keeps you up at night.
Salesforce Health Check
Health Check compares your org's security settings against Salesforce's recommended baseline and gives you a score from 0 to 100 (Trailhead). You can export the baseline, edit it and import your own as XML, up to five of them, which matters if your policy deliberately differs from Salesforce's defaults.
Two things are less well known. You can move a setting to Informational in a custom baseline, which takes it out of the score: useful, and also an easy way to make a number look better than the org is. And the score is queryable. The Tooling API objects SecurityHealthCheck and SecurityHealthCheckRisks return the score and every risk with your value next to the standard one (Tooling API reference), so you can track it over time instead of screenshotting it.
What it does not tell you. Health Check reads settings. It does not list who holds powerful permissions, what your sharing model exposes, what a guest user on each site can reach, which connected apps hold live tokens, or what your code does. That is not a flaw in the tool. It is the scope.
Salesforce Code Analyzer
Code Analyzer, formerly sfdx-scanner, runs static analysis over your source: Apex, JavaScript, HTML, CSS and metadata including Flows. Version 5 is current and the old v4 scanner is out of support (GitHub). It bundles several engines, including PMD, ESLint, RetireJS, the Graph Engine for Apex data flow, and Flow Scanner (engines). It is free under BSD-3-Clause, runs as sf code-analyzer run, and has an official GitHub Action.
It belongs in your pipeline, and if you publish on AppExchange you need its reports for security review anyway. But it analyses code in a repository, not a running org. It cannot tell you that someone granted View All Data to an integration user last Tuesday.
AuraInspector
Mandiant released AuraInspector on 13 January 2026 under Apache-2.0 (Help Net Security, GitHub). It tests an Experience Cloud site from the outside: which records a guest or a logged-in external user can reach through the Aura endpoint, record counts, whether self-registration is open, and list components that expose objects.
That outside-in view is something no configuration audit can fully replace, because it tests what the site actually returns. It is also why attackers adopted it. In March 2026 a modified version was used to mass-scan Experience Cloud sites (The Hacker News). Run it against your own sites, with authorisation, before someone else does. It covers Experience Cloud and Aura only, nothing else in the org.
Org Check, now that Optimizer is gone
Salesforce Optimizer was retired: orgs created after 4 August 2025 never had it, and access was removed through Winter '26 and Spring '26 (Salesforce help). Optimizer only ever touched security at the edges, such as external access levels and unused permission sets.
Org Check is the tool most admins moved to. It is a free, open-source Salesforce Labs project, available on AppExchange, and it reviews profiles, permission sets, field-level security, login hours, IP restrictions and password policy. It is unofficial and has no Salesforce Support. Treat it as a hygiene review: good at "what is here and is it tidy", lighter on "how would an attacker use this".
Security Center
Security Center is Salesforce's posture dashboard across one or many orgs: configuration, authentication, user permissions and activity (product page). It is an add-on, priced per customer, and in 2026 Salesforce began talking about a Security Center Essentials offering, so check what your current licence already includes before buying. If you run many orgs and want a supported product with history, this is the vendor answer.
Where sf-audit fits
I built sf-audit because the questions I kept being asked fell between these tools. It is an sf CLI plugin, Apache-2.0, and strictly read-only.
sf plugins install @cclabsnz/sf-audit
sf audit security --target-org prodOrg
It runs 93 checks across identity, permissions, sharing, guest and external access, integrations and connected apps, secrets, monitoring, Agentforce, and code patterns. It reads the Health Check score as one of those checks rather than replacing it. Findings are graded A to F, mapped to frameworks including OWASP, SOC 2, ISO 27001 and the Security Benchmark for Salesforce, and correlated into 16 named attack chains: a guest profile with API access, plus an object it can read, plus no monitoring, is one path, not three unrelated warnings.
A few things it does that the others above do not:
- A CI gate.
--fail-on HIGHexits non-zero, so a deployment that grants a guest user something new fails the build. - Drift over time. Each run is archived, and the next one shows what changed.
- Evidence after the fact.
sf audit events pullcaptures the free daily EventLogFile logs before they expire, andsf audit incidentturns a Guest User Anomaly into a cited verdict.
And what it does not do. Its code checks are pattern checks, such as without sharing on REST endpoints or unescaped Visualforce, not Code Analyzer's data-flow analysis. It reads configuration, so it cannot prove what a site returns the way AuraInspector does. It runs when you run it, unlike a monitored product. And it is a CLI, which suits admins who are comfortable in a terminal and annoys those who are not.
If you want a policy engine you configure in YAML rather than an opinionated scanner, I compared sf-audit with Security Audit Engine separately. Check its licence terms before commercial use.
A sensible combination
For a typical internal org with no public sites:
- Health Check, with a custom baseline that matches your actual policy.
- Code Analyzer in the pipeline for anything you build.
- A whole-org audit, sf-audit or a manual review, at least quarterly and after major releases.
If you run public Experience Cloud sites, add two things:
- AuraInspector against each site, with authorisation, after any change to guest access.
- Event Monitoring logs captured daily, so a Guest User Anomaly can be investigated rather than guessed at.
If you run many orgs and want one supported dashboard, Security Center replaces the ad hoc parts of that list, though not Code Analyzer or the outside-in test.
Frequently Asked Questions
Q: Is Salesforce Health Check enough on its own?
A: For settings, it is a good start. For security, no. It does not look at permissions, sharing, guest exposure, connected apps or code, which is where recent incidents came from.
Q: Does a high Health Check score mean my org is secure?
A: It means your settings are close to the baseline you scored against. If that baseline is a custom one, check which settings were moved to Informational, because those no longer count.
Q: What replaced Salesforce Optimizer?
A: Salesforce points admins to Health Check and Setup tools. For configuration review, many moved to Org Check, a free Salesforce Labs project without official support.
Q: Is it safe to run AuraInspector against my own site?
A: It is an open-source testing tool, and running it against a site you own and are authorised to test is the point. Do it in a sandbox or out of hours if you are unsure of the load, and never against sites you do not own.
Q: Can sf-audit change anything in my org?
A: No. It only reads, and a test in its build fails if any code path could write to an org.
Key Takeaways
- Health Check scores settings, not exposure. Use it, and know what it leaves out.
- Pick by question. Source code, outside-in site testing, configuration hygiene and whole-org posture are four different jobs.
- Public sites change the list. If guests can reach your org, test from outside and keep the logs.
- Every tool here has a blind spot. Choose two or three whose blind spots do not overlap.
What's Next?
Recommended Reading:
- The Salesforce Data Theft Campaigns, 2025 to 2026: A Verified Timeline
- Salesforce Guest User Anomaly Fired: Scanner, Tester, or Data Leaving?
- sf-audit vs sf-cli-security-audit: Two Salesforce Security CLIs Compared
Action Items:
- Open Health Check and note whether you are on the Salesforce baseline or a custom one.
- Write down which of the questions in the Quick Answer table nobody in your team can answer today.
- Pick the tool for that question and run it once this month.
Using a tool I have missed, or found one of these wrong about your org? Leave a comment below.
Responses
Checking your session.
Loading responses.