If you lead security at any organization that ships software, you already know this is not just AI-assisted development but a structural transformation of how software gets built, one is fundamentally reshaping who writes the code, how it reaches production, and what a security review actually needs to cover. All at a pace where developers can now push hundreds of pull requests faster than your security team can review one.

Every transformation of this scale, from open source to cloud to DevOps, has been a defining moment for the security leaders who lived through it. The ones who called the shift early and redesigned their programs around it became the architects of how their companies built security for the next decade. The ones who waited spent that decade catching up. This transformation is no different, except that it is moving faster than any of their predecessors. Securing the Agentic SDLC is not just another item for the roadmap. It is a fundamental rethinking of security for the entire ecosystem, which will define our craft and success for the decade ahead.

What is the Agentic SDLC?

The traditional SDLC followed a familiar chain: requirements → design → implementation → testing → deployment → monitoring. Humans drove every stage. Code was the artifact of human thought, written line by line, reviewed by peers, and shipped through well-understood CI/CD pipelines.

The Agentic SDLC breaks that chain.

In this new model, engineering focus shifts to three core activities:

1. Specifying intent, design, and architecture.

The most critical work in software development is no longer writing code, it’s defining what to build and why. Engineers and product managers spend more time crafting specifications, defining system architecture, and articulating design intent than they spend on implementation. As Anthropic’s report notes, “human expertise focuses on defining the problems worth solving while AI handles the tactical work of implementation.”

2. Manage context and tools. 

Developers now curate the context that agents operate within, and that curation is a craft in its own right. It starts with choosing the right model or agent for each task, defining how it operates, and selecting the tools it gets access to. It extends to configuring MCP servers, building Claude Skills, writing custom system prompts, and maintaining the knowledge infrastructure that lets agents make good decisions. The quality of the output is directly proportional to the quality of the context provided.

3. Reviewing and validating massive volumes of agent output. 

When agents can work for hours or days autonomously, generating entire feature sets or even complete applications, the human role shifts from writing code to reviewing it, evaluating architectural choices, validating design decisions, and ensuring the system as a whole solves the right problems. Anthropic’s research reveals that while engineers use AI in roughly 60% of their work, they can only “fully delegate” 0-20% of tasks. The rest requires active collaboration, supervision, and judgment.

Code itself is becoming a commoditized implementation detail. The real craft, the work that determines whether software is good, secure, and correct, is moving upstream to intent, design, and context.

Three audiences of agentic builders

The Agentic SDLC isn’t producing a single, uniform type of builder. It’s producing three distinct audiences, each with fundamentally different relationships to code, to tooling, and to the enterprise development pipeline. Understanding this breakdown is essential, because each audience creates a different category of security challenge.

Audience 1: Technical builders

These are the professional software engineers who have evolved from writing code to orchestrating agents that write it for them. They are the core of the Agentic SDLC.

In Anthropic’s framing, the engineer’s role has shifted from “implementer to orchestrator.” In 2026, the value of an engineer’s contribution increasingly lies in system architecture design, agent coordination, quality evaluation, and strategic problem decomposition. They shepherd multiple features through development simultaneously, applying their judgment across a broader scope than individual implementation ever allowed.

These builders work in tools like Claude Code, Cursor, and IDE-integrated agents. They express intent, provide context via MCP servers and Claude Skills, review agent-generated output, and ship through standard CI/CD pipelines. Some prompt agents conversationally; others collaborate with PMs and architects on detailed design docs that guide agent behavior.

A growing subset of this audience is going further, adopting spec-driven development, where structured specifications are committed to version control and serve as the primary input to autonomous code generation pipelines. GitHub’s Spec Kit has reached 89.2k stars. The Kiro IDE team cut feature builds from two weeks to two days. AWS engineering teams completed an 18-month re-architecture with six people in 76 days. Spec-driven development is powerful, but it remains an optional adventure at this point, a maturity level that some organizations pursue, not a path most companies will necessarily follow. Whether an engineer prompts an agent conversationally or feeds it a formal spec, the common thread is the same: they are technical builders who no longer write code manually, and whose primary craft has shifted to intent, design, and architecture.

