Answer yes only for practices you run, and list them: code review before merge, dependency scanning, protected branches, a way to receive vulnerability reports, and a patching rule. Say which parts are informal. Do not say you comply with a framework unless an independent party has said so.
What the question really asks
"Secure development lifecycle" is a loose phrase. Reviewers use it to ask whether security is part of how you build, or something you bolt on at the end. They want a short list of habits with evidence.
NIST's Secure Software Development Framework describes a core set of high level secure software development practices that can be integrated into each software development lifecycle implementation, with the aim of reducing vulnerabilities in released software and limiting the impact of those that remain. Many reviewers use it as a mental model. You can reference it as a guide, and you can say which practices you follow, but avoid claiming compliance.
Build the answer from five stages
| Stage | A practice a small team can run | Evidence |
|---|---|---|
| Plan | Security considerations noted in design for risky features | Design notes or ticket template |
| Build | Code review on every change to the main branch | Branch protection export |
| Check | Dependency scanning on pull requests, tests in CI | CI config and a recent report |
| Release | Production deploys through a pipeline with a named approver | Deployment log |
| Respond | A way to receive vulnerability reports and a patching rule | Contact page, policy |
Fill in only what is real. If design notes are informal, say "informal for now".
A model answer
"Security is part of how we build. Changes to the main branch need review, and direct pushes are blocked. Dependencies are scanned on every pull request and findings are reviewed weekly. Production deployments go through our pipeline with a named approver. We publish a contact for vulnerability reports and follow a written patching approach. Design review for security is informal and we are formalising it this year. We align these practices to parts of NIST SP 800-218 but have not been assessed against it."
Mistakes to avoid
- "We follow industry standard practices." It says nothing.
- "We are SSDF compliant" or any claim of certification you cannot back with an independent result.
- Listing tool names with no description of the control.
- Overstating threat modelling or penetration testing if you do neither routinely.
Keep a small proof set
One example pull request showing review, one scan report with a date, one closed vulnerability ticket, one deployment approval. Four artifacts answer most follow ups.
Review it yearly
Update the answer when practices change. A stale answer is a risk too.
For a longer treatment, see our guide to the secure software development framework.
Safeguard's policies and gates, dependency scanning and compliance and evidence automation support the check and release stages, and the free scan at https://gold.safeguard.sh/scan gives you a first report.
Quick check
Can we say we follow NIST SSDF?
Say you align certain practices to it and name them. Do not claim compliance without an independent assessment.
Do we need threat modelling?
Only claim it if you do it. Even a short design review for risky features is something honest to report.
What is the quickest improvement?
Make sure review, scanning and protected branches are on for every repository, then record that.
Sources
Last reviewed: 19 October 2026.
