SSDLC Checklist for AppSec Teams (September 2026)

Let's be honest, your developers are probably moving faster than your security reviews can keep up with, and AI coding agents are making that gap wider. The good news is that shifting security left doesn't mean slowing anyone down. It means giving every phase, planning, design, coding, testing, deployment, and maintenance, its own clear set of controls so nothing falls through.

TLDR:

• Fixing a bug in production costs up to 100x more than catching it at design, per commonly cited industry estimates
• Your secure SDLC checklist spans 7 phases: requirements, design, coding, testing, deployment, and maintenance, each with specific security gates
• AI coding agents (Copilot, Cursor, Claude Code) show a 25.7% vulnerability rate across tested samples, requiring security controls at the generation layer, before a PR exists
• The OWASP Top 10 for Agentic Applications maps 10 AI-specific risks (Agent Goal Hijack, Tool Misuse, Identity Abuse, Agentic Supply Chain, Unexpected Code Execution, Memory and Context Poisoning, Insecure Inter-Agent Communication, Cascading Failures, Human-Agent Trust Exploitation, and Rogue Agents) directly to SDLC phases, and most are invisible to traditional SAST tools
• Arnica governs the Agentic Development Lifecycle by enforcing security rules inside agent config files, running pipelineless SAST and SCA, and routing findings to active code owners in cases where 82% of findings point to developers who have already left

Why Security Must Live in Every SDLC Phase

The math on late-stage security fixes is brutal. Commonly cited industry estimates put the cost of a bug caught in production at up to 100 times more than the same defect found during design. The further a vulnerability travels through the pipeline, the more expensive and disruptive it becomes to resolve.

Treating security as a final gate means paying the highest possible price for findings that could have been caught in a design review. A structured checklist changes that calculus by giving every team clear security actions at each phase, before fix costs compound. See our secure SDLC policy guide for security leaders for the full framework.

Secure SDLC vs. Traditional SDLC

A traditional SDLC is a sequential process: plan, design, build, test, deploy. Security shows up late, usually as a pre-release scan or a pentest after the code is already written. The Secure SDLC (SSDLC) rejects that sequencing entirely.

In an SSDLC, security requirements are gathered alongside functional ones, threat models are produced during design, code is written against secure coding standards, and application security testing runs in parallel with functional QA. Security is an input at every stage, not a gate at the end of the pipeline.

The difference shows up in cost and timing. Traditional SDLC teams find vulnerabilities after the architecture is set and the code is committed, when changing anything is expensive. SSDLC teams catch the same issues when a design decision can still be reversed in a whiteboard session, before a single line of code exists to refactor.

Key Frameworks That Define Secure SDLC

Four frameworks dominate how organizations structure a Secure SDLC, and each fits a different context.

NIST SSDF (SP 800-218) organizes secure development into four practice groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. A Version 1.2 draft published in December 2025 updated guidance for AI-generated code. It is the default reference for US federal contractors and industries under strict compliance rules.

OWASP SAMM is a maturity model built around five business functions: Governance, Design, Implementation, Verification, and Operations. Teams score their current state and use the gap analysis to build a roadmap toward measurable, incremental improvement.

The Microsoft Security Development Lifecycle was one of the earliest formalized SSDLC models, built around mandatory security training, threat modeling, attack surface analysis, and a final security review before release. It remains a practical reference for product teams outside the Microsoft ecosystem.

ISO 27001 Annex A.8.25 requires secure development lifecycle controls as part of a broader information security management system. Organizations pursuing certification must show evidence of security integrated across development phases, making it a governance anchor for teams operating in European or enterprise procurement contexts.

Phase 1 and 2: Planning and Requirements Security Checklist

Security work that happens before a line of code is written has the highest impact of any phase. Getting requirements wrong here means every subsequent phase inherits the gap.

• Define security requirements in the same backlog as functional requirements, not in a separate document nobody reads
• Identify applicable regulatory constraints: PCI DSS, HIPAA, SOC 2, GDPR, or sector-specific mandates
• Classify the data the system will handle and assign a risk tier to the project
• Document security acceptance criteria that the release must satisfy before shipping
• Identify third-party dependencies and external integrations that will need supply chain review
• Assign a security owner for the project at kickoff, not after the first pentest finding
• Confirm that the team has completed relevant security training for the tech stack in scope

