Security testing before a launch: what we run, in what order
The sequence of security checks we run on a website or application before it goes live, from automated scans in the pipeline to a manual review.
The short answer
Security testing before a launch is a sequence of layers, each catching what the previous one cannot, run in order of cost so that the expensive human attention goes where it is needed. First the automated checks that run in the pipeline on every change: dependency scanning for known vulnerable packages, secret scanning for leaked keys, static analysis for common coding mistakes. Then configuration checks: headers, content security policy, cookie flags, HTTPS and HSTS, exposed files and endpoints. Then an automated application scan against the preview environment. Then a manual review of the risky parts: authentication, access control, input handling, file uploads, payments, integrations. Then, where the data or the client justifies it, a penetration test with a retest. The results become a fix list with severities, the fixes are retested, and the summary is the evidence you keep for clients and questionnaires. The automated layers keep running after launch; the manual ones repeat when the application changes materially.
The sequence
| Order | Layer | What it catches | When it runs |
|---|---|---|---|
| 1 | Dependency scanning | Packages with known vulnerabilities | Every build, from the first week |
| 2 | Secret scanning | Keys and passwords in code or history | Every change |
| 3 | Static analysis | Common coding mistakes: unescaped output, unsafe queries, weak crypto | Every build |
| 4 | Configuration checks | Headers, policy, cookies, HTTPS, HSTS, exposed files, verbose errors | Before launch and after configuration changes |
| 5 | Automated application scan | Injection, scripting, misconfiguration across the running application | Against the preview before launch; scheduled afterwards |
| 6 | Manual review of risky areas | Access control, logic, sessions, uploads, payments, integrations | Before launch; after material changes |
| 7 | Penetration test | What a skilled attacker can chain and reach | Before launch where justified; yearly or after major changes |
| 8 | Retest | That the fixes worked | After every round of fixes |
Running it well
- Put layers one to three in the pipeline on day one, so findings appear as code is written.
- Run the configuration checks against the preview, fix, and re-run; record the results.
- Scan the preview with an application scanner using test accounts at each role.
- Review the risky areas by hand with a checklist: every role tried against every other role’s data; every input given malformed values; every upload given the wrong file; every payment path walked.
- Commission the penetration test early enough that the retest finishes before launch.
- Triage all findings by severity and exploitability; fix the top group before launch; schedule the rest with dates.
- Retest and keep the report, the fix list and the summary.
- Leave the automated layers running and schedule the scan and the manual review for after changes.
What the business receives
A short summary of what was tested, at what layers, with what results and what was fixed. The scan and test reports with statuses after retest. The list of accepted findings with reasons. And the assurance that the automated layers continue on every change. That package answers most client security questionnaires and is the record that testing happened, which matters when someone asks later.
What this means for you
Security testing before launch is layered and sequenced: automated scanning in the pipeline from the start, configuration checks, an application scan, a manual review of the risky areas, and a penetration test where the data justifies it, each followed by fixes and a retest. Planned in from the first week, it adds little to the timeline and produces evidence you will use for years. Left to the last week, it produces a choice between a delay and a flaw.
Frequently asked questions
How long does security testing add to a launch?
The automated layers add minutes to every build and are already running throughout development. The configuration and header checks take an hour. The manual review of the risky parts takes a day or two for a typical business application. A penetration test, where needed, takes a week or two including the retest and is scheduled before the launch date. Planned in from the start, none of it delays the launch; bolted on at the end, all of it does.
Do static sites need security testing?
Less, but not none. Dependency and secret scanning still apply, headers and the content security policy are checked, forms and their functions are tested for validation, bot checks and rate limits, and the third-party scripts are reviewed. The surface is small, so the testing is short, and it is done every time rather than once.
What if the test finds something serious just before launch?
The launch waits, or the affected feature is disabled until fixed. A serious finding discovered before launch is the process working; the alternative is discovering it from an attacker afterwards. This is why the automated layers run from the first week, so that serious findings appear early, and the pre-launch layers confirm rather than surprise.
Sources
- OWASP Application Security Verification Standard (accessed 2026-09-12)