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 22 automated checks across six security domains (org health, identity and access, data security, integration security, code and automation, and platform) 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
2. Run the audit
sf audit security --target-org myOrg
The command runs 22 automated checks against your org, providing real-time progress for each one:
[ 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
The audit covers six critical domains of Salesforce security. Instead of digging through Setup, you get a consolidated view of:
- Org Health: Salesforce Health Check scores, password policies, and session settings.
- Identity & Access: Users with "God Mode" permissions (ModifyAllData, AuthorApex), inactive users with active licenses, and login trends.
- Data Security: OWD settings, Guest User permissions, and exposure of sensitive fields (SSN, Credit Cards).
- Integration Security: Connected App restrictions, Remote Site settings, and hardcoded credentials in Apex.
- Code & Automation: Apex sharing violations, Flows running in System Context, and unit test coverage.
- Platform: API limit consumption, Setup Audit Trail alerts, and credential-like names in Custom Settings.
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 all 22 checks. If you want to use a less-privileged user, they need read access to Users, Profiles, PermissionSets, Apex classes, Flows, ConnectedApplications, and the standard sharing objects.
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
Resources & References
- [@cclabsnz/sf-audit on npm: npmjs.com/package/@cclabsnz/sf-audit]
- [Salesforce Security Health Check (native tool for comparison)]
- [OWASP Salesforce Security guidance: owasp.org]