Paul Mead
Director of Product Security Engineering
Mimecast
My story moving from App Security to Product Security
Current State & Background
How would you describe Product Security at your organization today?
I'd say it is evolving. I think this is ultimately true of every org today. The rate of change in terms of software development practices (AI etc) as well as Cloud Architecture mean that change is a constant, so Product Sec needs to be changing alongside that too.
Before Product Security became a focus, how was security typically involved in your development lifecycle?
In a very fragmented way. There were elements of product security being handled, sometimes duplicated across Engineering Squads, Engineering Architecture, AppSec/ProdSec Teams, Security Architecture Teams, even GRC - this inevitably led to confusion, duplication and occasional conflict.
Inflection Point
What started to feel misaligned that made you think the focus on holistic product security is needed?
Detection of issues late in process - things we identified could have been found much earlier with things like Design Reviews and Threat Modeling. A key pattern that we saw was the ease with which some types of issues could be spotted - essentially if Team A and Team B had discussed the design/approach each was taking for their work on a shared objective.
How did those issues show up internally - was it delays, friction with engineering, uncertainty, or something else?
Delays due to rework, rework that was more difficult due to the affected work no longer being in the minds of the teams involved (context switching). Discussions around launch delays vs risk - “can we fix this later” type discussions, which could have all been avoided by finding the issues much earlier in the process.
Organizational Response
When you first raised the idea of formalizing earlier or design-stage security, how did leadership respond?
Initial resistance, particularly from those who felt “we’ve always done it this way” resisting change to their approaches.
What concerns did you hear most often from product or engineering teams at the beginning?
These are the main objections we heard:
“Threat Modeling is time consuming.”
“We don’t need this. Our team knows everything they need to know for their work.”
“This isn’t part of our planned work”
“Shouldn’t the security team just do this for us?”
“We’ll do the threat model when we do the pen testing.”
Execution & Impact
How do you measure whether the focus on design stage risk management is actually working versus just box-checking?
We track findings as tasks and defects linked to the originating project. These have an SLA for triage to accept/reject the finding, and an SLA to show any that remain open longer than expected.
What changed once security started engaging earlier - either in planning, design, or architecture discussions?
We provided hands-on training to the teams to enable them. Some teams now DIY and self manage around their review work, others come and ask AppSec to run sessions for them etc.
In quite a few cases significant architectural issues, or incorrect assumptions around who was doing what work, and when; were spotted, and remediated much earlier - this is all a risk management win, as finding those same issues pre-go live or in production would have led to significant disruption.
Reflection
How long did it take to go from "we're doing this" to "this is how we work now", and what were the milestones in between?
I don’t think we have a “done” state for this as we’re continually improving the process, tools and thinking involved. But from the start to our current stable state, it took about 18 months I think.
Looking back, what was harder than you expected about making the shift - and what turned out to be easier?
The groups pushing back were more common and more resistant to change than we had anticipated. We also had some cross departmental false starts where the org tried to move responsibility for the work elsewhere, and add new staff and tooling. This was disjointed with what Engineering needed/wanted and that caused a lot of friction, that we’re still unpicking in some places.
Advice to Peers
For teams considering a similar transition, what would you recommend starting with, and what would you avoid over-optimizing too early?
Do a lot of communication. Get senior management buy-in as early as you can.
Invest time into training the teams on good Threat Modelling practices. Find your champions, and work with them to engage the teams - don’t try to force the practice or tools, work with teams to find what works with them initially, and encourage a long term drift to standard ways of working etc.
I see this practice as fundamentally a culture change for an org - it’s not a case of simply saying something is now changed, you have to bring people with you on the project, they have to want to engage.