What is a secure development lifecycle (SDLC)?
A secure development lifecycle (SDLC, also called a security development lifecycle) builds security checks into every stage of making software. Those stages are design, coding, testing, release, and maintenance. Typical checks include threat modeling, code review, automated security testing, and dependency scanning.
What the buyer is really asking
Buyers want to see security built into how you ship, not bolted on at the end. List the actual steps: design review, code review, automated testing, and controlled deployment.
Other ways buyers ask it
Every one of these wants the same answer:
- “Describe your secure software development lifecycle.”
- “Do you follow a secure SDLC framework?”
- “How is security integrated into development?”
Evidence to have ready
- An SDLC or change management policy
- Branch protection and required review settings
- CI pipeline configuration showing security checks
Sample answers by company stage
The right answer depends on what you actually run today. Each sample below is honest only if its condition is true for you. Swap the bracketed details for your own.
Early startup
Use this if: You have code review and CI in place but no formal written SDLC policy yet.
We follow a lightweight secure development process. Every change goes through a pull request on [GitHub]. Branch protection requires [one] approving review and passing CI before merge. CI runs automated tests, dependency scanning with [Dependabot], and static analysis with [CodeQL]. Production deploys happen only through our CI pipeline, and engineers cannot push directly to production. Changes to authentication, permissions, or customer data handling get an extra review from [a senior engineer]. This process is enforced by tooling but is not yet written up as a formal SDLC policy.
Scaling
Use this if: You have a written SDLC policy, security training for engineers, and security checks that block merges.
Our SDLC policy defines security activities at each stage. In design, features that touch authentication, authorization, or customer data get a written security review before build starts. In build, engineers follow secure coding guidelines based on the OWASP Top 10 and complete secure coding training [annually]. Every change needs peer review and passing CI checks: unit tests, static analysis, dependency scanning, and secret scanning. High-severity findings block the merge. Deployment is automated, and every production change traces back to an approved pull request. After release, we track vulnerabilities from scanners, penetration tests, and outside reports against severity-based deadlines.
Enterprise-ready
Use this if: Your SDLC maps to a named framework and an auditor has tested it.
Our secure SDLC aligns with the NIST Secure Software Development Framework (SP 800-218) and is in scope for our SOC 2 Type II audit. New services and significant architecture changes require a threat model. Code review, static analysis, dependency scanning, secret scanning, and container image scanning are required checks on every merge. Dynamic scanning runs against staging before each release. An independent firm performs a penetration test [annually] and after major changes. We produce a software bill of materials for each release. Change records, approvals, and scan results are kept for [one year] as audit evidence. Any exception to an SDLC control needs documented approval from [our security lead] and carries an expiry date.
How the major questionnaires word it
Each standard questionnaire asks this in its own structure. These are paraphrased summaries, not the licensed question text.
- CAIQ v4 (Cloud Security Alliance)
- The Application and Interface Security domain spreads this across several rows: an application security policy, baseline security requirements, secure design and development, automated security testing, secure deployment, and vulnerability remediation. Write one SDLC description that covers each row so they agree.
- SIG (Shared Assessments)
- The application security section asks whether a formal SDLC exists, whether it includes security requirements and testing phases, and whether developers get secure coding training. The training row is where many startups have to answer no.
- VSA (Vendor Security Alliance)
- VSA-style questionnaires ask you to describe your development practices, with emphasis on code review, automated testing, and separation between development and production.
- HECVAT (higher education)
- HECVAT asks whether you follow a documented SDLC and whether it is based on recognized guidance such as OWASP. Name the guidance in the additional information column.
More evidence reviewers accept
- The written SDLC or secure development policy with its approval date
- Secure coding training completion records for engineers
- A redacted design review or threat model from a recent feature
- One traced change: ticket, approved pull request, CI run, and deployment record
- Exception records for any change that bypassed a required control
Red flags reviewers look for
- A policy with no enforcement. A document describing a secure SDLC means little if admins can bypass branch protection. Reviewers ask for settings, not only documents.
- Security only at the end. An SDLC where security shows up only as an annual penetration test tells the reviewer it is bolted on. Name what happens during design and build.
- Direct production access. Any hint that engineers deploy from laptops or edit production by hand undercuts every other step you describe.
- Claiming a framework you cannot map. Saying you follow NIST SSDF invites a request for the mapping. If you do not have one, describe your actual steps instead.
- No developer training. This is one of the most common gaps. Answer it honestly and say what engineers do get, such as review checklists or OWASP guidance.
Follow-up questions to expect
Can a single engineer ship a change alone?
Say whether branch protection applies to admins and whether any emergency path skips review. If a break-glass path exists, describe how its use is logged and reviewed after the fact.
How do you keep secrets out of source code?
Name the secret scanner and where secrets actually live, such as a secrets manager or your cloud provider's parameter store. Mention whether the scanner blocks the push or only alerts.
Is production separated from development?
Buyers want separate accounts or projects, no production data in development, and no developer credentials that reach production by default. Say which of these are true.
How do you handle AI-generated code?
A newer follow-up. The honest answer is usually that it goes through the same review and checks as any other change. Say so if that is true, and note any extra rules you apply.
How do you review third-party code before it ships?
Dependencies are part of your SDLC. Say how new libraries get approved, whether pull requests that add a dependency get extra scrutiny, and how you pin versions. If you generate a software bill of materials, mention it. If you do not, describe how you would find every service using a vulnerable library within a day, since that is what the buyer is really testing.
How Tyrvar answers this
Tyrvar treats every wording above as one question. You write the answer once, attach the evidence, and revisit it when your setup changes. Each buyer gets that approved answer no matter how their questionnaire words it. If you have not answered it yet, Tyrvar flags the question for you and does not make something up. Try it on your own questionnaire.