Sample on a fictional demo app, Advanced tier
Production readiness review
A clear view of what can block a demo app from becoming a reliable, controlled production release.
Everything in this report is invented to show the format: the app, its routes, files and findings. No client data or client system is involved, and the report certifies nothing about any real system.
Decision
- 1 Critical
- 2 High
- 1 Medium
Hold the public launch.
Resolve F-01 and F-02 first. Add spend controls before inviting external users.
| ID | Level | Finding | First action |
|---|---|---|---|
| F-01 | Critical | Object access control gap | Block cross-workspace reads |
| F-02 | High | Secret in client bundle | Rotate and move server-side |
| F-03 | High | Unbounded LLM spend | Add quota and rate limit |
| F-04 | Medium | No release gate or rollback note | Gate deploy on checks |
A real review confirms scope, access, environments and evidence before any finding is reported. It does not include penetration testing.
Findings
Each fictional finding connects a business risk to static evidence and a recommended fix.
Object access control gap
- Impact
- A signed-in user could read records from another demo workspace.
- Evidence
- The fictional route fetched a record by ID before checking ownership against the active workspace.
records.get(id) // no workspace check - Fix
- Authorize every object against the active workspace. Add cross-tenant tests before release.
Provider secret included in the browser bundle
- Impact
- Anyone loading the app could copy the demo credential and call the provider.
- Evidence
- A placeholder token pattern appeared in the fictional production JavaScript bundle.
assets/index.js: PROVIDER_KEY="demo_sk_..." - Fix
- Rotate the credential. Keep provider calls server-side. Add secret scanning to CI.
LLM usage has no server-side spend control
- Impact
- A loop or abusive user could create an unexpected model bill.
- Evidence
- The fictional server route called the model without a per-user quota, rate limiter, or cost ceiling.
await model.complete(prompt) // no quota, no limit - Fix
- Add per-user quotas, a server-side limiter, cost logging, and an alert threshold.
Deployment has no quality gate or rollback note
- Impact
- A bad change could reach users without a tested recovery path.
- Evidence
- The fictional deploy workflow had no test step, and the demo repository had no rollback runbook.
deploy.yml: build, then deploy (no test step) - Fix
- Require tests before deploy. Record the last known good release and rehearse rollback on staging.
From hold to controlled release
A practical sequence for the fictional demo app. Timing is illustrative and is not a quote.
First 72 hours: contain the urgent risks
- Block unsafe accessAdd workspace authorization and deny cross-tenant reads.
- Rotate and isolate the secretInvalidate the demo credential and move provider calls server-side.
- Cap model spendAdd a hard quota, rate limit, and an alert before public access.
Remediation plan
- Days 1-3Access modelCentralize authorization and add negative tests.
- Days 4-6Cost controlsLog tokens and cost per request. Set budgets and alerts.
- Days 7-9Release safetyGate deploys on tests. Add staging and rollback steps.
- Days 10-14VerificationRun acceptance checks and attach evidence to every gate.
What the report includes
- Prioritized finding register
- Evidence for each finding
- Impact and effort labels
- Recommended next actions
- Sequenced remediation backlog
- Suggested acceptance checks
- Scope and limitations
- Recorded walkthrough
Verify before launch
- Cross-workspace tests deny access
- No provider secret ships to the browser
- Quota and cost alerts trigger as expected
- Rollback succeeds on staging