How to answer
Do you have a secure software development lifecycle?
Reviewers are testing one thing: what prevents an unreviewed change from reaching your customers' data.
Yes. All code changes are peer reviewed before merge, automated dependency and static analysis scanning runs in the build pipeline, and development, staging and production environments are separated with no shared credentials.
FillTrust grades an answer like this confirmed in your documents when your documents support it.
- Answered from
- Your engineering handbook or SDLC policy, and the change management section of your SOC 2 report.
- Evidence to attach
- Occasionally a screenshot of a branch protection rule or a pull request showing a required review.
- Where it is asked
- CAIQ v4.0 · AIS-04SIG LiteISO 27001 Annex A · A.8.25
The phrase "secure SDLC" makes this sound like it needs a formal programme. It does not. What is being asked is narrow and practical: what stands between a developer's laptop and production, and is it a control or a habit.
Three things make up a complete answer for a company of this size.
Peer review, enforced. Not "we review each other's code", which every team says, but that merges to the main branch require an approving review and the repository is configured to refuse otherwise. The difference matters because the second one survives a busy Friday and the first one does not. If you have branch protection on, this is the strongest sentence in your answer, so lead with it.
Automated checks in the pipeline. Dependency scanning and static analysis on every build. Name what they cover rather than what they are called: a reviewer who does not use your tools cannot evaluate a tool name, but "dependencies are scanned on every build and a critical finding fails the build" is legible to anyone.
Environment separation. Development, staging and production as separate projects or accounts, with no credential that reaches more than one. This is where a lot of small teams have a real gap, usually a database URL in a developer's environment file that points at production. If that is true, it is worth fixing before it is worth answering, because it is also the finding that turns a routine questionnaire into a conversation.
What not to include. Threat modelling, secure coding training and a formal design review gate all appear in the fuller versions of this question. If you do not do them, leave them out rather than describing an aspiration. An answer covering review, scanning and separation is a good answer at fifteen people; the same answer padded with three practices you do not have is a worse one, because a single follow-up unpicks it.
This grades as confirmed for most teams with an engineering handbook. If your handbook describes the process but the repository does not enforce it, expect the grade to be implied instead, and treat that as accurate.
How this one goes wrong
Specific to this question, not general advice.
- Describing a process the repository settings do not enforce. If review is a convention rather than a required check, a reviewer who asks for the branch protection screenshot will find the gap.
- Listing tools instead of controls. "We use Dependabot and CodeQL" answers a different question from "what stops an unreviewed change reaching production".
- Claiming environment separation while a single set of credentials reaches both. This is the specific thing the question is testing.