Security Scanning
Every module is automatically reviewed on upload, before it's stored. This is what lets buyers trust the marketplace — and it's the same bar for everyone.
What happens after upload
When you submit in Studio, CodeSCE unpacks your files into an isolated workspace and runs a multi-scanner pipeline against them. The scanners produce a score and a set of policy flags, which combine into one of three outcomes: published, hold, or rejected.
Nothing is stored until the pipeline finishes. If your module is rejected, the files are discarded and you get a report explaining why.
Preflight
Before scanning modules, the platform runs a preflight check to confirm the scanner tooling is available on the server (headless Chromium and the analysis engines). Scanners are fail-open: if a tool is unavailable, that specific check is skipped rather than blocking uploads — but a healthy deployment has them all ready.
Scanners used
The pipeline runs the following checks. Browser-based scanners share a single headless Chromium session for speed.
Code & dependencies
| Scanner | Checks for |
|---|---|
| Semgrep | Insecure code patterns (static analysis) |
| ESLint | Code-quality and correctness issues |
| Dependency Audit | Known vulnerabilities in your packages |
| Duplication | Large amounts of copy-pasted / duplicated code |
Content & policy
| Scanner | Checks for |
|---|---|
| Environment detector | Backend/server code (the frontend-only gate) |
| Keyword filter | Prohibited or illegal content |
| NSFW image moderation | Adult imagery in the UI |
Dynamic & UI (headless browser)
| Scanner | Checks for |
|---|---|
| Playwright | Runtime behavior — network calls, unknown domains, suspicious patterns |
| Accessibility | Accessibility violations in the UI (axe) |
| Lighthouse | UI layout and responsive quality |
How scoring works
The scanners feed a combined score. The base outcome comes from that score:
| Score | Base outcome |
|---|---|
| ≥ 80 | Published |
| 50 – 79 | Hold (manual review) |
| < 50 | Rejected |
On top of the score, some checks act as hard gates that override it:
- Hard-reject (regardless of score): backend code detected, prohibited keywords, or explicit adult imagery.
- Downgrade to hold (never auto-reject): borderline content, high code duplication, weak accessibility, or poor responsive layout — these send an otherwise-publishable module to manual review instead of blocking it.
Pass / fail behavior
✅ Published — high score, no policy violations. If you chose to publish, the module goes live on the marketplace.
⏸️ Hold — the module is kept as a draft for manual review. This happens for borderline scores or any "needs review" flag (duplication, accessibility, responsive layout, mixed/uncertain environment, borderline content). Once a reviewer approves it, it can go live.
❌ Rejected — the files are not stored and the module is not published. You receive a report with the reason, such as:
- Prohibited content — illegal/banned content was detected.
- Adult content — the UI contains explicit imagery.
- Backend code — the module isn't a frontend module.
- Security review — the module didn't meet the security bar.
Rejected isn't permanent
A rejection is about this upload. Fix the flagged issue — remove backend code, clean up dependencies, replace disallowed content — and submit again.
Next step
Ready to go live? Continue to Publish a Module →.