Security & Assurance · Enterprise Readiness Assessment
What was checked, what was found, how serious each finding is, and what has to happen before the software carries real customers.
The exclusions are the first thing a reader checks, so they are stated rather than omitted.
Assessed. Application architecture and the boundaries between services. Access control and the separation between customer accounts. Data handling, including what is stored, where, and for how long. Dependencies and their known vulnerabilities. Secrets and how they are held. Automated and manual test coverage. Backup and recovery, tested rather than described. The delivery pipeline. Maintainability of the codebase as inherited by a new engineer.
Not assessed, by agreement. The payment provider’s own systems. The client’s corporate IT and email. Physical security. Load and performance testing beyond the recovery timings below. Any component not present in the frozen version named above.
What this report is not. It is a professional opinion about one version of one system on one date. It is not a certification, a warranty, or a statement that the software is free of defects.
One page for the reader who has to make a decision rather than a repair.
The application is fit to carry the customer it is being offered to, once two findings are closed. Both are closable inside four weeks and neither requires re-architecture. Nothing was found that would make this system unusual for its size and age.
The two blocking findings are an access-control gap between customer accounts, and a backup that had never been restored. The first is the failure this assessment exists to catch; the second was a belief rather than a fact until it was tested. Six further findings should be planned rather than rushed, and four are recorded for completeness and can reasonably wait.
| Ranking | Count | What it means for the decision | |
|---|---|---|---|
| Immediate | 2 | Close before the software carries this customer | |
| Planned | 6 | Schedule inside the next two releases; none blocks the decision | |
| Can wait | 4 | Recorded so the next reader is not surprised by them |
The same list every time. What is found changes; the method does not.
Order records are addressed by a sequential identifier. An authenticated customer changing that number in the request receives another customer’s order, including the delivery address and the contact name. No error is returned and nothing in the logs marks the request as unusual.
This is the most common serious flaw in software built quickly, and it is the first thing an enterprise customer’s own testers look for. It requires no tooling and no special skill. Under the PDPA, disclosure of the delivery address and contact name of another customer would be assessable as a data breach.
GET /api/orders/xxxxxx authenticated as customer A -> 200 OK GET /api/orders/xxxxxx authenticated as customer A -> 200 OK returns customer B’s order, address and contact name
Check ownership on every record read, not only on the account endpoints, and test each pair of roles against the other’s data as part of the release pipeline. Approximately three days of work. Re-tested at the re-check below.
Backups run nightly and complete without error. No restore had ever been performed. Restoring into a clean environment during this assessment took 4 hours 40 minutes and required a configuration value that exists only on the running server and is not in the backup.
A backup that has never been restored is a belief rather than a capability. The missing configuration value means the documented recovery procedure would not have completed unaided at the moment it was needed.
Add the configuration to the backup set, record the tested recovery time, and repeat the restore on a schedule so the number stays true. Approximately two days. Re-tested at the re-check.
Findings are closed against evidence, not against an assurance that they were addressed.
Re-checked 24 September 2026, within the ninety-day window. Findings 1 and 2 were re-tested directly rather than confirmed by report. Both are closed.
| Finding | Fix landed | How it was verified | Status | |
|---|---|---|---|---|
| 1 | Cross-customer order access | 9 Sep 2026 | Re-tested across four role pairs; the case is now a test in the release pipeline | Closed |
| 2 | Untested backup | 12 Sep 2026 | Restored into a clean environment unaided in 2 h 05 m | Closed |
| 3 | Live keys in repository history | 18 Sep 2026 | Keys rotated; history rewritten and confirmed | Closed |
| 4 | Retention undefined for support attachments | — | Policy agreed, implementation scheduled for the November release | Accepted, dated |
Agile Labs Pte Ltd assessed the application named above at release xx.xx.x, commit xxxxxxx, frozen on 3 August 2026, against the scope recorded in section 1 of the accompanying report.
Twelve findings were recorded. The two ranked Immediate have been re-tested by us and are closed. One further finding is accepted with a dated implementation plan. In our opinion, the version and scope assessed are fit to be relied upon by an enterprise customer for the use described, subject to that plan.
This statement covers one version of one system on one date. It is not a certification, and it is not a warranty that the software is free of defects. Changes made after the date above are outside it.