The acceptance criteria item is worth pausing on. Teams that skip it have no agreed definition of "done" on security. Without explicit criteria, security review becomes a negotiation at the end of the project when nobody wants to delay the release.

Phase 3: Secure Design Checklist

Design is where the cheapest security decisions get made. A threat model produced here costs a few hours; the architectural change it prevents could cost weeks.

• Conduct a threat model using STRIDE, DREAD, or PASTA before architecture is finalized
• Document every trust boundary in the system and specify how each is enforced
• Apply least privilege to every service, role, and API connection by default
• Design for defense in depth so no single control stands between an attacker and sensitive data
• Separate environments at the architecture level, beyond configuration alone
• Identify all external attack surfaces and document how each is protected
• Define authentication and authorization models before implementation begins
• Confirm that sensitive data is encrypted at rest and in transit in the design spec
• Flag any third-party or open-source components and require a supply chain review before approval

Set a design review gate: no component moves to implementation if unmitigated high-severity threats remain open. Without it, threat model findings become a suggestion instead of a blocker, and developers inherit unresolved architectural risks on day one.

Phase 4: Secure Coding Checklist

Developers write code fast. Security standards only hold if they are built into the workflow, not bolted on as a review comment after the PR is open. Building a developer-native AppSec program keeps standards enforceable without slowing engineering.

Input Validation and Output Encoding

• Validate all input server-side regardless of client-side checks
• Use allowlists over denylists for input validation rules
• Encode all output data before display to prevent XSS
• Parameterize all database queries; never concatenate user input into SQL strings

Authentication and Session Management

• Enforce MFA on all privileged and externally exposed accounts
• Generate cryptographically random session tokens and invalidate them on logout
• Set secure, HttpOnly, and SameSite flags on session cookies
• Implement account lockout after repeated failed authentication attempts

Access Control

• Enforce authorization server-side on every request, including below the UI layer
• Default to deny; grant permissions explicitly and minimally
• Verify object-level authorization before returning any resource by ID

Cryptography

• Use vetted libraries only; never implement custom cryptographic routines
• Use AES-256 for data at rest and TLS 1.2 or higher for data in transit
• Rotate cryptographic keys on a defined schedule and after any suspected exposure

Error Handling, Logging, and Secrets

• Return generic error messages to users; log full details server-side only
• Never log credentials, tokens, or PII
• Store secrets in a secrets manager; never hardcode them in source or config files
• Scan commits for secrets before they merge

Phase 5: Security Testing Checklist

No single test type covers the full attack surface. Each method catches a different class of risk, and gaps appear when teams treat them as substitutes instead of complements.

AI SAST runs without executing code, fitting early in the pipeline. DAST requires a live application, so it runs later. SCA and secrets scanning are fast enough for every commit with no meaningful latency cost. IaC scanning belongs alongside code review, not as an afterthought before deployment. Penetration testing is the one test type that cannot be automated away. Run it annually at minimum, and after any major architecture change.

Phase 6 and 7: Deployment and Maintenance Security Checklist

Before any build reaches production, run a final sweep against these controls:

• Complete a SAST and DAST pass on the release candidate, not the development branch
• Confirm all high and critical severity findings are resolved or formally accepted with documented rationale
• Run SCA against the production dependency manifest and block on any newly published critical CVEs
• Verify no secrets exist in environment configs, CI/CD pipeline variables, or container images
• Review infrastructure-as-code against your security baseline before provisioning
• Confirm environment separation: production credentials, networks, and data stores must be isolated from staging
• Validate that logging and alerting are configured and tested in the production environment before go-live

Post-Deployment and Maintenance

Shipping is not the finish line. The threat surface keeps moving after your code goes live.

