Software security must adapt for the AI era

Generative AI has created a security crisis of scale. It is also the most significant opportunity we have faced in three decades of internet innovation. Every new era of connectivity has made us rethink what resilience means, and this one is no different. AI-generated code brings new complexity, and it also gives us the tools to build security that is more pervasive, proactive, and precise than before.

We are moving beyond the manual security gates of the past. We now use AI to analyze code with unprecedented depth. We have already operationalized a capability like this through our open-sourced Foundry Security Spec, an offensive security harness specification. The more critical shift is in how software is engineered. Product managers, architects, and engineers now use AI agents to draft requirements and generate code in real time. That velocity renders traditional manual security gates obsolete. To stay secure from ideation to release, we must build security directly into the DNA of agentic workflows.

There are no victory laps in security, and this post isn’t one. Some of what follows is running today. Some we are still building. Our intent here is to be clear about which is which.

CSDL continues, and does more

The Cisco Secure Development Lifecycle (CSDL) is built on more than 400 software security requirements that validate products before they are released, with engagements at key stages of development. It has been a core part of how Cisco develops software for over 15 years and a key reason customers have found Cisco software trustworthy. As software development changes, CSDL must change with it.

Evolving CSDL doesn’t mean replacing it. The security bar stays where it is. What changes is how requirements are represented and delivered: they become more atomic, machine-readable, and contextual, so engineers and AI agents can both act on them directly. That lets us do considerably more. We can engage at more points in the development lifecycle, apply requirements more consistently, examine designs against a wider range of threats, and gather evidence continuously instead of only at the end. The result is highly secure software, delivered with more confidence and speed.

It also needs to continue to fit the broad diversity of software Cisco builds, from network infrastructure operating systems to software-as-a-service products to enterprise applications. Agentic engineering is a first-class path in CSDL, not an exception.

Agentic engineering

Requirements only protect a product if they are implemented. As Cisco increasingly uses agentic engineering techniques, agents need to help engineers meet the requirements. We are using agents within the evolved CSDL in two ways: carrying requirements into key phases of development and enforcing them at the gates and continuously assessing the software as it is built.

Agents and agent skills apply those constraints across the lifecycle, and what they supply changes with each phase.

Project CodeGuard is in use today. Cisco open-sourced it and donated it to the Coalition for Secure AI (CoSAI). It supplies rules and skills that steer AI coding agents toward safe patterns. We have been applying it internally across the Cisco ecosystem.

Our secure software guidance skill is in development, carrying Cisco-specific security requirements into the development workflow. When a product manager writes a Product Requirements Document (PRD), it determines the right intersection of security with what is being built and puts applicable requirements into the document. The engineer who uses that PRD to author the product’s spec inherits the security requirements rather than hunting for them. As the spec is written with an AI coding agent using secure software guidance skill, it brings the requirements through so that the spec describes a more secure product. The same happens at each subsequent phase in the development process. The final security of the product is improved twofold: by inheriting constraints from the prior phases and by the agent skills operating at the current phase. This approach also minimizes the impact on the context window of the coding agent.

Project CodeGuard and the secure software guidance skill also act as evaluators in the development pipeline, backing hard gates. The requirements that shaped the work are the ones enforced before anything ships.

We are also building agents that complement them by assessing the software as it is built. The automated security evaluation agent (ASE) examines a codebase the way a human assessor would. It builds a threat model, works out which security requirements apply given the system’s architecture and trust boundaries, then checks the source for evidence that those requirements are being met. It doesn’t review a single change. It assesses the system those changes produce, and updates as the code shifts. Every threat it reports carries the source that supports it.

We feed this code-based view into another agent that pulls in contextual information: PRDs, design review documents, architectures, threat models, test results, and any other information that builds a holistic security context. Like ASE, it updates its articulation of the risk as the context changes. Automation proposes findings, and a named reviewer decides which apply. Their corrections persist as the context changes. Assessment moves from a one-time snapshot to a living, evidence-based view of each product’s posture, and work that once took 40 to 80 hours of manual review now runs continuously.

While these agents and skills naturally fit with agentic engineering, they work with more traditional engineering methodologies as well.

What ongoing analysis teaches us

Our always-on offensive security harness has identified many findings, which drive the find-and-fix motion that hardens our software. The more valuable output may be the whole corpus of data. It includes not only the vulnerabilities found but also where our defenses held. We use it in three ways:

1. We harden designs, not just code. Findings update threat models and architectures, deepening defense in depth. Increasingly, we refactor a component or rewrite a codebase outright to remove a category of risk at its root, which was not economically viable before AI.
2. We improve how requirements are expressed. To date we have not found a novel issue that was not already covered by an existing software security requirement. We examine the corpus anyway, looking for requirements that are correct but harder to satisfy than they need to be.
3. We tune the pipeline. The corpus lets us calibrate deterministic tooling, such as static analysis, to reduce false positives. The signal engineers act on should be worth their attention.

This creates a loop, and intelligence flows back into the DNA of CSDL. When we identify a new class of risk, we don’t just patch the vulnerability. The finding leads to a new requirement, skills that provide phase-appropriate constraints, or a coded pipeline check. By turning every discovery into a preventative constraint, we aim to stop finding these issues at all, because our agents stop writing them in the first place.

Always-on assurance

The agentic CSDL holds a live understanding of the requirements, threat model, code, and test results. That sustains an always-on risk posture rather than a milestone snapshot. Evidence is gathered automatically as a by-product of the work, so engineering teams spend their attention on writing secure software rather than documenting that they did.

Threat modeling widens too. The objective is not only to confirm that known threats are handled, but to broaden the range of threats considered. That covers what we have bundled into our products, namely third-party and open-source components. The risk posture is available on an ongoing basis to the security team, so we can give clear guidance and direction to product managers and engineers.

The foundation remains, and what comes next

Methods change quickly. Our core CSDL principles do not.

• Security and privacy by design: threat modeling, layered defenses, and privacy engineering are built into the architecture from the start, not added later.
• Beyond secure by default: products ship secure out of the box with no insecure capabilities at release, and we remove any that later prove insecure. Customers never need to change settings to be secure.
• Software supply chain security: we know and trust what goes into our products. Third-party components, build systems, signing, and delivery are protected end-to-end.
• Hardened foundations: products are built on a secure baseline using hardened operating systems, strong cryptographic protocols, secure boot, and a verified chain of trust.
• Continuous validation: code review, testing, and compliance checks run throughout development and passing them is a mandatory gate before release.
• Continuous improvement: we close the gaps in requirements, data, tooling, and process that allowed incidents and exploits; we eliminate the whole class of weakness, not only the instance.
• Rapid remediation: we fix vulnerabilities in supported releases quickly and deliver fixes to customers through secure update mechanisms.

We are describing this in detail on purpose. Every organization building software faces the same problem, and it benefits everyone when others adopt our approach rather than start from a blank page. That is why Project CodeGuard is open source and with CoSAI, why Foundry was published as a specification rather than a tool, and why we describe our secure software guidance skill and our software security agents, even though the implementation stays internal.

For our customers, the commitment is unchanged: the software we ship meets a defined and enforced set of security requirements. What’s new is that those requirements reach the moment each decision is made, the evidence is continuous, and the results keep improving as the loop keeps turning. We aren’t finished, and we’ll keep sharing what we learn as it develops.