AI hasn’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’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—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 “Product Security,” 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’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’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 “Jeremy Bearimy.”

This is our SDLC now. The “design phase” 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 “before deploy” 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 “i.” 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 “slower” 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—agents simply adapt to what requirements we’ve provided them and build to the desired spec.

What We’re Doing About It

If there’s no simple stream to anchor against, security can’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’re not here to create findings, reviews, or tickets—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 correct we are. It’s the age-old saying: if we discover a finding in a forest and nobody is around to fix it, did we produce any value?

Every time we push a requirement onto people—whether through mandates, gates, or chasing tickets—we spend some of the trust we’ve accumulated. No one enjoys the security department that continually berates them. We should instead build a program that acts like the tides—producing continuous motion even when the moon is not directly exerting force on the waves (allow me this imperfect simile). Before we can effect technical change, engineering and the business have to come with us as stakeholders and collaborators.

A program that pulls is one with tools people reach for because they’re better, and guidance people seek out because it’s useful. That program earns trust with every use. This is the test we are taking to every program and idea we create moving forward: can the business pull it, or are we going to have to push it out?

Of course there are times where we have to push. We still track vulnerability tickets in our security debt program and hand teams tickets they must fix. However, the methods we employ must prioritize stakeholder collaboration and engagement.

While we record vulnerability tickets, our security debt program allows roadmap owners to determine when they can best resolve the ticket within a contextual, flexible resolution period. Those product decision makers get a single metric from security encapsulating their posture and they can pull that information into their prioritization planning. They do not need to get permission from security to delay a ticket or reschedule their roadmap. We don’t rely on a risk register that makes a VP sign off before a ticket can wait another year, or on one-size-fits-all deadlines. Yet our tickets get resolved on timelines appropriate to their risk.

Building programs that pull does not mean foregoing any aspect of accountability or responsibility. Instead, it requires a mindset shift in how security delivers the outcomes you want to achieve.

Mandates For Agents Are Good, Actually

Agents change the push-versus-pull contention. Pushing a requirement onto an engineer spends trust. Pushing one onto an agent costs almost nothing because the agent adjusts and keeps going. We can prepare security instructions, skills, and plugins that agents will dutifully pull in and consume, and hooks that block an agent from routing around a requirement that isn’t optional. A secure design pattern on a wiki page or a threat model attached to a closed review ticket won’t enter an agent’s reasoning unless the engineer prompting the agent already knows about them.

We are focusing on rebuilding our knowledge artifacts so agents can consume them without pushing out requirements onto developers. This includes our baseline security requirements, the patterns our Secure Design team creates, the threat models we maintain for each product, and the bug classes our bug bounty security researchers report.

Consider the simple example of an engineer who asks her agent to let customers register a webhook URL for resource monitoring alerts. Without security-provided context, the agent may write code that accepts a URL and sends it a POST request. Unfortunately, it creates a server-side request forgery (SSRF) vector as well. Under prodsec-derived plugins and hooks, the agent recognizes that the feature is making a server-side request to a destination the customer controls, so it pulls in our resources to learn how we want this class of problem handled. The agent can effectively translate our high level guidelines into practical steps for this particular product without requiring a meeting with the security team. It designs the feature to route requests through our approved pattern for outbound calls, blocks internal and link-local addresses, re-checks the destination after DNS resolution and denies redirection, signs the payload, and writes regression tests to ensure the security checks don’t accidentally disappear.

The engineer never had to know to ask and our security team did not need to find time to deep dive with the product team. Our goal is to free our security engineers’ time and energy to focus on our most important and complex projects without concern that other initiatives will lack security design input.

Agentic Development Doesn’t Change the Fundamentals

All that being said, none of this upends the last decades of secure software guidance. We’re fans of some of the newer concepts such as the Agents Rule of Two, but the OWASP Cheat Sheet Series remains as relevant as ever. Discussing least privilege architecture concepts with your engineering department, and providing those guidelines for agents, will continue to pay dividends.

In recent months, various news stories have shown several AI agents escaping their sandboxes, and in some cases causing damage depending on what they could reach when they got out. In the last few weeks, we had a sandbox escape of our own. A security research firm reported through our bug bounty program that they found a method to break out of a sandbox in one of our AI products and run commands inside the serving environment. However, as a result of the system architecture designed by our Secure Design team, based on our investigation, this did not result in any expanded impact and we could simply treat it as hardening cleanup. After the security researcher escaped our sandbox, they found themselves unable to pivot their access beyond what they could already do as a DigitalOcean customer. They found credentials outside the sandbox, but they were scoped only to the cloud resources the researcher had chosen to connect.

The issue is subject to coordinated disclosure with other affected providers, so we are limiting details for now and plan to share more after the public disclosure date.

Our Secure Design team had worked during the product development to architect the serving environment as untrusted from the start. Adopting the philosophy of “assume breach,” we assumed a customer might eventually break out of this sandbox and designed the environment to maintain our security boundaries even in that circumstance.

The storage credentials are read-only and scoped to what the customer already controls and elected to connect to the environment. The compute they found themselves on was single-tenant, provisioned for that customer alone. Should they have tried to act like an abusive actor, the activity would be connected to their account. The researcher got root in this environment and, per our investigation and their analysis, found nothing we hadn’t already intended for them to control.

Of course, escaping the sandbox is still a bug so we patched the vector they used. Our security design enabled us to do that routinely, as part of bugfixing and operational upkeep, instead of as a security incident. Least privilege and assume breach are decades-plus old principles.

Agentic development hasn’t changed these fundamentals; it has changed how we deliver them, which is now through the context our agents pull.

Accelerating To A Good Place

A Jeremy Bearimy SDLC means security cannot rely on specific engagement phases with product teams, as that operating model no longer exists. The most effective way to influence secure outcomes remains traveling with the work—building context agents can pull in and guardrails that they can’t route around. Directing the agentic chain-of-thought to secure code at the point of generation. Our job is to make that context good enough that engineers and their agents reach for it, and to put the gates on agents instead of on people. Underneath that, we ensure our products get designed with secure fundamentals so that when the next vulnerability occurs, we limit its impact on our customers, our business, and the wider Internet. That’s the standard we hold ourselves to for customers running AI workloads on DigitalOcean.

Thank you to Nielet D’Mello, Staff Product Security Engineer, and Tim Lisko, Deputy CISO, for providing feedback on drafts of this article.