• Maintain a current SBOM for every production application and reassess it when new CVEs publish
• Monitor CISA's Known Exploited Vulnerabilities catalog; any KEV match in your dependency inventory warrants immediate triage regardless of its original severity score
• Run scheduled SAST and SCA scans on production branches, beyond new PRs alone
• Track EPSS score changes on open findings; a dependency that scored low-risk at discovery can cross into actively exploited territory weeks later
• Patch third-party components within defined SLA windows based on severity tier
• Rotate secrets and credentials on a defined schedule and immediately after any suspected exposure
• Conduct periodic access reviews to confirm production permissions still match the least-privilege design spec

AI-Generated Code and the Agentic Development Threat Surface

AI coding agents have introduced a structural gap that most existing secure SDLC checklists were never designed to close. GitHub Copilot, Cursor, and Claude Code do not push code incrementally the way human developers do. They deliver complete draft PRs in one pass, often without a human in the loop until the review stage, a pattern that introduces vibe coding security risks teams cannot ignore. That changes where security controls need to sit.

The quality gap is well documented. AppSec Santa's 2026 AI code security research tested 534 code samples across six LLMs and found a 25.1% vulnerability rate. Veracode's 2025 GenAI Code Security Report found that 45% of AI-generated code introduced a known OWASP vulnerability. No major LLM produces consistently secure output. The AI-generated code security CISO guide covers these findings and mitigation strategies in depth.

Your agentic SDLC checklist needs items that traditional checklists omit entirely:

• Inventory every AI coding tool in use across your repositories, including which agent configuration files govern their behavior
• Define and enforce agentic rules at the agent generation layer, before code reaches PR review
• Scan AI-generated PRs with SAST and SCA on creation, before merge as well
• Require attestation evidence showing which security rules the agent applied during code generation
• Audit agent identity separately from developer identity, especially for cloud-based agents that commit under bot identities
• Run secrets scanning on every AI-generated commit; agents reproduce patterns from training data and can emit credential-shaped strings

With AI agents, "as early as possible" now means during generation, before the PR exists at all.

The OWASP Top 10 for Agentic Applications and Your Secure SDLC

The OWASP Agentic Applications Top 10, released by the OWASP GenAI Security Project, maps the risks specific to AI agent deployments. Each risk has a natural home in your SDLC checklist.

Most of these risks are invisible to traditional SAST tools because they are behavioral instead of syntactic. A scanner cannot flag ASI01 by reading code patterns. The agentic AI security complete guide covers the full range of behavioral threats. Catching it requires architectural controls set at design time and runtime behavioral monitoring during deployment.

How Arnica Governs the Agentic Development Lifecycle Across the SDLC

Every checklist phase covered in this article maps to a control Arnica enforces across the Agentic Development Lifecycle.

At the generation layer (Phases 1 through 3), Agentic Rules Enforcement writes a managed security rule block into the configuration files each AI coding agent reads: .cursor/rules/ for Cursor, CLAUDE.md for Claude Code, .github/copilot-instructions.md for GitHub Copilot. Rules default to OWASP ASVS Level 2 coverage and self-heal if a developer removes them. By the time a PR exists, the agent was already governed.

For Phases 4 and 5, pipelineless AI SAST and SCA scan every push and PR across 100% of connected repositories with no CI/CD pipeline instrumentation required. Arnica connects through the SCM and starts scanning immediately.

Post-deployment maintenance gets two capabilities most SDLC checklists treat as aspirational. Adaptive Backlog Management reassesses historical findings when a CVE crosses into the CISA KEV catalog or when EPSS scores shift materially, re-routing to the currently active developer with a fresh SLA timer. Arnica's own data shows 82% of security findings are attributed to developers who have already left the company. Security Champion Routing resolves that gap by identifying an active contributor in the relevant codebase instead of routing to a stale inbox.

PR Attestations give security teams auditable evidence showing how many times an AI agent applied governed security rules during code generation, answering the compliance question without assembling a manual audit trail.

Arnica has been named a Sample Vendor in the Gartner Hype Cycle for Platform Engineering 2026 under Software Supply Chain Security, and was formally included in the Forrester Agentic Development Security Tools report.

Final Thoughts on Making Security a Native Part of Your SDLC

