One of the largest trends in the last several years has been the push to move the cybersecurity and broader software industry towards the concept of Secure-by-Design.

While the concept is far from new, and the idea of building security in, rather than bolting it on has been around for 50+ years, dating back to The Ware Report, it has often been a bit of a utopian view of how security should be done, rather than how it truly is.

I’ve discussed this in various articles before, such as:

• Secure-by-Design Delusions

• Secure-by-Design (and Demand)

• Secure-by-Design vs Secure-by-Default: What’s the Difference?

• The Elusive Built-in Not Bolted-on

The biggest push for Secure-by-Design in recent years has arguably came from the U.S.’s Cybersecurity and Infrastructure Security Agency (CISA), especially under the tenure of the previous Director, Jen Easterly, now the CEO of RSAC.

I’m a huge proponent of the concept, as you can tell from my extensive prior writing on the topic. That said, I’m also a pragmatist and openly have acknowledged the challenges with moving Secure-by-Design from virtue signal, to real commitment and implementation.

I’ve spoken extensively in prior articles about the natural tension when it comes to Secure-by-Design and the competing priorities for businesses. While we’ve even seen some major corporations say that Security will be the #1 priority, at the end of the day, the reality is that companies are rightly focused on priorities such as revenue and speed to market, often leaving security as an afterthought, even if the organization genuinely does have good intentions and wants to produce more secure products.

This is even more true now in the age of AI and AI-coding tools, where product iteration cycles are shorter than ever due to AI’s ability to exponentially boost development velocity.

Even the most well-intentioned organization has faced headwinds when it comes to implementing Secure-by-Design in practice, both culturally and technically.

Some of the factors inhibiting its success historically are tied to incentives, or lack thereof, both from the market and regulatory perspective. That said, there are many organizations that genuinely do want to embrace and implement a Secure-by-Design approach to cybersecurity, but have typically lacked the tools and capabilities to take it from theory to practice - until now.

In this article, I’ll be discussing some of the emerging capabilities that are helping bring Secure-by-Design into reality, and how they address longstanding systemic challenges in cybersecurity that have hindered its success in years past, both from a technical and cultural perspective.

What’s The Hold Up?

While it would take an entire document to try and explain all of the potential factors that have hindered Secure-by-Designs adoption for not just years, but decades, I did want to cover some of the core challenges.

While we like to use feel good catch phrases such as “security as a business enabler”, historically security has been much more of a cost center, friction point and as some developers even call it, a “soul withering chore”.

I personally think that’s a bit harsh, but I won’t hold it against our developer friends. That said, they do have a point. While development moves rapidly and iteratively, security typical moves at a glacial pace by comparison and rather than living in code, pipelines and API’s, often operates in spreadsheets, static documentation and rigid procedures.

Another challenging factor with facilitating Secure-by-Design and building in rather than bolting on security is that security tends to be late to the party. Due to our behaviors, such as beating developers over the head with spreadsheets of toil and low context findings, we’ve unintentionally bolstered the very silos DevSecOps sought to break down.

To move Secure-by-Design from idea to implementation, cybersecurity must begin to live in the same environments, artifacts and metadata that engineering and development does, such as asynchronous communications (e.g. Slack), ticketing system where work is captured, ideation platforms and more.

There are also gaps when it comes to the knowledge bases that security lives and works in. While other enterprise functions such as marketing and sales have robust knowledge bases that extract critical data from enterprise systems and repositories, security often lacks this by comparison, forcing the security team to manually go comb through systems, repositories, discussions and more to try and get enough context about how a system is designed and will be developed in order to weigh in from the security perspective.

These challenges are poised to be challenged even more with the introduction and rapid adoption of AI, as we shift from developing code to describing desired systems and functionality in natural language, with copilots, coding assistants and agents now acting as force multipliers and running with semantic inputs and rapidly leading to developed software.

There’s also the ever present cybersecurity workforce challenges, with security engineers and architects historically being exponentially outnumbered by developers in large enterprises. With security budget growth slowing or even stalling by some reports, this isn’t a problem we can “hire” our way out of either. It requires a paradigm shift both from a technical and cultural perspective.

