Skip to main content

AppExchange HTML report

The output of vulkro-sf appexchange-report. A single self-contained HTML file that mirrors the published AppExchange Security Review checklist: every Vulkro Salesforce finding is mapped to the checklist section that covers it, every section gets a PASS / FAIL / NOT EVALUATED pill, and the report header pins the checklist version so the result is reproducible.

This is the format an ISV hands to their internal security lead before submitting a managed package for review. It is also the format a consultancy delivers at engagement close: the report is the deliverable, not a vendor dashboard link.

Self-contained by design​

The HTML file inlines all CSS and JS. No script is loaded from a CDN, no font is fetched from Google, no analytics pixel is included. The reviewer can open the file on an air-gapped laptop and every section renders identically.

This matters for the AppExchange audience: ISVs frequently work with internal security teams who review artefacts inside an isolated environment, and a report that breaks without network access is useless in that workflow.

Generating​

# Source-only report.
vulkro-sf appexchange-report . -o appexchange.html

# Source + live-org for full coverage.
vulkro-sf appexchange-report . --target-org my-prod -o appexchange-full.html

# Hand-off to a non-developer reviewer.
vulkro-sf appexchange-report . --target-org my-prod --executive-summary -o exec.html

Layout​

The report renders top-to-bottom in this order:

  1. Cover header: project name, scan timestamp, the pinned checklist version string (e.g. AppExchange Security Review checklist mapping v0.1.0, based on public sections as of 2026-Q2), a link to the canonical published checklist URL, and a single verdict pill (READY when every covered section is PASS, GAPS FOUND otherwise).
  2. Executive summary (only when --executive-summary is set): a one-page narrative summary listing total findings, the section pass rate, the top 3 risk areas by severity, and an action list. Sized to be readable by a non-developer reviewer.
  3. Coverage callout: a callout reminding the reader that the report is a readiness indicator, not a guarantee of acceptance, and listing the review categories Vulkro does not cover (pen test results, certain org-shape configuration that needs a live org to verify, the non-static parts of secure development lifecycle documentation).
  4. Summary strip: pass / fail / not-evaluated counts, total mapped findings, and the count of other Vulkro findings the scan produced that did not map to a checklist section (so nothing the scanner emitted is silently dropped from the report).
  5. One row per checklist section, in checklist order. Each row carries the section title, a one-line description, the list of Vulkro rule IDs that cover the section, a PASS / FAIL / NOT EVALUATED status pill, and a per-finding table (file, line, severity, rule ID, message) when the section is FAIL.

Reading the report​

  • PASS means at least one rule covers the section and the rule produced zero findings.
  • FAIL means at least one covered rule produced findings; the inline table lists every finding with file, line, severity, rule ID, and the actionable message.
  • NOT EVALUATED means no Vulkro rule covers the section yet. These sections still require manual review and are listed explicitly so they cannot be silently passed.

A section with a high count of NOT EVALUATED rows is not an indictment of the scan. It is an honest accounting of where static analysis ends and manual review begins. The methodology page links to the specific manual-review guidance for each NOT EVALUATED section.

Hand-off pattern​

The intended workflow:

  1. The developer runs vulkro-sf appexchange-report locally before any AppExchange submission.
  2. Every FAIL section is addressed in-source until the verdict is READY.
  3. The READY report is attached to the submission package as evidence of a pre-review pass.
  4. For a consultancy engagement, the same report becomes the close-of-engagement deliverable handed to the customer alongside a one-page cover letter.

Because the report is self-contained, the customer or reviewer can archive it indefinitely without worrying about a CDN going away or a dashboard link expiring.