Product Security in the Post-AI Era

Product Security in the Post-AI Era | DigitalOcean

© 2026 DigitalOcean, LLC. Sitemap .

Trust & Security

Product Security in the Post-AI Era

By Ari Kalfus

Director, Product Security

Updated: October 21, 2026 10 min read

<- Back to blog home

AI hasn&#x2019;t changed what secure software looks like, but what has changed is almost everything about how software gets built. Security programs designed around old processes are anchored to points on a lifecycle that no longer exist. Last month, DigitalOcean&#x2019;s Product Security team held a workshop to work through what that means for us.

Our discussion centered on what the post-AI software development lifecycle (SDLC) changes about the practice of producing software&#x2014;the content in this article is taken from that workshop. We affirmed that the outcomes and protections necessary to secure software in years past all still apply today. What changed is the practice of how we produce those protections. AI has upended the traditional SDLC, but the fundamentals remain crucial to get right.

What is Product Security?

Product Security and Application Security both suffer from unclear definitions. Any company can put different responsibilities together and call it &#x201c;Product Security,&#x201d; so let me define our program. Product Security at DigitalOcean is responsible for the security of the products we build and the ways in which we build them.

That scope runs from the design of a new feature, through the code, dependencies, people, processes, and pipelines that produce it, to how it holds up once security researchers and attackers get their hands on it.

Our mission is to minimize security risk and maximize business velocity through three functions:

The Secure Design team de-risks products early with architecture review and threat modeling.

The Security Platform team builds security into the tools engineers already use, so the secure way to build is also the easiest.

The Offensive Security team validates our work with external researchers who continuously test our products via our bug bounty. We also partner with external firms for specialized security testing.

Any findings we identify across our program are communicated through one measurement we call security debt . As a cloud provider, our threats fall into three general categories: risk to our customers, risk to our business, and risk to the wider Internet community.

Yesteryear&#x2019;s SDLC Is Gone

While our mission and priorities as a product security program have not changed, the way software is built has changed massively. The SDLC has gone through various iterations but has essentially remained a stable, phased path: requirements, design, build, test, deploy, operate. Agile teams likely test while they build and iterate on requirements and design as their build fleshes out, but teams can point to these phases and, particularly, security can anchor at one or more points along the lifecycle. We can shift left , right, out, in. These all suppose there is a line to shift across.

Traditionally, our program followed this same model. Secure Design engaged in architecture design early. Security Platform added tools and libraries that engineers could use as they built and introduced controls on the deploy pipelines. Offensive Security validated what launched in production. However, with evolving technologies and methodologies, product development no longer follows this course.

The Jeremy Bearimy SDLC

However the industry shifts over the next few years, I do not believe the SDLC as we knew it will be returning. Instead, the next few years of software development are going to look like what I&#x2019;m calling, inspired by The Good Place , the Jeremy Bearimy SDLC.

In the show, there is a scene about how time flows in the afterlife. Instead of flowing in a straight line, it runs in a loop. It crosses back on itself, it flourishes and winds around. Ultimately looking somewhat like someone signing their name &#x201c;Jeremy Bearimy.&#x201d;

This is our SDLC now. The &#x201c;design phase&#x201d; occurs in a prompt at 11 PM when someone is suddenly struck with an idea and begins brainstorming . An agent opens four PRs before the morning standup, or fully merges the code after the automated test suite and review council of agents approves the change. Deployments, which we already were performing multiple times per day, are now close to continuous, so a test phase &#x201c;before deploy&#x201d; is now counted in minutes. Work that used to happen after the build sometimes happens before design, because an agent wrote the implementation first and someone reverse engineered goals and requirements from it. And security, more often than not, is stuck at the dot over the &#x201c;i.&#x201d; Still trying to attach to a fixed point while the development stream flows along without them.

This might feel overwhelming, and security programs may feel that this is inherently less safe than &#x201c;slower&#x201d; approaches. There is data supporting both sides of that argument. What I will say is this paradigm does not have to intrinsically increase risk or reduce safety. It requires security programs to stop obstructing people. Ironically, it also makes room for mandates and gates again, as long as they apply to agents. The more options we were able to provide developers in the past, the more they were able to accomplish. The more options we provide agents today, the more disjointed every product becomes. Employing opinionated defaults and blocking agents from going around them no longer has the side effect of slowing developers down&#x2014;agents simply adapt to what requirements we&#x2019;ve provided them and build to the desired spec.

What We&#x2019;re Doing About It

If there&#x2019;s no simple stream to anchor against, security can&#x2019;t wait at one. We have to travel with the work. Across the three teams that make up our product security department, I tell folks that while we are here to minimize risk and maximize velocity, what we fundamentally sell to the rest of the business is trust.

This may surprise some readers. We&#x2019;re not here to create findings, reviews, or tickets&#x2014;our purpose is to develop trust. If engineering teams cannot trust our guidance, they will not follow it. If the business cannot trust our warnings and escalations, it will not act on them. And when that happens, everything downstream of us is dead on arrival, no matter how technically...