Secure-by-Design Hits Prime Time

To help provide a concrete example of the sort of innovations and capabilities I’m discussing, I will be using Prime Security as a point of discussion, and as a partner in this post.

Request a Walkthrough

Prime Security has set out to secure every product design decision and their associated risks and to streamline and automate security design reviews by leveraging Agentic AI to be a force multiplier for security, functioning in roles such as Security Architecture and Privacy autonomously.

I’ve spent the last several years advocating for security to leverage AI just as enthusiastically as our development and engineering peers, as well as attackers, if we hope to have any chance of keeping pace and addressing longstanding systemic issues in security. Among those are challenges of scaling design stage security as well as activities such as threat modeling, which historically have been cumbersome and time intensive.

This is also where the clear distinction between Product Security and Application Security are drawn.

There’s no shortage of tooling and products available to help secure code, but the actual design and architecture of systems from inception?

Not so much, until now.

This shift to design-driven security also involved moving from the age old bolted on model of security, to a model where security is built in, not just by people, but through proactive automated security reviews and inputs, that has deep organizational context regarding what developers are working on and proactively sending them recommendations inline with development, whether that’s JIRA today or Cursor tomorrow.

This behavioral shift for security addressing longstanding challenges too, where security comes in after the fact, once something has already been designed and even potentially developed and deployed, functioning as a gate, often requiring expensive and time consuming rework which impedes development velocity, wastes scare business cycles and leads to organizational frustration with security.

Prime looks to address this through automating the security decision layer itself, with strategic design-stage governance and AI-powered decision automation. This is facilitated with deep business and technical context to govern design-stage risk at-scale and with a velocity that will make sure developers and business peers do not tune out and avoid engaging security as they historically have.

Below you can catch a “Day in the Life” product walkthrough showing key aspects of Prime’s approach, from a knowledge base, map of the organization’s environment, current state of risk as well as a working repo of security controls and threats.

This includes starting with a map of the current state of the environment and repository of security controls and threat vectors and how a practitioner can leverage Prime’s design risk coverage to track the work of teams they are less familiar with and get a detailed risk breakdown.

From there, the risk if converted into a full security review with a single click, and within minutes providing them with a detailed summary of development work and other ongoing development efforts that are relevant to it. They also receive specific remediation guidance and risk and requirements are delivered directly into AI coding tools such as Cursor via Prime’s MCP Integration.

When we look at the current landscape in software and cybersecurity, it is clear that coding is getting commoditized. The volume and velocity of AI-generated coding tools is making it impractical and even irrational to expect a human to review all of the AI-generated code at scale.

Across AppSec we’re now seeing innovators look to use the same AI technologies to scale code review, through the use of purpose-built agents, as well as combining LLMs with traditional tools such as SAST to reduce false positives and catch business logic and authorization flaws that legacy SAST tools struggled with.

Prime is looking to do the same with measuring and managing risk at the Design stage. This includes looking at what a human security architect would do, such as assessing a system to understand what a system does, what components it has and what risks are associated with it and automate that human judgement and knowledge at-scale through the use of agentic security architects. While others are looking to do the same, what makes Prime unique is there organizational context they tap into that resolves the visibility and communication challenges associated with security and development teams working together.

At its core, Prime created a context-risk engine by coupling LLMs with context graphs, to map the relationships between systems, features and dependencies and enable context-aware reviews that typically required human labor. This includes bringing together engineering tasks through integrations with knowledge sources, organizational code bases, documentation and enterprise security policies to fully automate a Secure-by-Design (SbD) approach and facilitate Design Stage Risk Management (DSRM), which we will discuss next.

All of this can be presented to security teams and leaders in a comprehensive view to see the time they have saved on traditional time intensive security reviews, how many security violations exist, what the top identified risks are and what security reviews are active, as seen below.

Design Stage Risk Management (DSRM)

