As organizations face mounting pressure to balance innovation with compliance, embedding security directly into the software development lifecycle has become essential. At Sign In Solutions, this journey is guided by a deliberate adoption of OWASP SAMM (Software Assurance Maturity Model) and the SAMMY platform to make application security both measurable and sustainable. Leading this effort is Jason Mordeno, Director of Compliance and Security, who also serves as the company’s Global Privacy and Data Protection Officer.
Jason has played a pivotal role in transitioning Sign In Solutions from a checklist-driven approach toward a culture of continuous improvement. By integrating OWASP SAMM into their secure software development lifecycle (S-SDLC), his team has aligned security practices with ISO 27001, SOC 2 Type II, GDPR, and other frameworks, while ensuring engineering velocity remains high. SAMMY further enables them to assess, validate, and plan improvements in a way that is visible to both engineers and leadership.
In this interview, Jason shares how Sign In Solutions has embedded security into its workflows, the challenges of avoiding “tick-box” compliance, and how OWASP SAMM and SAMMY are helping the company build a scalable, resilient, and evidence-backed security program that supports both innovation and trust.
In what context are you using OWASP SAMM?
We’re using OWASP SAMM as part of our enhanced Secure-DLC (S-SDLC).
When did your organization start using OWASP SAMM?
We slowly transitioned to OWASP SAMM from OWASP Top 10 mid-2024.
What were the deciding factors to select OWASP SAMM?
Many reasons, but we’ll pick a few. We moved to OWASP SAMM to protect ourselves from the “tick-box” approach that can creep in during high-pressure deliverables and to keep our compliance and security program both measurable and sustainable. As engineers know, checklists and frameworks can be useful guardrails, but without an ongoing feedback loop they can quickly turn into static documents that teams reference only for audits. That’s where continuous improvement often gets lost.
We see OWASP SAMM as a better fit because it’s designed to embed security gradually into every phase of the SDLC and not just at the end. It aligns well with the way our development teams work from architecture and design decisions, through implementation, automated testing, and into daily operations. It also layers silently with other frameworks we already have in place, such as CCPA, GDPR, ISO 27001 ISMS, and SOC 2 Type II trust service criteria; meaning it strengthens both our existing posture and our engineering practices. Its maturity levels give us a way to track progress in a measurable way, identify improvements, and adapt as technology stacks, deployment models, and threat landscapes change; which in the cloud environment it always does.
The transition to OWASP SAMM was deliberate and gradual, which meant we could map existing workflows and security activities directly into its structure without slowing delivery. We injected enhancements to our existing practices such as secure coding practices, automated scanning, threat modeling, and CI/CD security checks by fitting it into a broader maturity model that we can measure and improve over time. This has helped us avoid negative drift, where processes degrade as priorities shift, and has kept security in focus even when timelines get tight.
With OWASP SAMM, application security has become an ongoing, evolving practice; something we actively improve in our processes, where we can, rather than a one-time effort to tick boxes on a list. It gives us both the structure and the flexibility to keep engineering velocity high while ensuring security is structurally implemented rather than sticker’d on.
What are the biggest challenges in implementing OWASP SAMM?
One of the biggest challenges in implementing OWASP SAMM or any type of framework or model, even one focused specifically on application security, is the risk of fatigue. Many organizations already operate under multiple standards and certifications, and introducing yet another framework can create the perception that it’s just another “tick-box” compliance exercise. This perception can lead to an allergic resistance, not because the framework lacks value, but because teams associate it with extra work, administrative overhead, or new restrictions that may slow delivery.
Another challenge is the way a framework is introduced. Rolling it out in a big, formal push can feel disruptive, especially if it comes with an immediate list of new requirements. Engineers may see it as a checklist handed down from the gods above rather than something that supports their work, which can make adoption harder and limit its effectiveness.
We addressed these challenges by introducing OWASP SAMM gradually and quietly, building it on top of our existing compliance controls with ISO 27001 ISMS and SOC 2 Type II trust service criteria. Many of OWASP SAMM’s practices naturally align with controls we already follow, so instead of creating separate processes, we embedded its principles into what teams were already doing. This allowed us to gain early and quiet-humble wins without creating friction.
Once it had some early momentum, meaning certain practices were already familiar and being followed, we further began integrating OWASP SAMM more visibly into our triages, security reviews, and development processes. We focused on shaping better security behaviours and decision-making over time, rather than overwhelming teams with a sudden, all-at-once rollout of new rules.
This “silent mover” approach helped us in several ways: it reduced resistance by showing the practical value of SAMM before formally labeling it, as it allowed us to map and adapt practices without slowing delivery, and it ensured SAMM became part of our engineering culture rather than an isolated compliance checklist. By introducing it this way, we kept adoption smooth, prevented framework fatigue, and positioned SAMM as a long-term enabler of secure development rather than just another audit requirement. We know there’s still a long way to go, but the path we’ve taken shows our engineers that we’re here to guide and support them, building on the strong work they’ve already accomplished.
Jason Mordeno,
Director of Compliance and Security
Global Privacy and Data Protection Officer
When did you start and what were the deciding factors for using SAMMY?
We started looking into how OWASP SAMM could work for us around mid-2024 and officially began using SAMMY in early 2025. It fits right into our existing compliance and security program without creating extra hoops to jump through. SAMMY is flexible enough to adapt as we move along and it scales naturally with how we already work. That’s made it easy to weave into our daily routines while still supporting the bigger picture of long term security and engineering goals.
What are your objectives in the use of OWASP SAMM and SAMMY? What do you hope to achieve?
Our objectives with OWASP SAMM and SAMMY are to scale application security effectively, manage control drift, and have it as part of our compensating layer to enable innovation. Using SAMM’s structure across Governance, Design, Implementation, Verification, and Operations, we can embed security into every stage of the SDLC. This ensures our practices grow with the business, align with frameworks like ISO 27001 and SOC 2 Type II, and remain measurable through SAMM’s maturity levels.
What we hope to achieve is a security program that integrates seamlessly into engineering workflows, maintains audit readiness without extra overhead, and empowers teams to deliver secure software faster and with confidence.
What have been the main benefits so far of working with Codific?
“Working with Codific and using SAMMY has made a real difference in how we approach application security. We can assess, validate, and plan improvements which have turned our AppSec work into a continuous and measurable process instead of a one-off exercise.”
What are your three favorite features or functionalities of SAMMY? Can you share why these are important to you and how they have helped you so far?
Live Benchmarking and Target Postures
Framework Mappings
Dashboards
My favorite parts are the risk coverage approach to questions, the live benchmarking and quantifiable target postures against OWASP SAMM practices. The mapping saves us time by sound checking across our frameworks, the workflow keeps us moving forward with clear priorities, and the dashboards make progress visible to both engineers and leadership.
Do you have any advice for those considering working with SAMMY?
For anyone considering SAMMY, use it to build habits, not just tick boxes, and take advantage of the training and resources Codific provides in parallel with what is on the OWASP SAMM official site. It’s been a great way to keep security practical and measurable.
What have been the main benefits so far for you of using OWASP SAMM and SAMMY?
1. Fluid and Natural Path with Application Security
OWASP SAMM has given us a way to further improve application security and an enhanced natural way of how we build software and not just a separate checklist we run at the end. For our collaborative teams this means security isn’t an extra task to add-on, but rather it’s embedded into our existing workflows. Over time, we’ve seen subtle and positive changes with engineering habits: design discussions include security considerations by default, PR reviews actively check for security flaws, and pipelines have enhanced processes to catch vulnerabilities before they emerge. None of this happened overnight as it evolved naturally because SAMM’s structure makes security feel like part of building quality software, and not a blocker to it.
2. Iterative Behavioural Changes Built into Vulnerability Management and the SDLC
The SAMM maturity model lets us build security into our vulnerability management and SDLC in small and manageable steps instead of trying to revamp everything at once. For example, we started by introducing structured reviews even in micro-steps that include security impact checks, then layered with enhanced automated dependency scanning in CI, and later added an improved mandatory security testing before production releases. These steps were tied to existing processes that engineers already follow such as ticket triage, sprint planning, code merges; they then became habits and not burdens. Engineers don’t have to context-switch into “compliance mode” because security is now part of how we track, fix, and prevent issues in the same workflow we use for feature work and bug fixes.
3. Enhancing Quality, Integrity, and Cyber Insurance Readiness
This section is specifically for application security. Insurers increasingly want to know that we’re not only reacting to threats, but are actively preventing them. Through OWASP SAMM, we can show that our applications are built and maintained with quality, integrity, and resilience in mind. That means we can demonstrate processes like verifying that code changes check for vulnerabilities, having clear escalation paths when issues are found, and tracking fixes from discovery to deployment. From a security engineer’s perspective, it’s the difference between “we think our app is secure” and “here’s the evidence that it is.”
This documentation and maturity proof help us in insurance coverage and assessment. During these insurance activities, insurers require a set of documents and material practices to evaluate the cyber risk of your organization, and OWASP SAMM gives us a structured, evidence-backed way to provide them specifically for application security. Instead of pulling fragmented docs from different systems that don’t interconnect, we can instead point to our OWASP SAMM assessments, maturity scores, and mapped controls as a single and organized source of truth. This allows us to present to insurers on how we structure and clearly show how we identify, assess, and mitigate risks across the entire SDLC such as from secure design and coding standards, through vulnerability management, to operational monitoring and incident response.
OWASP SAMM also makes it clear that these are not one-off compliance tasks, but part of a continuous improvement cycle. This level of organization and traceability reduces back-and-forth during the insurance coverage assessment process, builds trust with the insurer, and positions us more favorably for premiums and coverage.
In many organizations, application security gets folded into ISO 27001 or SOC 2 Type II compliance registry controls and presented to insurers as a set of compliance “tick boxes.”
The problem is, when insurers perform a deeper assessment review as part of the cyber coverage process, they often find that these controls exist on paper, but are not backed by consistent, real-world processes. You could try to bridge this gap with something like the OWASP Top 10, but it’s typically not enough on its own because it focuses on risk categories rather than continuous operational maturity.
By leveraging OWASP SAMM, we can present application security as an objective, measurable, and material part of our overall risk management program. This gives insurers confidence that our application security practices are embedded in daily operations, continually improving, layered as a compensatory framework amidst other frameworks and directly contributing to reducing real-world risk which is exactly what they’re looking for during a cyber insurance coverage assessment.
4. Alignment with EU GDPR Security Requirements
GDPR can feel abstract to engineers, but OWASP SAMM turns it into actionable and natural practices. Article 25’s “data protection by design and by default” becomes threat modelling in our review sessions, role-based access control in our APIs, and data minimization in our schemas. Article 5’s “integrity and confidentiality” becomes encryption in transit and at rest, secure logging, and automated alerts for suspicious access patterns. The OWASP SAMM approach builds these into our existing SDLC and operational processes allowing us to technically fulfill GDPR requirements without spinning up an entirely separate compliance track. That means less duplicate work for engineers and a cleaner and more streamlined development flow that keeps us compliant.
Would you recommend the use of OWASP SAMM to others? And if so, for which kind of situations/organizations would it fit best?
I’d recommend OWASP SAMM to any organization whether you’re a 3-person dev team just getting serious about security or a large enterprise managing dozens of services. For smaller teams, it gives you a roadmap that grows with you. For bigger teams, it helps prevent “negative control drift” that slows erosion of good practices that can happen when you’ve got lots of moving parts and competing deliverables. It’s especially powerful if your org already uses reliability engineering practices like incident postmortems, SLOs, and infrastructure-as-code reviews. SAMM fits right alongside these, so security becomes another dimension of system reliability rather than a separate silo. Engineers see the benefit because it improves the stability, safety, and maintainability of the systems they have already built without sacrificing velocity. Build for resilience.
Do you have any advice for those looking to start implementing OWASP SAMM?
Start early even if it’s small micro steps. OWASP SAMM has a much bigger impact and feels more natural when it’s introduced early in your development culture rather than added on later. I’d recommend running OWASP Top 10 and SAMM side by side from the start. Together, they’ll give both engineering and compliance teams a clear picture of what’s most important and where the real gaps are.
Don’t feel like you have to roll it all out in a month or asap. Take your time and focus on building habits that stick. Rushing it just turns it into another tick box exercise that gets in the way of delivery. The goal is progress you can sustain and not absolute perfection overnight.
From a compliance perspective, keep engineers in the loop on why certain controls exist and how they connect to your existing frameworks and requirements. When engineers understand the link between secure coding practices, automated checks, and audit requirements, they will see security as part of delivering quality software and simply a tickbox exercise. Lastly, the earlier you bake security into your workflow, the less it costs to fix later and the more freedom you’ll have to innovate without blockers down the road.
What role do you think OWASP SAMM will play in the future for the industry?
For us, it has already started to shape how we approach application security, and that influence will only grow in the future. As more organizations adopt it, the trust between what it promises and what it delivers will only get stronger. I can see it becoming a go-to standard for weaving security into the software lifecycle in a way that works for engineering teams: practical, measurable, and something people choose to use rather than feel forced to follow.
Do you have any advice for those looking to start implementing OWASP SAMM?
For us, OWASP SAMM is our primary framework for application security and also serves as a compensating framework for our ISO 27001 ISMS controls, SOC 2 Type II trust services criteria, and CCPA and GDPR requirements. It allows us to align application security practices with our broader compliance obligations which then creates a cohesive approach with checks and balances rather than managing separate and isolated siloed processes.
Is there anything we forgot to ask in these questions that you think is important? Anything you would like to add?
I’d suggest visiting the OWASP website and taking the time to explore what interests you on application security. There are many paths and you’ll find a lot of value and perhaps even enjoyment in the materials, guidance, and community resources available.