AppExchange Security Review readiness
Before an ISV submits a managed package to the AppExchange Security Review, the question that matters is simple: are we ready, or will this bounce? A bounced submission costs another review fee and weeks of calendar time, and roughly half of first-time submissions fail. The AppExchange Security Review Readiness (ASRR) audit answers that question ahead of submission by checking the package against the requirement categories a reviewer evaluates and returning a single verdict: READY or GAPS.
This page explains what the ASRR audit checks, the six requirement categories
(SF-ASRR-001 through SF-ASRR-006), and how to read the verdict.
What the audit checks
The ASRR audit is not a second security scan. It is a readiness rollup: it takes the findings the detector pipeline already produced and organizes them into the requirement categories the AppExchange Security Review evaluates, then judges whether the package clears each one. A category clears when no finding gates it; a category fails when at least one gating finding sits in it. The audit reports the verdict per category and an overall verdict for the package.
The point is to turn a flat finding list into the same shape the reviewer thinks in, so an ISV can walk the six categories top to bottom and see, before paying the fee, exactly which categories would bounce.
The six requirement categories
Each category has a stable ID. The ID does not move between releases, so a verdict is comparable run to run.
| ID | Category | What it covers |
|---|---|---|
SF-ASRR-001 | Authorization (CRUD / FLS / sharing) | Explicit object- and field-level access checks before every query and DML; user-mode or security-enforced SOQL; an explicit sharing mode on every Apex class. This is the single largest cause of first-time review failure. |
SF-ASRR-002 | Input validation and output encoding | No injection into dynamic SOQL or dynamic Visualforce; user-rendered content encoded for its sink; no manual-DOM XSS in LWC or Aura. |
SF-ASRR-003 | Secrets and credential handling | No hardcoded API keys, passwords, or Connected App secrets in source or metadata; credentials held in Named Credentials or protected custom settings / metadata. |
SF-ASRR-004 | External communication and integrations | Outbound callouts over HTTPS with a valid certificate chain; Named Credentials for outbound auth; no cleartext endpoints; Connected App scopes justified rather than Full. |
SF-ASRR-005 | Cryptography | No weak or deprecated primitives (MD5, SHA-1, DES, RC4); no ECB-mode block ciphers; no predictable randomness for security tokens. |
SF-ASRR-006 | Logging, error handling, and sensitive-data exposure | No PII or secrets in debug logs or error output; no stack traces or system data leaked to end users; sensitive fields not over-exposed through Apex REST, Visualforce, or LWC returns. |
These six categories line up with the published Security Requirements Checklist a reviewer walks. The authoritative checklist lives on the Salesforce Partner Community (Security Requirements Checklist); the ASRR audit organizes Vulkro findings into the same shape so the pre-submission self-check mirrors the review.
How to read the verdict
The audit returns one verdict per category and one overall verdict.
- READY on a category means no finding gates it. The package clears that requirement as far as the local scan can see.
- GAPS on a category means at least one gating finding sits in it. The audit lists those findings under the category, each with its own ID and fix guidance, so the gap is actionable rather than abstract.
- The overall verdict is READY only when every category is READY. A single GAPS category makes the overall verdict GAPS.
A READY verdict is a strong pre-submission signal, not a guarantee: the local scan covers the code- and metadata-level requirements, but a human reviewer also evaluates documentation completeness, the package's stated data handling, and design rationale that no static scan can judge. Read READY as "the findings the reviewer's automated tools would catch are clear," and pair it with the documentation review the submission requires.
A GAPS verdict is the more useful one before submission: it is the list of things to fix now, while a fix costs an edit rather than a bounced review and another fee. Work each GAPS category down to READY, re-run, and submit when the overall verdict turns READY.
Where this fits in the submission flow
The recommended order before a submission is: run the mandatory Salesforce tooling first and fix everything it flags, then run the Vulkro scan and the ASRR audit to close the residual gaps and confirm a READY verdict, then prepare the submission documentation. The ASRR verdict is the gate you set for yourself: do not pay the review fee until the overall verdict reads READY.