TL;DR
- Install with:
sf plugins install @cclabsnz/sf-audit - Run:
sf audit security --target-org <alias> - Get an HTML report with a health score, a grade, and a prioritised findings list
What You'll Learn
- What security risks sf audit security detects
- How to install and run the plugin against any Salesforce org
- How to read and act on the HTML report
- What the health score and grade mean
The Problem
Salesforce orgs accumulate security debt silently: Guest User overexposure, excessive Profile permissions with ModifyAllData still active from a go-live rush, Connected Apps that haven't been used in years but still have full access, and sharing rule gaps that nobody audited after the original setup. No built-in Salesforce tool surfaces all of these as a single prioritised, actionable report; Setup is a point-in-time view, not a continuous monitor.
Quick Answer
Install the plugin once with sf plugins install @cclabsnz/sf-audit. Then run sf audit security --target-org <alias>. Replace <alias> with your org alias or username. The command runs a full set of read-only checks (88 across ten domains as at August 2026, up from the 22 across six this post originally described) and writes an HTML report to the current directory. The report includes a health score out of 100, a letter grade (A through F), and a findings list sorted by severity. Start with the CRITICAL and HIGH findings. Those carry the most risk. Re-run the audit after each remediation batch to track your score improving. The --fail-on HIGH flag makes the command exit with an error code, which is useful for blocking CI/CD deployments when new high-severity findings are introduced.
Salesforce orgs accumulate risk quietly. A connected app that stopped being used two years ago. A profile that still has ModifyAllData because someone was in a rush during a go-live. Guest user access that made sense at the time.
None of it shows up anywhere unless you go looking. Setup is a point-in-time view, not a monitor. We built sf audit security to make the looking fast.
Getting Started
The audit hooks directly into the Salesforce CLI you already use. No separate auth flow or complex config files required.
1. Install the plugin
sf plugins install @cclabsnz/sf-audit
You will be warned that the plugin is not digitally signed. That is expected and it is not specific to this plugin: Salesforce only accepts signing keys served from its own domain, so no third-party plugin can satisfy the check and every community plugin produces the same prompt. Answer y to continue.
Since that is a poor thing to have to take on trust from a security tool, the guarantees here are ones you can verify. Releases carry signed npm provenance, so you can confirm the published package was built from the exact public commit, and the read-only promise is enforced by a test that fails the build if a single write path appears in the source:
npm audit signatures # reports "verified attestations" for @cclabsnz/sf-audit
For CI, where an interactive prompt would hang the job, allowlist it on the build machine in ~/.config/sf/unsignedPluginAllowList.json (%LOCALAPPDATA%\sf\ on Windows) with ["@cclabsnz/sf-audit"].
2. Run the audit
sf audit security --target-org myOrg
The command runs its full set of read-only checks against your org, providing real-time progress for each one. That was 22 checks when this post was written and is 89 across ten domains as at September 2026, so treat the README as the live figure:
[ 1/22] Health Check
[ 2/22] Users & Admins
...
─────────────────────────────
Audit Summary
─────────────────────────────
CRITICAL 2 findings
HIGH 4 findings
MEDIUM 7 findings
LOW 3 findings
─────────────────────────────
Score: 61/100 Grade: C
─────────────────────────────
Report written: ./sf-audit-00D8t000001abc-1711234567890.html
What it Checks
Instead of digging through Setup, you get a consolidated view. The audit covered six domains when this post was written and now spans ten:
- Org Health & Configuration: Salesforce Health Check scores, password policies, and session settings.
- Identity & Authentication: single sign-on, MFA posture, and login policy.
- Users, Permissions & Privilege: users with "God Mode" permissions (ModifyAllData, AuthorApex), inactive users holding active licences, shadow admins, and separation of duties.
- Data Access & Sharing: OWD settings and exposure of sensitive fields (SSN, credit cards).
- Guest & External-Facing Access: guest user exposure graded by what a guest can actually reach, Experience Cloud sites, classic Sites, and CSP.
- Apex & Code Security: Apex sharing violations, Flows running in system context, and CRUD/FLS guards.
- Integrations, Connected Apps & Deployments: connected app restrictions, remote site settings, and OAuth scope.
- Secrets & Credential Storage: hardcoded credentials in Apex and credential-like names in custom settings.
- Monitoring & Threat Detection: Setup Audit Trail signals, event monitoring posture, and login anomalies.
- AI & Agents: Agentforce and GenAI surface, mapped to the OWASP LLM Top 10.
Professional Features
Pro Tip: Use the
--fail-on HIGHflag in your CI/CD pipeline to automatically block deployments if new security risks are introduced.
| Flag | Purpose |
|---|---|
--format html,json |
Generates both interactive and machine-readable reports. |
--output ./docs |
Writes reports to a specific directory. |
--fail-on HIGH |
Exits with an error if HIGH or CRITICAL findings exist. |
--checks [names] |
Runs only a specific subset of security checks. |
Understanding Your Grade
The scoring model provides an objective measure of your security posture. The health score starts at 100, with deductions based on the severity of findings.
| Grade | Criteria |
|---|---|
| A | Score ≥ 85 AND zero HIGH findings. |
| B | Score ≥ 70 AND max one HIGH finding. |
| C | Score ≥ 55 AND max three HIGH findings. |
| D | Score ≥ 40 AND zero CRITICAL findings. |
| F | Score < 40 OR any CRITICAL finding. |
The grade gives you an honest read on where your org sits. Most production orgs land between B and D on their first run. Start with the CRITICAL and HIGH findings, resolve them, and re-run the audit to track your progress.
Want to know how the plugin is built? The cache dependency system, the layered architecture, and the scoring model: Read part two.
Frequently Asked Questions
Q: What permissions does the running user need?
A: The plugin queries your org using the Salesforce REST API and Tooling API in read-only mode. A System Administrator profile covers every check, but you should not need one: the plugin explicitly does not require View All Data, because it reads configuration and metadata rather than your business records. The repository ships a least-privilege SF Audit (Read-Only) permission set plus a breakdown of what each permission is for and what the tool deliberately does not need. See PERMISSIONS.md. The short version is API Enabled, View Setup and Configuration, View All Users, View Health Check, and View Event Log Files, with Author Apex only if you want the Apex and Visualforce code checks to run.
Q: Does the plugin make any changes to my org?
A: The plugin is entirely read-only. It queries your org using the Metadata API and Tooling API but never writes, updates, or deletes anything.
Q: How often should I run the audit?
A: Run it before each major release to catch new issues introduced during development, after significant configuration changes (new profiles, sharing rules, or connected apps), and on a regular cadence (monthly or quarterly) to track your security posture over time. The --fail-on HIGH flag makes automated scheduled runs practical by alerting on regressions.
Q: Can I run this against a production org?
A: Yes. The plugin is entirely read-only and safe to run against any org including production. There is no risk to production data or configuration.
Key Takeaways
- Zero Config: No setup beyond installing the plugin and pointing it at an org alias. The plugin reuses the existing
sfauthentication and requires no separate config files for a standard run. - Read-Only: The plugin is safe to run against any org including production because it only queries; it never writes, updates, or deletes anything.
- Prioritised Findings: The HTML report organises findings into Critical, High, Medium, and Low severity bands with a health score and grade, so you always know exactly where to focus remediation effort first.
What's Next?
Recommended Reading:
Action Items:
sf plugins install @cclabsnz/sf-audit- Run against a sandbox first to familiarise yourself with the report
- Address any Critical findings before your next release
Responses
Checking your session.
Loading responses.