Beyond ASVS: Cheat Sheets, WSTG, SAMM, MASVS and PCI Software Security

The OWASP® Application Security Verification Standard (ASVS) tells you what a secure application must verifiably do. It doesn't tell you how to build each control, how to test it, whether your organization can repeat the result, or whether a payment product can be listed by the PCI Security Standards Council. This last part of the series maps the other OWASP projects and the PCI Software Security Framework onto those questions, so you reach for the right document at the right time.

ASVS is a requirements catalog: roughly 350 requirements in 17 chapters and three levels, according to its frontispiece, each written so you can mark it pass or fail. That makes it the right backbone for a payments API (Part 3 covers the structure), but a requirement is only the start. Someone still has to write the code, someone has to try to break it, and someone has to decide whether the team can repeat this every sprint.

The OWASP Top 10:2025 sits on the other side. It is an awareness document, and its own program chapter points readers to ASVS as the standard to verify against, to SAMM for improving how software gets built, and to the Cheat Sheets for developers. Part 4 compares the two in detail.

Each resource below answers a different question. Mixing them up is how teams end up "testing against the Top 10" or calling a vendor's product "PCI compliant".

Open the diagram full size:

Scroll sideways to see the whole diagram. Open full size

The OWASP Cheat Sheet Series is a collection of short implementation guides, one per topic, written for developers. There are well over a hundred, so the useful entry point is the ASVS index, which maps every ASVS 5.0 chapter to the sheets that help implement it. A story citing an authentication requirement from chapter V6 leads you to the Authentication, Password Storage and Multifactor Authentication sheets.

Two sheets deserve a place in every payments team's onboarding:

• Third Party Payment Gateway Integration: recalculate totals on the server, authenticate gateway callbacks, confirm status and amount with the gateway's API before fulfilling an order, handle duplicate and out-of-order events idempotently, and never trust parameters that come back through the browser.
• Transaction Authorization: the user confirms the significant details (amount, beneficiary) before authorizing, the authorization is bound to transaction data held on the server, and an attacker can't downgrade the method to a weaker one.

Cheat sheets are guidance, not requirements, and they don't always agree with ASVS. For PBKDF2-HMAC-SHA512, ASVS Appendix C sets a floor of 210,000 iterations while the Password Storage Cheat Sheet recommends 220,000. Pick one and name the source in your design record; Part 5 works through these choices.

The Web Security Testing Guide (WSTG) is OWASP's manual for testing web applications: a methodology plus test cases. Version 4.2 is the current stable release; version 5.0 is in development and, as of October 2026, has not been released. The v4.2 test cases are grouped into 12 categories, from information gathering through authentication, authorization and session management to API testing.

For payments, the category I'd point to first is business logic testing, because that's where money moves and automated scanners are weakest. WSTG v4.2 has tests for process timing, limits on how many times a function can be used, and circumvention of workflows. In payment terms: refunding the same capture twice, racing two payouts against one balance, or skipping the authentication step in a checkout flow.

WSTG complements ASVS. The ASVS 5.0 assessment chapter discourages black-box-only testing as an assurance method and recommends testing led by documentation or source code. Use WSTG cases inside a test plan that also includes code review and automated tests.

OWASP SAMM (Software Assurance Maturity Model) is a self-assessment model for an organization's software security program; 2.2.0 is the latest release. Its model has five business functions (Governance, Design, Implementation, Verification and Operations), each with three security practices. Each practice has two streams of activities and three maturity levels, and you choose a target level per practice rather than aiming for the top everywhere.

The difference from ASVS is scope. ASVS asks whether this application meets a requirement. SAMM asks whether your organization reliably produces software that does. A team can ship one service that meets ASVS Level 2 and still score low in SAMM if that result depended on one engineer and no repeatable process.

SAMM also credits unglamorous engineering work. As a team lead on a wealth management platform, I built CI/CD quality gates (automated tests and SonarQube) and engineering standards that cut production incidents by 35%. In SAMM's vocabulary, that work maps mostly onto the Secure Build practice under Implementation, with some of Verification.

For PCI-scoped teams, SAMM's model pages link every stream to OpenCRE, which connects them to standards such as PCI DSS, ASVS, NIST SSDF and NIST 800-53.

The Mobile Application Security Verification Standard (MASVS) is the mobile counterpart of ASVS: baseline security and privacy requirements for iOS and Android apps. It sits at the top of a chain. MASVS says what to achieve, MASWE (the Mobile Application Security Weakness Enumeration) lists the weaknesses, and the MASTG (Mobile Application Security Testing Guide) says how to test.