Many may be asking, what exactly would we call this paradigm shift, of moving the concept of Secure-by-Design from a talking point to tactical execution. A key term that is catching traction is Design Stage Risk Management (DSRM). From Prime’s perspective, this can be explained as follows:

“DSRM is the proactive identification, modeling, and governance of security risks before implementation actions are taken. It formalizes and operationalizes Secure-by-Design principles with automation, visibility and enforcement.”

When I read that, it directly speaks to points I’ve tried to make previously with regards to the historical challenges of Secure-by-Design, such as in my article “The Elusive Built-in Not Bolted-On”.

While we all collectively head nod and agree that security should be built in rather than bolted on, we’ve largely lacked the methodologies and capabilities to do this in practice, and by trying to retroactively force this on development peers have only created more friction and resentment for cybersecurity within the organizations and among teams.

We’ve seen the rise of other categories in product security such as application security posture management (ASPM) or cloud security posture management (CSPM) which were more focused on build and runtime vulnerabilities, misconfigurations and risks, but historically we have missed a similar category and capabilities for the design stage of the product development lifecycle (PDLC), until now.

The introduction of DSRM helps take security from an afterthought to a key consideration from the design stage, breaking the perpetuating of the paradigm of bolting security on rather than building it in and allowing security to tap into the rich unstructured data sources where design discussions and decisions reside, which was historically too laborious before the rise of LLMs.

This isn’t just a marketing phrase either, its supposed by real world reporting and activities too, as seen below:

One of the biggest enablers of DSRM is that of LLMs. Through their ability to navigate unstructured data and design intent and how it ties back to business context while also accounting for security risks and concerns helps bring DSRM into reality.

The persistence of insecure design is pervasive too, routinely showing up on the OWASP Top 10. To mitigate this risk, OWASP calls for more use activities such as threat modeling and secure design patterns.

However, as I have discussed, scaling programs and activities such as threat modeling has been problematic historically, due to its human-centric approach and manual tasks. We’re now seeing a renaissance in the art of possible in activities such as threat modeling, with open source examples such as StrideGPT, an AI-powered threat modeling tool that leverages LLMs to generate threat models and attack trees for applications.

It is ironic that after years of hearing how we need to "shift security left”, very few of those efforts have focused on Design stage security, and instead focused on the Build and Run stages of the PDLC.

One aspect I particularly like of how Prime views DSRM is the three classes of security decision-making they rally around, as seen below:

• Operational Decisions - Access controls, network changes, privilege escalations, and configuration approvals required to keep systems moving

• Knowledge Decisions - Guidance on secure patterns, best practices, and safe integration approaches that translate security expertise into actionable direction

• Strategic Design Decisions - Higher-impact evaluations such as architectural reviews, privacy implications, vendor selection, and formal risk acceptance

Anyone who has spent years as a security practitioner knows how these decisions manifest in practice, often through informal conversations, discussions among product teams, implicit assumptions and more, all of which security often isn’t involved in, albeit partly due to years of us subjecting our development and engineering peers to laborious manual security practices and being seen as an impediment rather than a collaborator.

By leveraging DSRM and AI capabilities we have the opportunities to take these security decision-making activities from a loose process of dialogue and assumptions to an actual structured operating model, tapping into the various systems and workflows where product design takes place but security often isn’t a part of, or struggles to keep context for.

Prime advocates a robust integration-centric approach for DSRM, tapping into ticketing and workflow systems, communication channels, and architecture tools and coupling it with our traditional security tooling such as SAST/DAST, CNAPP etc. and broader threat and vulnerability intelligence feeds to empower AI-driven Secure-by-Design implementations.

Organizations have historically missed security involvement or bandwidth to maintain context across these data sources, especially beyond traditional security tooling as seen above. Being able to bring it all together in a robust DSRM platform allows security to unify findings and telemetry from traditional security tooling and threat intelligence with broader design and architectural considerations to facilitate a security-centric product development lifecycle (PDLC).

