u/berrism

I built an open-source Salesforce security audit tool based on the Salesforce Baseline Standard — SBS — a community security spec created by Pablo Gonzalez and others in the Salesforce community.

Repo:

https://github.com/Berrismi/sbs-audit-engine

Walkthrough:

https://youtu.be/S0XgBN400zA

The reason I built it is simple:

A lot of Salesforce security risk is not dramatic.

It is boring, quiet, and cumulative.

Too many permissions.
Old profiles.
Permission sets nobody has reviewed.
Guest user exposure.
Settings that were configured years ago and never revisited.
Controls that technically exist but are not validated consistently.

I’m trying to make those checks more repeatable.

For admins, I’d love feedback:

1. Which Salesforce security checks are most painful to validate manually?
2. What would make a tool like this approachable for admins who are not developers?
3. Would you want CSV output, a simple HTML report, prioritized findings, or a guided checklist?
4. What are the security areas you think most orgs overlook?

This is open source and early.

Not a replacement for a formal security review, but hopefully useful as a structured first pass.

I built an open-source Salesforce security audit CLI based on the Salesforce Baseline Standard — SBS — a community security spec created by Pablo Gonzalez and others in the Salesforce community.

Repo:

https://github.com/Berrismi/sbs-audit-engine

Walkthrough:

https://youtu.be/S0XgBN400zA

I’m looking for developer/architect feedback on the implementation and roadmap.

The broader goal is to make Salesforce org security posture more inspectable from metadata/API-accessible signals, especially around permissions, authentication/session settings, guest user exposure, and SBS-aligned controls.

A few questions:

1. Are there specific Salesforce security checks you wish were easier to automate?
2. What is the best output format for real-world use — JSON, CSV, HTML, SARIF, GitHub Action output?
3. Any thoughts on the right balance between Metadata API, Tooling API, REST API, and SOQL-based checks?
4. What would make this credible enough for you to run in a real org?

This is not meant to replace a full security assessment.

It is meant to make the first pass less manual and more repeatable.

I built an open-source Salesforce security CLI tool based on the Salesforce Baseline Standard — SBS — a community security spec created by Pablo Gonzalez and others in the Salesforce community.

The idea is simple:

Salesforce security should not live only in someone’s head, a spreadsheet, or a once-a-year review.

Admins, developers, architects, and RevOps teams need a practical way to understand where an org may have risk hiding in plain sight.

Repo here:

https://github.com/Berrismi/sbs-audit-engine

I also recorded a walkthrough video here:

https://youtu.be/S0XgBN400zA

A few areas I’m thinking about:

- Permission and access model risk
- Profile and permission set hygiene
- Session and authentication controls
- Guest user exposure
- Metadata/configuration gaps
- SBS-aligned checks that can be made more repeatable

I’d love feedback from this community:

1. What Salesforce security checks would you want prioritized?
2. What output would actually be useful — JSON, CSV, HTML, summary report, GitHub Action output?
3. What are the security areas you see companies ignore until it becomes painful?
4. Any concerns with how this should inspect orgs safely?

Not pretending this replaces a full security review.

The goal is to make the first layer of visibility easier, faster, and more repeatable.

www.wengrow.app *soon to be Wengrow.ai domain we already bought.

We are looking for feedback on the app we recently built before we start investing in marketing, this channel seems like the type of folks that would be interested in and able to provide good feedback about why we should maybe not invest in marketing in first place.

It came about as an idea we developed while working with a consulting client. What if your website talked back and acted like a professional sales agent providing information and obtaining it as well to increase web traffic to lead conversion. They did not buy the custom build, so we turned it into a SaaS that seems to be different enough and cheaper than competitors in the space.

Website: www.wengrow.app

Developed by: www.HelloMavens.com a consulting company I co-founded with my partner, Kerry. My name is Michael Berris in case you want to verify me on LinkedIn/facebook.

We are looking for feedback on the app we recently built before we start investing in marketing, this channel seems like the type of folks that would be interested in and able to provide good feedback.

It came about as an idea we developed while working with a consulting client. What if your website talked back and acted like a professional sales agent providing information and obtaining it as well to increase web traffic to lead conversion.

Website: www.wengrow.app

Developed by: www.HelloMavens.com a consulting company I co-founded with my partner, Kerry. My name is Michael Berris in case you want to verify me on LinkedIn/facebook.

I hope this does not count as spam/self-promotion - this is intended to drive feedback on the concept/website, not intending to drive signups.