The security challenge here is about scale and context. These builders are 10x more productive, shipping at volumes that overwhelm traditional review processes. And the agents they orchestrate make design decisions without institutional memory, without awareness of trust boundaries, past security incidents, or adjacent system dependencies. The output is technically excellent but contextually blind.

Audience 2: Semi-technical builders

A second, rapidly growing segment of builders are those who aren’t professional engineers but are now producing production code: product managers, designers, data analysts, junior developers. They use natural language, “vibe coding,” the term coined by Andrej Karpathy, to prompt AI agents and generate working software, which then enters the standard SDLC through pull requests.

The pattern looks like this: the builder describes what they want in plain English. Claude or Cursor generates the code. A developer reviews the PR. Tests run, CI/CD deploys, and the output reaches production. It’s an enterprise-guardrailed version of vibe coding, the output enters the standard pipeline, but the person who initiated it may have limited understanding of the architectural and security implications of what they’re shipping.

The code itself is often syntactically clean, AI models are sophisticated enough to avoid the tactical issues that scanners flag. But the design decisions embedded in that code are made by an AI agent operating without organizational context, without understanding of the broader system architecture. Palo Alto’s Unit 42 has documented real-world breaches caused by this exact pattern: a sales lead app compromised because the agent skipped authentication and rate limiting, an AI agent deleting an entire production database despite explicit instructions, authentication bypasses from exposed public IDs. Their root cause finding is that AI models “prioritize function over security” and suffer from “critical context blindness.” An independent scan by Escape.tech of 5,600 vibe-coded production applications confirmed the scale of the problem: over 2,000 vulnerabilities, 400+ exposed secrets, and 175 instances of exposed PII, including medical records and authentication credentials. And these are typically design-level flaws, not syntax errors.

Anthropic’s own research confirms this is becoming mainstream: the barrier separating “people who code” from “people who don’t” is becoming permeable. As their report notes, “coding capabilities democratize beyond engineering,” with non-traditional developers building in fields like cybersecurity, operations, design, and data science.

The security challenge here is about visibility and literacy. The people generating code may not understand what a trust boundary is. The developers reviewing their PRs may be overwhelmed by volume. And the design decisions being made are invisible to any tool that only looks at code.

Audience 3: Citizen developers

The third audience is often the least visible, and introduces a unique set of risks. Non-technical builders across sales, marketing, legal, and operations are using Claude, Lovable, and other no-code/low-code tools to build internal applications, automations, and workflows that never enter the formal SDLC at all.

Anthropic’s trends report confirms this is accelerating: “Non-technical teams across sales, marketing, legal, and operations gain the ability to automate workflows and build tools with little or no engineering intervention.” Zapier has achieved 89% AI adoption across its entire organization with 800+ AI agents deployed internally. Anthropic’s own legal team reduced marketing review turnaround from two to three days down to 24 hours by building Claude-powered workflows. Domain experts implement solutions directly, removing the bottleneck of filing a ticket and waiting for engineering.

Citizen-developed applications break the boundary between corporate security and product security. They operate entirely outside the purview of traditional product security teams. There is no PR to review. No CI/CD pipeline to gate. No design doc to analyze. These applications go directly from business need to production usage, with whatever security posture the AI agent happened to bake in by default. They often handle real customer data, connect to real internal systems, and operate as de facto production software, without ever being seen by a security engineer.

A security mandate that can’t be met

Product security teams were already struggling to keep up with human developers long before any of this started. Backlogs were growing, reviews were slipping, and threat models were going stale faster than teams could refresh them. Now add agentic developers shipping at 10x volume, vibe-coded pull requests from semi-technical builders who don’t know what a trust boundary is, and citizen-built shadow IT that never enters the pipeline at all. This rapidly increases the threat surface, at a pace no human process was designed to match.

Manual review processes, design reviews, architecture assessments, and threat models all remain high-fidelity activities that catch real flaws. But they are fundamentally human-speed processes facing machine-speed output from three different directions.

This is the core tension of the Agentic SDLC: security teams are under more pressure than ever to secure these applications, while also being expected to enable the greatest productivity boost of our generation. Block the agentic pipeline and you block the business. Let it run unchecked and you accept unquantifiable risk.

What security for the Agentic SDLC requires

We founded Clover because the industry requires a fundamentally new approach to software security, one that works across all builder audiences, at machine speed, with continuous understanding of design, architecture, and intent.

