Answer with specifics a reader can check: what tool category runs, where in the pipeline, on which repositories, who triages findings, and what records you keep. Avoid absolutes such as "all code is scanned" unless you can show it. Say plainly what is not covered.
What the question is really asking
Questionnaire items such as "do you use static analysis?" or "do you perform secure code review?" are a proxy for whether you catch flaws before release. NIST's Secure Software Development Framework frames this as code review and analysis performed against your secure coding standards, with issues recorded and triaged in your team's workflow. A good answer maps to that shape.
An answer template
Fill each line with facts that are true today:
- What: "We run static application security testing on application source code."
- Where: "It runs on pull requests and on the main branch" or whichever is true.
- Scope: "It covers these languages and these repositories." Name exclusions.
- Response: "Findings are triaged by the owning team in our issue tracker, and high severity findings block merge" only if that is your practice.
- Evidence: "We retain scan results and triage decisions, and can share a sample under NDA."
- Review cadence: "Rules and exceptions are reviewed on a stated schedule."
If a line is not true, drop it. A shorter honest answer is better than a complete overstated one.
Wording that helps and wording that hurts
| Safer wording | Risky wording |
|---|---|
| "Scans run on every pull request for the covered repositories" | "All code is always scanned" |
| "Findings above a set severity block merge" | "No vulnerabilities reach production" |
| "We track and triage findings" | "We fix everything immediately" |
| "Following practices aligned with the SSDF" | "SSDF certified" |
| "Audit in progress" if true | Any claim of a completed report you do not hold |
NIST describes the SSDF as a framework of recommendations, so be careful with words like "compliant" or "certified." Describe what you do and let the buyer judge.
Attach evidence, not adjectives
A one page summary is more convincing than a long paragraph. Include the tool category, scope table, a sample finding with its triage record, and the date of last review. Keep the exportable results with the commit scanned, and consider a standard format such as SARIF for sharing, since it is an OASIS standard for static analysis output.
Keep answers consistent
Different people answering different questionnaires lead to contradictions. Keep one approved paragraph per topic in a shared library, with an owner and a review date. When practice changes, update the paragraph, then the questionnaires follow.
Know the limits and say them
OWASP notes static tools have false positives, false negatives and blind spots such as access control and configuration. A buyer who sees you name those limits and describe a complementary practice, like code review or dynamic testing, usually trusts you more, not less.
A worked example: three versions of one answer
The question is: "Do you perform static analysis on your source code before release?" Here are three possible answers, from weakest to strongest.
Version one: "Yes, we take code security seriously." This says nothing a reader can check.
Version two: "Yes, we run automated static analysis on all code." The words "all" and "automated" invite follow up. If one repository is not covered, the answer is wrong.
Version three: "We run static application security testing on pull requests for our main application repositories, covering the languages we use for services. Findings are triaged by the owning team in our issue tracker, and findings in a defined high severity category block merge. Legacy repositories A and B are scanned on a nightly schedule instead. We retain results and triage decisions and can provide a redacted sample under NDA."
Version three is longer and far more useful. It states scope, process, an exception and evidence, and it can be defended line by line.
Step by step: prepare your answer library
- List every repository and mark whether it is scanned, how often and by what.
- Write the scope sentence from that list, naming any exceptions.
- Document the triage process in two or three sentences.
- Decide what evidence you can share, and under what conditions.
- Have an engineering lead and a security lead approve the text.
- Store it in a shared answer library with a review date.
- Update the text whenever practice changes.
When a questionnaire arrives, you copy from the library, not from memory.
Matching question variants
| Question wording | What the reader wants |
|---|---|
| "Do you perform secure code review?" | Human and tool review of code before release |
| "Do you use SAST?" | A yes or no, and where it runs |
| "How do you identify vulnerabilities in your code?" | Your whole set of methods |
| "How do you ensure compliance with secure coding standards?" | A standard and a check against it |
| "Do you test third party code?" | Dependency scanning and review |
Answer the actual question and not the one you wish had been asked. When a question mixes topics, split the answer into labeled parts.
Dealing with partial coverage
Most real programs have partial coverage. Say so plainly: name the covered areas, name the gaps and say what compensates. For example: "Our infrastructure scripts are reviewed by a second engineer on each change, since our static tool does not analyze that file type." That sentence shows awareness and control. Buyers read it as maturity.
Evidence package for follow up
Prepare a small packet in advance:
- A one page process summary.
- A scope table by repository.
- A sample finding with its triage record, with sensitive details removed.
- The date of the last policy review.
- A statement about the standards you follow, using careful wording such as "aligned with" and avoiding "certified."
NIST describes the SSDF as a framework of practices, so claims of conformance should be carefully phrased and based on what you can show.
Consistency across documents
The answer in the questionnaire should match your website, your sales deck and your trust documentation. If the website says "every pull request" and the questionnaire says "nightly," someone will notice. A quick monthly check of the library against public statements prevents that.
Escalation
If a question asks for something you do not do, say so and describe your plan if you have one with a date. Avoid inventing a process to fit the question. A plain "not currently, planned for next quarter" is acceptable, and it is far safer than an answer that cannot be supported.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how one practice maps to questions in more than one framework, which helps you reuse a single answer.
Quick check
What if we only scan some repositories?
Say so, and name which ones. Partial coverage stated clearly is acceptable. Overstated coverage is the risk.
Can I say we follow the SSDF?
Only if you can describe the practices you actually follow. Avoid claiming certification, since the framework is a set of recommendations.
How long should a questionnaire answer be?
Long enough to state scope, process and evidence in a few sentences. Add a short packet for follow up instead of a long paragraph.
Safeguard offers compliance and evidence automation, which helps teams keep records ready for these requests, and a free scan at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218, Secure Software Development Framework version 1.1
- OWASP, Static Code Analysis
- OASIS, SARIF version 2.1.0
Last reviewed: 19 October 2026.
