OWASP's Cornucopia mobile deck turns a card game into a MASVS requirements lookup

The load-bearing part is the mapping table printed with each card. Turn over AA3 and you do not just get a prompt about authentication; you get the CAPEC entries, the OWASP MASWEs, the MASTG best practices and knowledge base items, the MASTG tests and the MASVS requirements that apply to the feature under discussion ^[4][6]. That is the difference between a workshop artefact and a backlog item. The MASVS requirement is what you write into the story. The MASTG test is what tells you it is done.

Then the arithmetic. Six suits of thirteen cards plus two jokers is eighty ^[2], which is exactly the threat count the release states ^[1], so the number of threats is the deck geometry ^[1]. Eighty is what a playing-card format lets you print, not a measurement of MASVS v2.1. The claim that the edition covers all the requirements, tests and weaknesses of the Mobile Application Security Project ^[1] therefore lives entirely in those tables, where one card can point at several requirements. Two things have to hold for that coverage to transfer to your product. Every requirement you care about must appear in at least one card's table, and your real risk must sit inside one of the six suits: Platform & Code, Authentication & Authorization, Network & Storage, Resilience, Cryptography, and Cornucopia, which carries the MASVS privacy requirements plus some mobile malware cards ^[3]. Cryptography gets thirteen prompts whether or not MASWE v1.0 lists more crypto weaknesses than that.

The sprint story is a practitioner report, and worth reading as one. At Admincontrol the deck is played during threat modelling and design, before mobile apps and features get built, and the post says this makes it possible to settle security requirements during the development sprint ^[5][7]. Running the game before sprint planning is what pulls threat modelling into the team's SDLC, and leaving the "what can go wrong" call with the team is what the post credits for preventing scope creep and, in its words, dissatisfied scrum masters ^[8]. What the post does not supply is measurement: no session length, no team size, no threats found per game, no defect outcomes ^[2]. Anyone sizing this against a two-week cadence is extrapolating from one company's description of its own practice ^[5].

The compatibility line is a pin, and pins carry maintenance. v2.0 targets MASVS v2.1, MASTG v2.0 and MASWE v1.0 ^[1], so the mapping tables are current only as long as those three are, and a team that adopts the deck as its requirements index inherits the revalidation job when any of them moves.

The second half of the post argues against handing the decision to agents, and the mechanism it describes is a knowledge one. Its example: agents produce a design requiring Just-In-Time access, the requirement collides with a feature the product manager wants, fixing it with Claude-based agents proves slow and expensive, the review returns 200 comments, and the review, threat modelling and coding agents disagree with each other, so the feature ships and the security stays underdeveloped ^[12]. Reading that through the Dunning quote about needing the skills to recognise a right answer ^[13], the author's position is that a team which never learned why the control mattered cannot defend it under product pressure, and that agents will cheer either choice ^[11].

On the evidence in the post, what v2.0 buys is a requirements lookup indexed by threat rather than by control number, with a game attached, in English plus Hindi, Russian and Ukrainian ^[9], playable online at cornucopia.owasp.org ^[10]. That is a useful thing to have in a design review; whether it compresses threat modelling to fit a sprint is still a claim one team makes about its own process.