Admincontrol provides secure software platforms for board management and confidential document collaboration. The company evolved its threat modelling practice by introducing OWASP® Cornucopia. This case study explores how a structured, game-based approach enabled their engineering teams to increase their ownership of threat modelling to identify security risks earlier in the development lifecycle.
The Challenge
Although threat modelling sessions were held, they consistently suffered from low and uneven participation. Discussions around threats and mitigations were largely driven by a single security specialist, with limited contribution from development teams. As a result, threat modelling did not scale across the organisation and failed to become a shared engineering responsibility.
Autonomy was another key issue. If central security did not organise and facilitate the sessions, they did not take place. This created a dependency on a small number of individuals and introduced a bottleneck that was incompatible with the goal of decentralised security ownership in an agile working environment.
The company applied several strategies to enable participation:
- Threat modelling presentations and awareness sessions
- Training up a number of security champions
- Follow-up meetings and joint working sessions with teams
- Regular threat modelling discussions in weekly security forums
- Escalation through ISO 27001 ISMS non-compliance reports
Despite these efforts, teams remained largely passive, and threat modelling continued to be perceived as a specialist-led or compliance-driven activity rather than a core part of system design.
What came next?
The objective was to shift threat modelling from a centrally driven separate security exercise to a team-owned engineering practice, embedded into normal delivery workflows.
Adoption was achieved by integrating OWASP Cornucopia, a threat modelling game, alongside Adam Shostack’s four-question threat modelling framework, directly into the company’s software development lifecycle. Rather than positioning Cornucopia as an optional workshop tool, it was mandated as part of Admincontrol’s custom development methodology and became the primary mechanism for structured threat identification.
Playful, structured, and lightweight, this new mandate was well received by teams. Through anonymous feedback, participants reported that the sessions improved both awareness of security requirements and understanding of concrete mitigations, reinforcing the role of the sessions as a learning mechanism as well as a delivery aid.
Threat modelling and related security activities embedded into existing agile practices. Regular security champion chapter meetings, agile security grooming, and security test planning sessions were established and integrated into Scrum as standard ceremonies. As a result, security design, security requirement analysis, threat modelling, and security testing became recurring and expected activities rather than ad hoc interventions.
How things changed?
OWASP Cornucopia introduced a clear, shared framework for identifying threats. Each card in the deck acted as an explicit prompt. This allowed teams to easily get started and discuss threats in the context of their own system architectures rather than relying on abstract guidance or prior threat modelling expertise.
The game format also changed how teams collaborated. Threat modelling sessions became discussion-led rather than facilitator-led. Engineers, QA testers, and project managers were all able to participate meaningfully, identify valid threats, and contribute to mitigations. Overall, it introduced a sense of challenge and enjoyment, which helped sustain a depth of engagement from engineers, and gave specialists space to dive in deeper.
Furthermore, identified threats were translated into security requirements, design decisions, and follow-up tasks during the sessions themselves. As a result, ownership of security activities increased across roles. Development teams took responsibility not only for threat identification and mitigation planning, but also for security requirement gathering and security design decisions. Functional testers began performing penetration testing based on threats identified during Cornucopia sessions, rather than waiting for external penetration testing.
From a delivery perspective, this resulted in:
- Earlier discovery of security issues during development
- Fewer security-related defects identified post-release
- Improved time-to-market due to fewer late rework cycles
Example case: Threat Modelling a New Android Mobile Application
As part of its board portal services, Admincontrol initiated the development of a new Android mobile application. Given the sensitivity of the data handled by the platform and the expectations of a security-aware user base, the application needed to meet a high security bar from the outset.
Admincontrol benchmarks its web services against OWASP Application Security Verification Standard (ASVS) Level 2 and its mobile applications against OWASP Mobile Application Security Verification Standard (MASVS) Level 2 with Resilience requirements (L2+R). For the new mobile app, this meant ensuring that MASVS requirements were addressed during design rather than discovered late through penetration testing. Given the size and depth of the Mobile Application Security Testing Guide, over 570 pages, this required an approach that was both comprehensive and compatible with agile delivery.
OWASP Cornucopia (Mobile App edition) was used as the primary mechanism to identify mobile-specific security requirements, perform threat modelling, and inform the secure design of the application. The deck is explicitly mapped to the OWASP Mobile Application Security Verification Standard (MASVS v2.0) and the OWASP Mobile Application Security Testing Guide (MASTG v1.7), and is structured into six suits aligned with MASVS categories: Platform & Code, Authentication & Authorisation, Network & Storage, Resilience, Cryptography, and Cornucopia, the latter covering privacy-related threats alongside mobile malware scenarios.
Why this worked
One of the first sessions demonstrated how effective the approach was in practice. Despite taking place late in the day after several hours of meetings, the team was able to systematically work through the relevant mobile threat categories in a short, focused session. The discussion flowed directly into defining concrete security requirements and backlog items aligned with MASVS L2+R, allowing threat identification and implementation planning to be completed within the same working session.
Nine months after development began, an external security company conducted penetration testing and MASVS 2.0 verification against the L2+R profile. The assessment confirmed that the application met the required standard, with only a single low-severity finding reported.
This example demonstrated how Cornucopia can be used not only for threat discovery, but as a practical security-by-design mechanism: translating mobile threat modelling directly into requirements, implementation tasks, and verifiable security outcomes within an agile development process.
Key takeaways
A key insight from this case study is that the primary barrier to effective threat modelling was not a lack of training or formal process, but limited engagement and ownership within delivery teams. Introducing a game-based approach lowered the barrier to participation while maintaining technical focus, allowing threat modelling to be decentralised and embedded into everyday engineering workflows.
As a result, ownership of threat modelling and security planning shifted closer to the teams building and testing the systems. Central security was able to move from execution to enablement, focusing on facilitation, process improvement, and scaling good practice across the organisation. This change increased overall security capacity without increasing headcount and helped establish threat modelling as a repeatable, team-owned engineering activity rather than a compliance-driven exercise.
