TL;DR
- Both tools are read-only
sfCLI plugins that audit Salesforce security from your terminal, with no external service and no credential sharing. @cclabsnz/sf-audit(the one I maintain) is opinionated and broad: 66 fixed checks, an A to F grade, attack-chain correlation, seven-framework compliance mapping, and a branded report you can hand a client. You run one command and get an answer.@j-schreiber/sf-cli-security-audit(the Security Audit Engine) is configurable and focused: you author policies in YAML and it audits permissions, profiles, and users at scale against the rules you define.- Neither is "better." They sit at opposite ends of an opinionated-versus-configurable axis. Choose by whether you want an instant posture read or a versioned, bespoke permission policy.
What You'll Learn
- The real design difference between the two plugins, grounded in what they actually ship today.
- Which tool fits a one-off org review, an audit firm's client work, or an in-house team with strict permission rules.
- How to install and run each, with the actual commands and flags.
- Why you might reasonably run both.
The Problem
Salesforce core clouds give you a Health Check page and a pile of setup screens, but no built-in way to audit security posture across an org from the command line, and no native way to audit the permissions of every user at scale. So the community filled the gap. Two open-source sf plugins now do this from your terminal, and on the surface they look like direct competitors. They are not, quite.
Common questions this article answers:
- What is the difference between sf-audit and sf-cli-security-audit?
- Which Salesforce security CLI plugin should I use?
- Can I run both, and would that make sense?
- Which one works better inside a CI pipeline?
Full disclosure up front: I build and maintain @cclabsnz/sf-audit. I have tried to keep this honest, and I will point out where the other tool is the better choice. The other plugin is built by Jannis Schreiber, a well-known name in the Salesforce community, and it is a genuinely good piece of work aimed at a different problem.
Quick Answer
Use @cclabsnz/sf-audit when you want to point a command at an org and immediately learn what is wrong across the whole security surface, with a grade, prioritised findings, compliance mapping, and a report you can share. It is opinionated: it ships with a fixed definition of what "risky" means, so there is nothing to configure before your first run.
Use @j-schreiber/sf-cli-security-audit when your real need is permission and access auditing, and you want to encode your own rules as configuration that lives in git. It is unopinionated: you decide what counts as a violation, write that down in YAML, and run it repeatably.
| @cclabsnz/sf-audit | @j-schreiber/sf-cli-security-audit | |
|---|---|---|
| Philosophy | Opinionated, batteries included | Configurable policy engine |
| First run | One command, zero config | Initialise, then author policies |
| Scope | Broad: 66 checks across nine domains | Focused: permissions, profiles, users at scale |
| Defines "risk" | The plugin does | You do, in YAML |
| Standout features | A to F grade, attack chains, compliance matrix, client report | Config as code, fully customisable rules, audit at scale |
| Output | html, md, json, branded executive report | Report of executed policies and audited entities, json |
| CI fit | --fail-on HIGH severity gate |
json output, config in version control |
| Version today | 1.2.0, Apache-2.0 | 0.23.0, beta, license in repo |
| Commands | sf audit security / history / diff / list |
sf org audit init / sf org audit run |
Both are read-only. Both run locally against an org you are already authenticated to. Neither writes anything back.
The Real Difference: Opinion vs Configuration
Most tool comparisons come down to feature checklists. This one does not, because the two plugins answer different questions.
sf-audit is opinionated. It carries a built-in model of what good Salesforce security looks like, encoded as 66 checks spanning org configuration, identity and authentication, users and privilege, data exposure, Apex and code, integrations, and monitoring. You do not tell it what to look for. You run it, and it tells you. The trade is obvious: you get instant value and a strong default, but you are accepting my definition of risk rather than writing your own.
sf-cli-security-audit is configurable. Its model is two parts: policies (what to audit) and classifications (how to audit). You initialise an audit against an org, which exports the permissions, permission sets, profiles, and users, then you tune YAML files that describe the rules you care about and run them. The trade is the mirror image: there is setup work before you get an answer, but the answer is exactly the rule set your organisation decided on, checked into version control like any other code.
That is the whole comparison in one sentence. One tool hands you an opinion. The other hands you a framework for expressing yours.
Where Each One Wins
sf-cli-security-audit is the better choice when
- Permission auditing is the actual job. Its core is access analysis at scale: who has which permissions, which profiles and permission sets grant them, across every user. If your question is "prove that no one outside this set has Modify All Data," a policy you write and version is a cleaner fit than a generic check.
- You want config as code. Policies and classifications are human-readable YAML meant to live in git for transparency and reproducibility. Your audit rules get reviewed in pull requests like everything else.
- Your rules are bespoke. If your org has unusual, specific access requirements, an engine you tune beats a fixed checklist that cannot know your intent.
- You want a minimal conceptual surface. Two commands,
initandrun, and a config folder. That is the whole tool.
sf-audit is the better choice when
- You want an answer with zero setup. One command produces an A to F grade and a prioritised findings list. Nothing to configure first.
- You need breadth, not just permissions. The 66 checks reach into MFA method strength, trusted IP ranges that bypass MFA, certificate expiry, Apex CRUD and FLS enforcement, hardcoded credentials, guest user access, and more. Permission analysis is one domain of nine, not the whole tool.
- You want findings correlated, not just listed. Attack-chain correlation links individual findings into named, multi-step scenarios, so a reader sees how three medium issues combine into one real path in.
- Compliance and client reporting matter. Every finding maps to controls across seven frameworks (OWASP, SOC 2, ISO/IEC 27001:2022, the Security Benchmark for Salesforce, NZ Privacy Act, HISO 10029, NZISM). The
executiveformat produces a branded, print-to-PDF report with a remediation roadmap and a compliance coverage matrix, which is the difference between a tool for engineers and a deliverable for a client. - Posture drift over time matters. History and diff archive each run and show what changed between audits.
Running Each One
sf-cli-security-audit
sf plugins install @j-schreiber/sf-cli-security-audit
# Initialise an audit against your org: exports permissions,
# permission sets, profiles, and users, and seeds classifications
sf org audit init --target-org myOrg --output-dir ./audit
# Tune the YAML policies and classifications under ./audit, then run them
sf org audit run --target-org myOrg
The run produces a report listing every policy that executed and every entity it audited. Add --json for machine-readable output to feed a pipeline. Everything stays on your machine, and the config folder is yours to commit. Note that the plugin is at 0.23.0 and described as beta, so command signatures may still change.
sf-audit
sf plugins install @cclabsnz/sf-audit
# Run all 66 checks, write an HTML report to the current directory
sf audit security --target-org myOrg
# Fail a CI build on HIGH or CRITICAL findings
sf audit security --target-org myOrg --fail-on HIGH
# Branded executive report for a client engagement
sf audit security --target-org myOrg --format executive --prepared-for "Acme Health"
# NZ health or government engagement: NZ compliance matrix
sf audit security --target-org myOrg --format executive --frameworks nz
There is no init step and no config to write before the first run. You can still scope it (--checks), retune scoring (--scoring-config), and gate CI (--fail-on), but the defaults are useful out of the box.
CI Pipelines
Both are CI friendly, in different ways.
sf-audit gives you a direct gate: --fail-on HIGH exits non-zero when any finding lands at or above that severity, so a pull request that regresses posture fails the build with no extra wiring. You point it at a scratch org or sandbox and read the exit code.
sf-cli-security-audit gives you config-as-code repeatability: the policies live in the repo, so the audit rules are versioned and reviewed alongside the metadata they protect. You emit json and assert on it. It is less of a one-line gate and more of a policy-enforcement pattern, which suits teams that want their security rules under change control.
Frequently Asked Questions
Can I run both?
Yes, and for some teams that is the right answer. They overlap but do not duplicate. Run sf-audit for a broad posture read, a grade, and a client-ready report, and run sf-cli-security-audit to enforce your specific, hand-written permission policies in CI. One gives you the wide sweep, the other gives you precise control over the access rules you care most about.
Which should an audit or consulting firm use?
For client deliverables, sf-audit is built for that case: the executive format produces a branded report with prioritised findings, attack scenarios, a remediation roadmap, and a compliance matrix you can hand over. If a particular client has unusual permission requirements you need to encode and re-run engagement after engagement, layering sf-cli-security-audit on top makes sense.
Which fits an in-house team with strict permission rules?
sf-cli-security-audit, if those rules are specific and you want them versioned. Writing your access policy as YAML in git, reviewed in pull requests, is a stronger control than hoping a generic check happens to match your intent. Use sf-audit alongside it to catch the wider surface your bespoke policies were never meant to cover.
Is sf-audit biased here because you built it?
A fair question. I have tried to answer it by being concrete about where the other tool wins: permission auditing depth, config as code, customisability, and a smaller conceptual surface are all real advantages of sf-cli-security-audit, and I would recommend it without hesitation for those cases. The honest summary is that sf-audit trades flexibility for breadth and instant value, and sf-cli-security-audit trades instant value for flexibility. That is a genuine design fork, not one tool being behind the other.
Are these safe to run against production?
Both are strictly read-only. They use SOQL, the Tooling API, and REST GET requests, and neither writes anything back to the org. As always, run against a sandbox first if you want to confirm behaviour and review the access each one needs.
Key Takeaways
- The two plugins answer different questions:
sf-auditasks "what is wrong across my whole org right now," andsf-cli-security-auditasks "do my specific, written-down permission rules hold." sf-auditis opinionated and broad: zero config, 66 checks, grade, attack chains, compliance mapping, client reports.sf-cli-security-auditis configurable and focused: policies and classifications in YAML, versioned in git, strong on permission auditing at scale.- Both are read-only, local, and CI friendly. Running both is a reasonable strategy, not redundancy.
- Pick by need, not by feature count. Breadth and instant value, or precision and customisation.
What's Next?
If you want the deeper story on how sf-audit is built and what it checks, start with How We Built a Native sf Plugin for Salesforce Security, then sf-audit: 61 Checks, Attack Chains, and Compliance Mapping for the check catalogue and compliance model. For a hands-on first run, see Catch Salesforce Security Gaps in One Command.
If your immediate concern is MFA specifically, the Salesforce Security Enforcement 2026 guide covers the wider context both tools operate in.