Do you have secure software development practices?

How to answer this security questionnaire question, with an expert response your security or GRC team can adapt.

Expert answer

Follow a secure development lifecycle with threat modeling, code review, dependency and static analysis, and security testing before release. Train developers on secure coding and track vulnerabilities to closure.

What the security reviewer is checking

Reviewers map your answer against a secure development lifecycle mentally shaped by NIST SSDF (SP 800-218) and OWASP guidance: security requirements and threat modeling at design time, peer review and automated scanning before merge, dependency and secret hygiene, protected build pipelines, and independent validation through penetration testing. They pay particular attention to enforcement — whether checks are blocking gates in CI or advisory suggestions engineers can skip — and to supply chain posture, since build-pipeline compromises made software provenance a standard line of questioning. A specific answer names the practice at each stage; a weak one says "we follow OWASP best practices" and stops.

Example response you can adapt

This is an illustrative template, not a real vendor's security posture. Replace every claim with what is actually true for your organization before submitting it.

Security is built into each stage of our development lifecycle, which is aligned with the NIST Secure Software Development Framework. At design time, features touching authentication, authorization, or new categories of data undergo threat modeling with the security team. Every code change requires peer review and must pass blocking CI gates: static application security testing, software composition analysis against known-vulnerable dependencies, and secret scanning — a failing gate stops the merge, and exceptions require documented security approval. Dependencies are pinned via lockfiles and updated under our vulnerability SLAs. Build pipelines are access-controlled and produce artifacts from source only through CI, with no manual artifact uploads to production. Deployments are gradual with automated rollback on error-rate regression. Independently, an accredited third party performs an annual penetration test of the application and infrastructure, and engineers complete annual secure coding training oriented to the OWASP Top 10.

Evidence reviewers expect you to attach

Secure development policy or SDLC standard
CI pipeline configuration summary showing SAST, SCA, and secret-scanning gates
Most recent penetration test executive summary and remediation status
Threat modeling procedure or a sanitized example
SOC 2 report section on change management (CC8.1)

Follow-up questions reviewers ask next

Are security scans blocking gates in CI, or advisory only?
When was your last penetration test, and are all findings remediated?
How do you vet and update third-party dependencies?
Can a single engineer push code to production without review?
Do you produce a software bill of materials (SBOM) on request?

Answer every security questionnaire in minutes

Wolfia drafts accurate, cited answers to security questionnaires and RFPs from your existing documentation. See it work on your own questions.Book a demo