Context is the new foundation. In the traditional SDLC, humans carried context implicitly, why this service exists, what data it handles, what the trust model is. In the Agentic SDLC, that context evaporates. AI agents operate without institutional memory, without awareness of adjacent systems, without understanding of past security decisions. Security that doesn’t start with context, deep, architectural, continuously-updated context, is security that can’t function at an agentic scale.

Clover builds a live context engine that fuses product context (what we’re building and why), technical context (how it’s built, what talks to what, where sensitive data flows), and security context (what could go wrong, what’s been reviewed, what assumptions remain unvalidated). It does this by plugging into the tools builders already use: Confluence, Jira, GitHub, Claude, Slack, and continuously analyzing the evolving state of every product and application.

Building an effective context engine is the difference between security agents that spit out AI slop and an effective agentic infrastructure that actually works at scale. With the right context in place, this engine can secure all three builder audiences:

1. Technical builders get fast, high-signal feedback they can iterate on, without the noise of traditional scanners.
2. Semi-technical builders produce higher-quality code with simpler inputs, as architectural context is enforced downstream.
3. Citizen developers can move quickly while staying within company guardrails, even outside the formal SDLC.

The security shift isn’t from scanners to better scanners. It’s from scanning code to understanding context. When code is commoditized, risk moves upstream, into design decisions, architecture, and implicit assumptions agents make without awareness. AI-generated code will often pass scanners while still introducing systemic flaws. The question is no longer simply “is this code vulnerable?” but “did we make the right decisions before the code existed?” Clover operates at that layer, analyzing intent, architecture, and trust boundaries before they become implementation.

Facing the security challenge (and opportunity) of the decade

When your builders adopt something faster than you can govern it, that’s a signal that your security model’s status quo is shifting beneath you. GitHub arrived in enterprises through backchannels years before security teams were ready to bless it. ChatGPT showed up on employee laptops months before most CISOs had an AI policy. Every seismic shift in how software gets built has followed the same pattern: the builders move first, the organization catches up later, and the security teams who treated the shift as a threat to contain ended up running behind the ones who treated it as a shift to secure. The Agentic SDLC is the same pattern, at a larger scale, moving faster.

And the pattern is already playing out. Inside the organizations moving fastest, the Agentic SDLC is not next year’s planning exercise, it’s today’s production reality. Engineers are orchestrating agents. Product managers and designers are shipping vibe-coded features. Sales, legal, and operations are building applications that never touch a pull request. The builders are already speaking loudly, in three different voices, and the security model sitting on your desk wasn’t designed to hear any of them.

Every security leader reading this already has more on their plate than the hours in a day allow. Scanners to triage, vulnerabilities to patch, pen tests to run, compliance clocks ticking. All of it matters. All of it is real. But none of it will define the next decade of product security. This will. The leaders who recognize that first, the ones who stop treating agentic development as a threat to contain and start treating it as the terrain they now operate on, are the ones who will still be leading when the dust settles. The rest will be explaining to their boards why the pipeline got away from them.

The craft of software has moved from code to intent. The craft of security has to follow. Not eventually. Now.

We’ve been building Clover for exactly this future, and we’ll have a lot more to share soon. If you’d like an early look at what we believe security for the agentic era has to be, get in touch.

The post Securing the Agentic SDLC appeared first on Clover Security.

After acquiring three companies in Israel, American software giant ServiceNow is also investing directly in Israeli startups. Calcalist has learned that ServiceNow has invested in Israeli cybersecurity company Clover Security, in a deal estimated to be worth several million dollars.

As part of the investment, ServiceNow is expected to integrate Clover’s technology into its own suite of enterprise solutions and will also become a customer of the company.

Clover was founded in 2023 by Alon Kollmann (CEO) and Or Chen (CPO). The two met in 2022, when Kollmann was pursuing an MBA in France and Chen was completing his tenure at Checkmarx, which had acquired Chen’s previous startup.

Clover integrates AI agents into everyday developer tools such as Confluence, Jira, GitHub, Cursor, and Slack, enabling teams to identify design flaws early and build securely from the outset. Its AI agents replicate the mindset of experienced security professionals, understanding system behavior, predicting where vulnerabilities may emerge, and applying security principles before development begins. As a result, security teams are relieved of repetitive work, and developers receive real-time security guidance inside their existing workflows.

