--- title: "The Pre-Launch Security Checklist for 2026: What the Standards Actually Require" date: 2026-09-17 author: "Tobias Rast" featured_image: "https://static.pegotec.net/uploads/2026/08/pre-launch-security-checklist-2026.webp" categories: - name: "Pegotec News" url: "/category/news.md" --- # The Pre-Launch Security Checklist for 2026: What the Standards Actually Require Most pre-launch security checklists you find online are somebody’s private list. That makes them impossible to audit and impossible to argue with. Consequently, this one is built from published standards instead — every item cites a requirement identifier you can look up, quote in a review, and hold a vendor to. ## Start from ASVS, and know what a level means The OWASP Application Security Verification Standard 5.0.0, published 30 May 2025, remains the current release. It contains **345 requirements across 17 chapters**. Those requirements are split into **70 at Level 1, 183 at Level 2, and 92 at Level 3**. Notably, that makes L1 only about 20% of the standard, while claiming L2 means implementing 253 requirements — roughly three-quarters of the entire standard. Therefore, be precise when someone says “we follow ASVS.” Ask which level, and ask what they excluded. ## The level trap nobody mentions Here is the finding that should change how you set your gate. The ASVS Configuration chapter contains 21 requirements — and exactly **one** of them sits at L1. Worse, the Security Logging and Error Handling chapter contains **zero** L1 requirements. Sixteen are L2, and one is L3—meanwhile OWASP Top 10:2025 lists logging and alerting failures as a top-ten risk. Consequently, an L1-only gate is blind to an entire Top 10 category by construction. If you take a level off the shelf without tailoring it, that is the hole you ship with. ## Three checks you can automate this week These are L1, unambiguous, and trivially machine-verifiable. - **V13.4.1 — no source-control metadata reachable.** Deploy without `.git` or `.svn` folders, or make them inaccessible externally and to the application. Request `/.git/config` against the deployed origin and fail the build on a 200. - **V6.3.2 — no default accounts.** Enumerate accounts and fail on anything resembling. `root`, `admin` or `sa` still present or enabled. - **V15.2.1 — no component past its remediation window.** Fail on any dependency older than the SLA you documented under V15.1.1. ## Four things no scanner can check for you ASVS 5.0 deliberately separates documentation requirements from implementation requirements. Verifying that a decision is written down, and verifying that it is actually built, are two different activities. Four documentation requirements sit at L1: documented input-validation rules (V2.1.1), documented rate-limiting and anti-automation configuration (V6.1.1), documented function-level and data-level authorization rules (V8.1.1), and a documented risk-based remediation window for vulnerable third-party components (V15.1.1). Crucially, without those artifacts, the paired implementation requirements are not passing. They are unverifiable, which is a different and worse status. ## Your password policy probably fails L1 This is the section that surprises teams most, because ASVS inverts conventional corporate policy. - **V6.2.5 forbids composition rules entirely**—no mandatory uppercase, digit, or symbol requirements. - **V6.2.7 requires that paste works**, along with browser password helpers and external password managers. - **V6.2.8 forbids truncating** or case-transforming the submitted password. - **V6.2.4 requires screening** new passwords against at least the top 3,000 common passwords matching your policy. - **V6.2.1 sets an 8-character minimum**, with 15 recommended. So if your signup form requires one uppercase letter and one symbol, or blocks pasting, you fail L1 today. Replace the composition rules with the breached-password check instead. ## Storage parameters, stated exactly Vague guidance like “use a strong hash” fails review. The OWASP Password Storage Cheat Sheet gives checkable numbers instead. Use **Argon2id** at a minimum of m=19456 (19 MiB), t=2, p=1 — or the alternative configuration m=47104, t=1, p=1. Where Argon2id is unavailable, use **scrypt** at N=2^17, r=8, p=1. Additionally, put those numbers in your own documentation. A reviewer can then check configuration against a stated target rather than against an opinion. ## Update your vocabulary to Top 10:2025 The 2025 edition reordered things in ways that affect what you check. Broken Access Control remains number one and now **includes SSRF** — so stop tracking it as a standalone item. Security Misconfiguration jumped from fifth to **second**. Software Supply Chain Failures enters as an expanded category covering build systems and distribution infrastructure, not merely your dependency list. Mishandling of Exceptional Conditions is entirely new. However, use the Top 10 for prioritization rather than as the gate itself. Two of its ten categories come from a community survey rather than measured data, which the project states openly. ## The supply-chain category is not a dependency scan Software Supply Chain Failures deserves separate attention, because most teams will tick it with a dependency scanner and move on. That is not what the category covers. It expands the older “vulnerable and outdated components” entry to include the build systems and distribution infrastructure around your dependencies. Your CI runner, your artifact registry, your release signing, and your package-publishing credentials all sit inside it. Notably, OWASP records this category as having the fewest occurrences in its dataset but the highest average exploit and impact scores. Rare, in other words, and devastating when it happens. Therefore, add build-pipeline checks alongside the package list: who can publish, what signs artifacts, and which third-party actions your pipeline executes. ## Where to look up the detail ASVS states requirements but deliberately does not explain implementation. Accordingly, the OWASP Cheat Sheet Series maintains an official index that maps cheat sheets to the ASVS section by section. Use that pairing when a requirement is clear, but the method is not. One caution, though: some individual cheat sheets still reference older Top 10 editions, so check the vintage of any specific page before citing it in a review. ## Report what you checked, not just what failed ASVS requires a verification report that lists every requirement checked, as well as those explicitly marked as non-applicable. That is a meaningfully different artifact from a penetration-test report, which lists findings only. The distinction matters at launch. A findings-only report tells you what someone happened to look for. Consequently, it cannot tell you what was never examined. ## How to run this as an actual gate 1. **Pick a level, then tailor it.** Start at L1, then promote the logging chapter explicitly — otherwise you inherit the blind spot described above. 2. **Write the four L1 documentation** artifacts **first.** Nothing downstream is verifiable without them. 3. **Automate what is mechanical.** Source-control metadata, default accounts, dependency age. 4. **Record non-applicable requirements deliberately.** “Not applicable” is a decision with a reason, not a silence. 5. **Re-run at every release**, because configuration drifts faster than code. ## How Pegotec helps We run standards-referenced gates rather than private lists, so the output is a report a client’s own auditor can follow. Furthermore, we record non-applicable requirements with reasons, which usually saves time later. If you need a launch gate that survives external review, [talk to us](https://pegotec.net/contact-us/). ## Read next - [Developing and Maintaining Security-Critical Applications](https://pegotec.net/best-practices-for-developing-and-maintaining-security-critical-applications/) — the practices behind the checklist. - [How We Handle Feature Flags for Gradual Rollouts](https://pegotec.net/how-we-handle-feature-flags-for-gradual-rollouts/) — reducing blast radius at launch. - [The True Cost of Deferred Software Maintenance](https://pegotec.net/true-cost-of-deferred-software-maintenance-2026-failure-benchmarks/) — what unpatched dependencies cost later. **Which ASVS level should a pre-launch security checklist target?**Start at Level 1 but tailor it deliberately. ASVS 5.0.0 contains 345 requirements, split into 70 at L1, 183 at L2, and 92 at L3, so L1 is only about 20% of the standard, and claiming L2 means implementing 253 requirements. The critical gap is that the Security Logging and Error Handling chapter has zero L1 requirements, while OWASP Top 10:2025 ranks logging and alerting failures in the top ten. Promote that chapter into your gate explicitly, or ship blind to an entire Top 10 category. **Does a standard corporate password policy pass OWASP ASVS?**Usually not. ASVS 5.0 requirement V6.2.5 forbids composition rules entirely — no mandatory uppercase, digit, or symbol. V6.2.7 requires that paste, browser password helpers, and external password managers all work, and V6.2.8 forbids truncating or case-transforming the submitted password. The minimum length under V6.2.1 is 8 characters; 15 is recommended. Instead of composition rules, V6.2.4 requires screening new passwords against at least the top 3,000 common passwords matching your policy. **What password hashing parameters should we configure?**The OWASP Password Storage Cheat Sheet gives exact values rather than vague guidance. Use Argon2id at a minimum of m=19456 (19 MiB), t=2, p=1, or the alternative configuration m=47104, t=1, p=1. Where Argon2id is not available, use scrypt at N=2^17, r=8, p=1. Record the chosen parameters in your documentation so a reviewer can check the running configuration against the stated target rather than an opinion. **Is an ASVS verification the same as a penetration test?**No, and the difference matters at launch. ASVS requires a verification report that lists every requirement checked, as well as those explicitly marked non-applicable. A penetration-test report lists findings only. A findings-only report tells you what someone happened to look for, but it cannot tell you what was never examined. For a launch gate, you want the coverage statement, with non-applicable items recorded as decisions with reasons rather than silences.