The latest release, v2.1.0, added a MASVS-PRIVACY group, giving eight control groups: storage, cryptography, authentication, network, platform, code, resilience and privacy. Since v2.0.0, the old L1, L2 and R levels are no longer part of the standard; they moved to the MASTG as testing profiles.

If merchants or cardholders use your mobile app, ASVS still covers the backend API it calls; MASVS covers the device side, such as token storage, certificate validation and tamper resistance.

OpenCRE (Open Common Requirement Enumeration) is an OWASP project that links security standards through a shared catalog of common requirements. Start from one topic and it shows the matching sections in other documents.

Treat any mapping as a starting point. As Part 7 showed, the ASVS project publishes no official mapping to PCI DSS, so even links you find through OpenCRE are candidates, and every line you draw needs a written reason.

The PCI Software Security Framework (SSF) is the Council's set of standards and validation programs for payment software vendors. According to the SSF FAQ, it has two standards: the Secure Software Standard, which covers products, and the Secure Software Lifecycle (Secure SLC) Standard, which covers how a vendor builds them.

The Payment Application Data Security Standard (PA-DSS) was formally retired on October 28, 2022, after the Council published the SSF requirements in January 2019 as the way forward. Per the SSF FAQ, PA-DSS applications moved to the "Acceptable Only for Pre-Existing Deployments" list when their validations expired.

The Council published v2.0 on January 15, 2026, the first major revision. It adds a companion document for identifying sensitive assets, makes software development kits eligible (including EMVCo 3DS SDKs, with a route intended to eventually replace the separate PCI 3DS SDK Standard), allows wildcards for changes that don't affect security, and revises the process for assessing changes. A 12-month transition from v1.2.1 starts once assessor training is available; the Council expected computer-based training in Q1 2026. I haven't found a published retirement date for v1.2.1, so check the Document Library before you plan a validation.

The draft went through a request for comments from May 15 to June 15, 2026, and the Council published v2.0 on September 28, 2026. It aligns with the sensitive-asset focus of the Secure Software Standard v2.0 and adds requirements on digital tools, including how a vendor accounts for AI. The transition from v1.1 also runs 12 months from training availability, with training expected in Q4 2026. Neither standard requires an assessment against the other, but vendors with a listed and validated Secure SLC get program benefits for the products they build with it.

• A product is validated to the Secure Software Standard by a qualified assessor, accepted by the Council and listed on its website.
• A vendor's lifecycle is validated to the Secure SLC Standard and listed in the same way.
• A merchant or service provider is assessed against PCI DSS. Compliance belongs to that entity, never to a product.

The SSF FAQ is explicit: validated payment software may support the security of your cardholder data environment, but it doesn't make you PCI DSS compliant, and it still belongs in your own assessment. Whether you must use validated software is up to the payment brands, not the Council. The FAQ also describes the Secure Software Standard as meant for payment software sold, distributed or licensed to third parties (including software delivered as a service), not for software a company builds for its own sole use. That FAQ dates from 2019, so confirm eligibility in the current Program Guide.

The practical consequence: if you build a payments platform for your own use, SSF validation is not your path; PCI DSS Requirement 6 is (Part 1 and Part 7). If you sell payment software to other companies, the SSF may apply, and a SAMM self-assessment is a cheap way to find lifecycle gaps before a Secure SLC assessor does.

For a payments team building its own platform, this is the starter kit I'd adopt, in order:

• ASVS 5.0 as the requirement set, with versioned IDs in stories and tests. On a multi-tenant payment aggregator I work on, I set up a spec-driven, test-first delivery workflow (a backend test standard and an ADR template) and built the admin and merchant sign-in against 13 ASVS 5.0 controls. Requirements as the spec, tests as the proof, ADRs for the trade-offs.
• The Cheat Sheets through the ASVS index, linked from tickets, with the payment gateway and transaction authorization sheets as required reading.
• WSTG business logic and authorization tests in the pre-release test plan, next to code review and automated tests.
• A SAMM self-assessment once a year, picking two or three practices to raise rather than everything at once.

Add MASVS when you ship a mobile app, use OpenCRE when you need to show how two standards relate, and look at the PCI SSF only if you sell payment software to others.

Over eight parts, we moved from what PCI DSS 4.0.1 asks of engineers and how scoping and SAQ D shape the work, through ASVS 5.0 and how it differs from the Top 10, into concrete controls: authentication for a payments API and payment page scripts under 6.4.3 and 11.6.1, then the mapping from ASVS to Requirement 6. The thread running through all of it: PCI DSS tells you what an assessor will check, the OWASP documents tell you how to build and verify it, and your team needs both written down in a form it can test.