In November, Clover raised $36 million in a funding round led by Notable Capital and Team8. Since then, the company has expanded its operations, signed additional customer agreements, and reached a revenue run rate of more than $1 million per quarter. Clover currently employs around 50 people, most of them based in Israel, with the remainder in the United States.

ServiceNow has been steadily expanding its presence in cybersecurity in recent years, positioning the sector as a key growth engine. The company has previously invested in Snyk and recently acquired Armis for approximately $7.75 billion. It also announced acquisitions of Israeli AI and data companies Pyramid Analytics and Traceloop.

The partnership with ServiceNow is expected to significantly expand Clover’s market reach, giving it access to thousands of enterprise customers worldwide through ServiceNow’s platform.

“ServiceNow is one of the most influential enterprise software platforms in the world,” said Kollmann. “The decision to invest in us and partner with us reflects how the market is evolving. As AI-driven development accelerates, security must be embedded directly into the software creation process, not added later. For us, this is another step toward making this approach the standard in global organizations.”

The post ServiceNow invests in cyber startup Clover Security appeared first on Clover Security.

Today we are proud to share that Silicon Valley CISO Investments (SVCI) has joined Clover Security as a strategic investor. What makes SVCI distinct is not only their track record of successful investments, but their perspective as practicing security leaders. SVCI is a community that brings together dozens of CISOs who protect some of the most complex and consequential technology environments in the world. SVCI members lead security programs for some of the most technology-enabled and forward leaning companies that are rapidly embracing AI-native software development. As early adopters of this shift, they have concluded that … design-led security must be accelerated, iterated and rapidly integrated into the development lifecycle to maintain pace with the way software is being built today. The winners through this era will be those companies that adopt this trend and evolve alongside as the bar continues to be raised on what it takes to earn customer trust.

Why Clover

Across the ecosystem, a clear shift is underway. Security teams are increasingly shifting their focus to collaborating with engineers early in the development lifecycle. The most critical design decisions often take place even before a single line of code is written; security needs visibility and influence into those decisions, to ensure product changes are built securely by nature.

Clover stood out to SVCI not only because of its unique, fresh perspective on the evolution of product security, but also because of its rapid customer adoption and growth, signaling a clear market shift. Customers with advanced engineering stacks or resource constraints are rapidly adopting design-led product security not as an experiment but as a strategic part of how they build software. Together with Clover’s consistent execution, rapid expansion within organizations, and customer feedback, this solidified SVCI’s conviction that Clover is positioned to lead a new category and define how modern software will be secured.

What’s next

With SVCI, Clover gains both strategic insight and direct access to the leaders shaping how security teams adapt to AI-native development. Their experience helps us refine the technology where it matters most, and their network accelerates the adoption of design-led product security across the industry. This partnership strengthens our ability to define new expectations and build the standards that will guide how software is securely designed in the years ahead.

The post SVCI backs Clover Security to empower companies to secure their products by-design, fueled by AI appeared first on Clover Security.

Let’s be honest: it’s become completely impossible to keep up with the progress of AI and how it transforms software development. Every time we think we have a handle on what’s going on, OpenAI or Anthropic releases another model, capability, or way of building apps.

What started with basic code-completion capabilities has now evolved into autonomous agents that act on behalf of developers, generating code and features at an unimaginable speed. But architecture itself is also getting more complex. New AI patterns like RAG, agents, and MCPs are being pushed into existing products before security guardrails and policies are even set. And if that’s not enough, HR and Marketing teams are now spinning up entire products in hours. Everyone has become a builder, and that reality is here to stay.

What this means for security

This new era brings extraordinary innovation but also unprecedented risk. Engineering capacity is multiplying through AI while security capacity has remained largely fixed, and the gap is only widening. When AI agents can generate entire features in seconds, the old reactive security model simply can’t keep pace.

For the past decade, we tried to solve software security by looking for better ways to do reactive scanning. Scanning more, scanning earlier, scanning smarter… “Focus on what matters most”, they said. In theory, it sounded like progress. In practice, we’ve been incrementally optimizing a flawed approach. SAST, SCA, DAST, secret scanners, ASPMs, CSPMs, runtime scanners, reachability, prioritization, and remediation, AI-powered AppSec, agentic AppSec. Different names, different roles – all different flavors of the same reactive pattern. All focused on detecting issues after implementation had been completed and developers had moved on to the next task. We’ve been adding smarter fire alarms to a straw house that keeps catching fire instead of rebuilding with fire-resistant materials.