A secure SDLC is less about adding more process and more about putting the right checks at the right moments. Your design decisions, your code standards, your deployment gates, and your post-ship monitoring all carry security weight, and this checklist maps out where each piece fits. With AI agents now generating production-bound code at scale, waiting for a pentest to find problems is a strategy that does not hold. Try Arnica free to see how agentic rules enforcement and pipelineless scanning fit into the phases you already run.

FAQs

What is the difference between SSDLC and traditional SDLC, and why does it matter for AppSec teams?

The core difference is timing: a traditional SDLC treats security as a final gate before release, while an SSDLC builds security requirements, threat models, and testing into every phase from planning through deployment. That timing gap is where fix costs compound. IBM Systems Sciences Institute data shows a defect caught in production costs up to 100 times more to fix than the same issue found during design.

How do you handle OWASP Top 10 risks for agentic applications in a secure SDLC checklist?

The OWASP Agentic Applications Top 10 2026 maps each risk to a specific SDLC phase: Agent Goal Hijack (ASI01) belongs in the design phase, where you define agent scope boundaries and rejection logic; Agentic Supply Chain Vulnerabilities (ASI04) is a requirements and design concern, requiring inventory and vetting of all third-party agent components before build begins; Unexpected Code Execution (ASI05) is addressed at coding and testing, by restricting the tools and runtimes available to each agent; Memory and Context Poisoning (ASI06) requires coding and testing controls that validate and sanitize all memory inputs; Insecure Inter-Agent Communication (ASI07) belongs in design, where you authenticate every agent-to-agent message boundary; Human-Agent Trust Exploitation (ASI09) is a design control that defines mandatory human-in-the-loop checkpoints; and Rogue Agents (ASI10) is a deployment concern requiring agent actions to be logged with attribution back to the prompting identity. Most of these risks are behavioral instead of syntactic, meaning traditional SAST cannot catch them by reading code patterns. They require architectural controls set at design time.

What should a secure SDLC checklist include for AI-generated code that standard templates miss?

Standard secure SDLC checklist templates were written for human-written code and omit several controls specific to AI coding agents. Your checklist needs: an inventory of every AI coding tool and agent configuration file in use across your repositories; security rules enforced at the agent generation layer before any PR exists; SAST and SCA scans triggered on AI-generated PR creation instead of only on merge; attestation evidence showing which security rules the agent applied during generation; and agent identity audited separately from developer identity, because cloud-based agents commit under bot identities that standard routing logic does not resolve. Agents also reproduce patterns from training data and can emit credential-shaped strings, so secrets scanning on every AI-generated commit is a mandatory baseline item.

How do I build a secure SDLC checklist that covers both the OWASP Top 10 web vulnerabilities and the new OWASP Top 10 for agentic AI?

Treat them as two separate control layers that map to different SDLC phases. The OWASP Top 10 web risks (injection, broken authentication, cryptographic failures, and the rest) are coding and testing phase controls: parameterized queries, MFA, TLS 1.2 or higher, server-side authorization checks on every request. The OWASP Top 10 for Agentic Applications 2026 risks require controls at design (defining agent scope and trust boundaries), coding (validating all agent inputs and outputs), and deployment (logging agent actions with identity attribution). The gap most teams miss is that web-focused secure SDLC checklists cover only the first layer, leaving agentic risks entirely unaddressed until something surfaces in production.

How does Arnica enforce secure SDLC controls across the agentic development lifecycle without requiring CI/CD pipeline instrumentation?

Arnica connects through your SCM (GitHub, GitLab, Azure DevOps, or Bitbucket) and scans every push and PR across all connected repositories from day one, with no per-repository CI/CD pipeline configuration required. At the generation layer, Agentic Rules Enforcement writes a managed security rule block into the configuration files each AI coding agent reads before generating code: .cursor/rules/ for Cursor, CLAUDE.md for Claude Code, .github/copilot-instructions.md for GitHub Copilot. Post-deployment, Adaptive Backlog Management reviews historical findings when a CVE crosses into the CISA Known Exploited Vulnerabilities catalog or when EPSS scores shift, re-routing to the currently active developer instead of a stale inbox, resolving the stale-routing problem described above.