What a production readiness audit examines before you launch
Readiness is not a feeling, and it is not a number you award yourself. It is a set of specific questions with specific answers. Does the deployment actually refuse an unauthorised request. Has anyone ever restored the backup. Can you undo the release you are about to ship. An audit answers them in a form somebody else can check.
How readiness gets established
Three layers producing different strengths of evidence. Several readiness questions can only be answered by running the system, and the report never pretends a run answered one it could not reach.
Public URL scan
E4Tests the deployed application from outside, the way any visitor reaches it: transport security, security response headers, and what the running service discloses about itself. It needs nothing but the address, and what it observes it observes against the running system. Its limit is reach rather than strength: a URL can never establish authorisation, data-layer or backup posture, and those controls stay uncovered.
Repository validation
E2Reads the source: where secrets live, whether authorisation is enforced on the server or only in the interface, whether data access is injection safe, and which dependencies carry known critical vulnerabilities. Findings cite the file they came from, so a result is checkable rather than asserted.
Runtime validation
E4Builds and runs the application in an isolated environment and probes the running system. This is the layer that answers questions reading code cannot: whether the deployed configuration actually refuses an unauthorised request, and whether error responses leak internals under real conditions.
The thirteen controls, and how each result is reached
This is the whole set. Some are measured against the running system, some are read from the source, and two are judged from what you tell us. The report says which, every time, because a control confirmed by attestation and a control confirmed by probe are not the same evidence.
What it costs to skip
None of these are hypothetical. They are the failures that are cheap to find the week before launch and expensive to find the week after.
The first real customer is the test
Development traffic is one person who owns everything they touch, so a cross-account bug cannot show itself. It becomes visible the moment there are two accounts and one of them belongs to somebody who did not agree to be an experiment.
A backup nobody has restored
An untested backup is a belief about a file, not a recovery plan. The difference between the two only ever becomes clear on the single day it can no longer be fixed.
No way back from a bad release
Shipping is the part everyone has practised. Reversing a release that is actively corrupting data, quickly, while customers are watching, is the part nobody rehearses until they have to do it live.
A dependency with a public advisory
Known vulnerabilities are public by definition, which means they are equally public to whoever is scanning your stack. It is the least defensible thing to ship, because the fix usually already exists.
Performance that only fails once you succeed
A query with no supporting index is instant across a thousand rows and a serious problem across a million. The reason to find it before launch is that the table is still small enough to fix cheaply.
Answering your first security questionnaire from memory
The first enterprise buyer asks for evidence, not for reassurance. Assembling it retrospectively, against a deal deadline, costs far more than having had it, and every answer is one you are personally standing behind.
What the result looks like
An illustrative extract, not a real customer result. Every row carries the evidence grade behind it, and a control nobody could establish says so.
| Control | Status | Evidence | Note |
|---|---|---|---|
| Transport security (TLS) is enforced | Verified | E4 | Redirects confirmed against the running deployment |
| Object ownership is enforced server-side | Verified | E4 | Cross-account request refused by the running system |
| Dependencies are free of known-critical vulnerabilities | Failed | E3 | One critical advisory with a fix already published |
| Database queries are index-backed at scale | Partial | E2 | Two growth tables with primary-key-only indexes on hot paths |
| Verified backups and restore procedure | Uncovered | Not graded | No attestation, and no evidence from the layers that ran |
Mapped to published standards
Each control is tested against a named clause, so a result means something outside our own vocabulary. Mapping is not certification, and none of these bodies endorse StackAttest.
What this audit is not
- It is not a penetration test. A deterministic check and a runtime probe are not an adversarial human engagement, and there are classes of weakness only a person hunting for them will find.
- It is not SOC 2 and does not replace it. SOC 2 attests to organisational controls over time; this validates technical controls in the software. They answer different questions for different buyers.
- It does not replace human due diligence. It gives a reviewer repeatable evidence to start from, which is a different thing from being the reviewer.
- Controls the run could not reach are reported as uncovered rather than passed. A result you did not earn is worse than no result.
- It is not a load test or a performance benchmark. It reports schema-level signals, such as a growth table with no supporting index. That is a different claim from measuring how the system behaves under real traffic.
- It is not a business readiness review. Pricing, support cover, contracts and compliance paperwork all belong to launching a company, and none of them are what a technical validation run examines.
Questions
What is a production readiness audit?
An independent evaluation of whether named technical controls are in place and working, tested against published standards, with the strength of the evidence behind each result recorded. It is built to answer a buyer's question rather than to confirm the author's own impression.
How is this different from the free readiness tool?
The tool is a self-assessment: you answer the questions, it runs entirely in your browser, and nothing is sent anywhere. An audit runs the other way round. We test the system and produce evidence, so the result does not depend on you being trusted. Most people use the tool first, then run the audit on what it flagged.
When is the right time to run one?
Before the first real customer, before answering a security questionnaire, and before a funding process. Each is a moment when somebody asks you to prove something, and the cheapest time to find a problem is before the person asking is watching.
What do we get at the end?
A result for each control with its evidence grade, an explicit list of the controls the run could not reach, remediation guidance for what failed, and a Passport you can publish if you choose to. Publication is your decision, and nothing becomes public because a run happened.
Are all thirteen controls tested every time?
No, and a report claiming otherwise would be the problem it is meant to solve. What a run can reach depends on which layers you ran and what the application exposes. Anything unreachable is reported as uncovered rather than quietly passed.
Does a good result mean we are ready to launch?
It means the controls tested passed at the evidence strength shown, which is a narrower statement than being ready. Thirteen controls is a defined floor for production readiness, not a complete security review, and the report is written to keep that distinction visible.
Related
Find out what is actually true of your application
Start with the layer you can run today. The report says which layers ran and what they could not reach, so the result is honest about its own limits.