With AI, it’s even clearer that reactive security is flawed at its core. AI models are continuously improving to the point where they will eventually stop introducing known vulnerabilities altogether. At the same time, AI gradually distances builders from code syntax, intricate implementation details, and focuses their attention on high-level design, specification, and outcome.

In this new world, reactive scanners are simply not enough. Security has to be design-led. It must understand intent, architecture, and system behavior before code exists. Teams don’t need another scanner or a faster workflow. They need a way to eliminate entire classes of issues by addressing them where they start, inside the design process. That’s how security moves at the speed of development, embedded where products begin instead of where they break.

A new design-led mindset

Design-led product security is about making security a natural part of the building process, guiding and collaborating with builders long before implementation begins. Every architectural decision is a potential security decision. Every integration, every data flow, every dependency carries consequences that no tool can “patch out” later. These decisions are being made by developers, product managers, architects, and AI agents – while security teams are not in the room, more often than they are.

Clover was built to live in that creative moment: the earliest conversations, the messy drafts, the evolving diagrams. It was built to bring the security guidance that helps teams reason about security, privacy, and compliance – and influence decision making before those ideas translate into code.

Similar to onboarding a new security team member, Clover’s AI agents start with learning the organization’s context, digging into existing documents and code bases, observing how teams build, and continuously learning from feedback. Finally, they can naturally extend the security team and help them scale manual activities like design reviews, architecture reviews, threat modeling, and more – in ways that were simply not possible before.

Scaling product security with context

We believe security should scale at the speed of innovation. That means:

Starting with context. Understanding architecture, intent, and system behavior before anything is built, so security becomes part of the design conversation, not the post-mortem.

Meeting builders where they are. Inside the tools where ideas are captured, designs evolve, and code takes shape, including Confluence, Jira, GitHub, Cursor, and Slack.

Designed for scale. Scaling secure design means operating in complex enterprise environments, with varying technologies, processes, and cultures.

These are the design principles that guide every feature and use case we build at Clover. They didn’t come out of creative brainstorming sessions, but from hard lessons our team learned over the past decade building application and cloud security solutions at places like Microsoft, Checkmarx, and Dazz (acquired by Wiz).

We learned through hard lessons that product security cannot be reactive. It must be proactive.

It’s become clear to us: good product security is when builders don’t feel you slow them down. Great product security is when builders want to pull you into the room, not because they have to, but because you make their product better.

Looking ahead

We’re proud to see Clover powering teams that are building some of the most advanced products in the world – across financial services, enterprise software, and consumer applications. Our mission is simple but transformative: make software products secure by nature.

As AI reshapes how software is built, we’re redefining how it is secured. Because in the AI era, the most powerful way to make products secure isn’t to react faster, it’s to design smarter.

The post Introducing Clover Security: Design-led product security for the AI era appeared first on Clover Security.

I’m excited about what AI can do with regard to product security. Google has been around this space for a long time and yet, we still have the same issue of scale: There are simply never enough security engineers. You could give me a thousand more security engineers, and I still wouldn’t be able to cover everything that I’d want to cover. But AI changes all that, particularly in the product security space, because it can be present all the time and do it at scale.

Traditional tools are very good at identifying issues, but ultimately, that breaks down when the suggestion just ends up sitting in a queue for some developer to go and manually fix. The ability for AI to not only identify the issue, but then actually go and fix the issue, is a gamechanger and very scalable.

Another point is that AI can be there all day, every day, and more critically, built directly into automation workflows. Many processes today are asynchronous: They rely on the security engineer being available and to assist in a consultative type role. That role really ends up being a Monday-to-Friday type of job. If you have an AI that’s integrated into your CI/CD pipelines, it’s present all the time, and a built-in part of the continuous flow.

Product security vs application security

In traditional application security, legacy tools such as SAST or SCA, scan the products and then they create a backlog of issues that have to be remediated, all of which happens outside of the development process. The teams developing products are going through the build process, doing beta releases, and working on getting that product to market. Product security thinks about it much more holistically.