As we know, software is never “done”, and systems and products continue to iterate constantly, and in the age of AI, at a pace and volume like never before. Implementing an AI-powered DSRM platform allows security to shrink the cycles required to keep pace with the product teams velocity and keep context from sprint to sprint or across product release cycles.

DSRM Maturity Model

To help make DSRM approachable for organizations who historically haven’t embraced DSRM principles in practice, Prime proposes a 4 level DSRM Maturity Model, moving from Ad-hoc through Adaptive (Predictive).

This allows organizations to move from an ad hoc approach to DSRM to actually defining processes, working to optimize and automate them and leverage insights from actual organizational outcomes and trends to improve their approach and proactively mitigate risks before they emerge.

Incentives and Regulations

Remember earlier how I spoke about the lack of regulatory forces or compliance leading to a lack of incentives to prioritize Secure-by-Design?

That is starting to change in some markets as well, most notably in the EU with the introduction of the EU’s Cyber Resilience Act (CRA). This introduces binding law that is applicable prior to products being placed on the market and helps enforce Secure-by-Design/Default principles across the entire product lifecycle.

Some of the key requirements include identifying and mitigating security risks prior to product releases, including secure development practices across a products lifecycle and providing evidence of due care. The consequences aren’t trivial either, reaching as potentially as high as 2.5% of global annual turnover and can lead to market access restrictions, eliminating a vendors total addressable market due to lack of market access.

How Prime Approaches It

To see an overview of how Prime shifts security work to the design stage in practice, where risks actually begin, give it a look below, including their comprehensive context graph and how it enables organizations to mitigate risks at-scale and even autonomously. Security doesn’t have to be reactive and can scale by-design via agentic security architects.

We’ve spoken a lot about concepts such as DSRM, maturity models, and even the regulatory forces at play that are bringing DSRM to a reality. That said, I wanted to take some time to dig into how Prime Security approaches the problem set, and the specific capabilities they provide as well.

Prime aims to cover a variety of use cases, including:

• Discover design risk across all developer tasks

• Automate full security & privacy reviews in under 20 minutes

• Consult with an agentic architect to answer security questions in real-time

• Safeguard AI-generated code with security context

To bring DSRM into fruition for teams, prime works to scan all planned development work and surface insights to security teams proactively, helping highlight potential design flaws and enable secure product releases and catching technical debt before it is accrued.

Historically, security and privacy reviews have been human-centric cumbersome performative exercises, where product teams are forced to come sit and explain things to security. Prime takes an automation-centric approach than acts as a force multiplier for security while streamlining collaboration across teams that often have a friction rich relationship due to the different incentives and focuses of the teams involved (e.g. Development <> Security).

I spoke earlier about how this isn’t a problem we can hire our way out of, especially with security budgets stagnating for many organizations. Prime aims to empower development teams with on-demand security architect agents that can not only accelerate reviews but provide actionable security recommendations before products ship.

Lastly, AI coding tools and agents have seen incredible rates of adoption and not will, but already have fundamentally changed the field of software development forever. Recognizing this, Prime’s approach to securely architecting AI-generated code involved embedding security context directly into popular tools such as VS Code and Cursor via MCP integrations, meeting developers where they work and not disrupting flow while still injecting security rigor into the SDLC via native integrations. This includes surfacing security guidance that is grounded in the broader business requirements, security policies and environmental considerations from the security perspective.

Closing Thoughts

Moving security from being something that was bolted on rather than built-in has been a goal of security for decades. We’ve watched for the last several years as Secure-by-Design was something that felt good for the community to say, but rarely was something that could be implemented at-scale, especially without significant friction on development, engineering and the business.

Now, innovators such as Prime Security are taking us from catchphrase to capability. This includes taking an approach aimed at the era of AI-driven product development, leveraging the same emerging technologies as our peers to drive secure business outcomes. They’re also pioneering approaches as Design Stage Risk Management (DSRM) which have been desperately missing from the industry’s approach to secure system design, development and deployment.

I couldn’t be more excited to watch this new approach to security thrive.

Request a Walkthrough