Product security looks at the purpose of the product and sees it as a business problem to solve. It’s about being involved in the holistic process of building a product so it’s much more integrated and focused on realtime.

There is a transition that has to take place between the AppSec model and the product security approach. How do we move security engineering teams from being blockers to actually business enablers? How do you actually understand where your product teams are? What are their business objectives? How do you fit into all that and ensure that you’re adding momentum to the business, not taking it away? How do you move from being the team that says “No” to the team that is figuring out ways to say “Yes”?

AI is already being used significantly for code development and product development, and that’s pretty exciting. We’re nearing a world where we are going from having “software engineers” to having “software designers.” It’s a world where a developer turns to LLMs to take a prompt to build an application that solves a certain problem, describing how the user interface should look, providing the data sources. That’s where design-led product security is important. It takes those inputs from the developer and applies the proper security policies and security guardrails automatically. It finds the secure ways to access that data source the developer wants to use, whether it’s by using a specific connection method, or a type of encryption, or any other rule that the product security team has codified.

How do we describe in language that AI can use and apply our security guardrails, our security principles, our known vulnerabilities? That last part about known vulnerabilities is really critical, because AI allows us to also understand where our developers are making mistakes, where the failure patterns are, and then actually catch those patterns and describe them as patterns, and ultimately correct them.

The well-lit paths of building secure by design

At Google Cloud it’s very important for us to include security at the design level. We’ve recently signed on as part of the US government’s Secure by Design Pledge, but frankly, we’ve been doing security by design for a very long time. It’s an expectation, a very reasonable expectation, of our customers. The question is simple: How do we create well lit paths for our developers to do the right thing?

We look at it through a number of ways. One of those ways is by directing our partners and developers towards the well-lit paths: Use this library, use this framework, use this vendor, and you’re going to get all of the security that you need for free. You don’t actually need to devote more time to thinking about it. It takes out the friction and makes things much easier.

The second thing is making sure that devotion to security by design is expressed to customers. Sometimes, the customer needs to make a choice. Large enterprises have their own needs, and it may not be clear to them what they need to be able to do in order to become secure by design. That’s why one of the things that we will do is make deliberate choices about default settings. Should we apply the secure by design default which is more secure, and then allow the customer to disable that security setting if their use case requires them to be less secure, say as for integrating with a legacy application. That’s also why we work very closely with our development teams to have the product shipped in a more secure state, while giving the customer the awareness that, if necessary, they can back that off.

These are examples of very conscious choices and well-lit paths. It’s really more a question of how far we can go with this approach.

How Clover is changing product security

As a product security leader, my challenge has always been how to scale and how do I get deeper into the product space, even to the point where our customers are. A major obstacle is that there’s just never enough security engineers. Taking an AI driven approach is an exciting opportunity in this regard, because AI allows scale and increases productivity. And Clover helps do that.

The post Iain Mulholland, security leader at Google Cloud, on product security in the AI-native era appeared first on Clover Security.

The concept still matters: security should be built in, not bolted on. Yet many of the practices labeled as secure by design are quite literally bolt-ons that come into play later in the SDLC, rather than true design commitments made upfront. To attain secure by design we need to lead with design not just work back from CVEs and vulnerabilities to define tactics.

In this article, we’ll give an overview into secure by design as it exists today, its challenges and how we as an industry can reframe the principle to create a roadmap to successful adoption and implementation.

Where secure by design drifts from design

CISA’s position in Shifting the balance of cybersecurity risk: Principles and approaches for secure by design software is that vendors should take responsibility for customer security outcomes and ship products that are secure to use out of the box. Secure by default is the companion idea: strong protections should be enabled without extra cost or complex configuration. The message is blunt: the software industry does not need more security products; it needs more secure products.

The secure by design initiative sets the right tone and direction for accountability, transparency, and leadership, but most of its principles and tactics sit outside the actual design phase of software development. Executive sponsorship, metrics, SBOM sharing, and public reporting all shape how an organization behaves, but they do not tell software builders what to design. They are organizational and operational guardrails, not design and planning practices.

The real design layer is tangible. It includes design and architecture reviews, secure patterns and paved-road, threat modeling, security frameworks and requirements, all addressed before a line of code is written. This is where security and design actually intersect.

Bringing order to the secure by design chaos

If secure by design is to be actionable, it needs to be specific and concrete. The term has grown so broad that it can cover leadership buy in, threat modeling, and everything in between. There is a suite of related terms at our disposal to tighten up secure by design. Namely, secure by design, secure by default, design security, and secure design. Unfortunately they are often mixed up or misapplied, and at this point barely anyone understands their differences.

Here’s a quick breakdown of the differences between them all:

• Secure by design is the philosophy. It’s the idea of systematically integrating security into every aspect of software development: architecture, requirements, development, deployment, and maintenance. It is the broadest and most comprehensive term here.
• Secure by default is a principle that says the product should ship with safe defaults, making the secure choice the easiest and the insecure choice the intentionally explicit one.
• Design security is the general practice of considering security during the design phase. It is broad and not tied to a methodology or philosophy.
• Secure design is the outcome designs that already incorporate specific security controls to address risks that were identified.

As an industry we have spent years focused on the philosophy, the ideal of what secure by design should be. But philosophy does not make software safer. Without practices, measurable outcomes, and principles that guide design and security decisions, the concept stays abstract and aspirational. Making secure by design real means moving from intention to implementation, from stating what we believe to building what we can prove.

Design security is no small feat

Embedding security at the design stage sounds elegant but proves difficult in practice. True design security requires time, information discovery, domain specific skill, collaboration, and a culture where engineering, product, and security teams are aligned on priorities.

Developers describe impossible tradeoffs between release velocity and secure architecture, management using “shift left” as a cost-saving slogan, and offshore teams working under time and skill constraints that make structured design reviews unrealistic. Others point to a skills gap: few developers are trained to spot subtle logic flaws or unsafe assumptions at design time, and those few product security experts who can are not always brought in early enough or overruled in light of delivery deadlines.

According to CrowdStrike’s 2024 State of Application Security Report, 54 percent of organizations admit that fewer than half of their code changes undergo any form of security review before release. Seventy percent say it takes 12 hours or longer to resolve critical vulnerabilities once discovered. That delay reflects how reactive most programs remain. Security still enters the process too late, and even when design reviews happen, they often give way to speed-to-market pressure and fragmented ownership.

Design security demands more than intention. It requires time to explore misuse cases, authority to challenge feature requirements, and a baseline of engineering maturity that allows teams to integrate security decisions without grinding development to a halt. The problem is not that teams disagree with the concept of secure by design, but that few have the margin, structure, or skills, at scale required to make it real.

The secure by design challenge just became exponential, but there’s a silver lining

Unless you’ve been living under a rock, it should be no shock that the state of vulnerabilities is only getting worse. Disclosures keep rising year over year, and that is only what we’re aware of at the moment. Organizations already struggle to triage, prioritize, and patch at the pace issues appear, leaving a growing backlog.

This was a growing problem back when we were just talking in terms of good old fashioned human developers and bad actors. Now AI-native development is accelerating velocity across the board, so the problem is compounding. The existing backlog remains, the pressure to patch and prioritize persists, and we are generating more code faster than ever. Not to mention the fact that bad actors are increasingly leveraging LLMs to both discover new attack vectors but also as a new attack vector in its own right.

There is a silver lining. The same AI that is jet propelling development can be applied to the bottlenecks above: it can close skills gaps with just-in-time design reviews; auto draft and sanity check threat models and architecture reviews; flag unsafe patterns and dependency risks before code merges; generate paved roads and secure default configs; triage the flood of potential risks and threats so humans focus on the highest impact work; and automate design security workflows for both human in the loop security reviews and direct to developer with copilots that provide expert security guidance and safe code suggestions. Used this way, AI amplifies scarce expertise, turns design context into consistent security artifacts, and quantifies previously qualitative design risk across products.

What’s next for secure by design?

This article sets the foundation for how we think and talk about secure by design. We unpacked the confusion around the term, examined CISA’s framing, and argued that most of what is called secure by design today happens after design is finished.

In the next posts of this series, we’ll dive deeper into the secure by design progression we laid out earlier and explore each layer in depth to provide an adoption and actualization roadmap, starting with design security.

The post Secure by design: a mantra in search of meaning appeared first on Clover Security.