IAST output can be one piece of evidence that you test running software for vulnerabilities. It does not by itself show you meet any framework. Evidence needs context: scope, dates, who reviewed it, and what you did about each finding.
What the SSDF is, and is not
NIST's Secure Development Framework, SP 800-218 version 1.1, published in February 2022, is described as a core set of high-level secure software development practices that can be built into any software development life cycle. It also gives buyers and suppliers a shared vocabulary. It is a framework of practices, not a product requirement for any specific tool, and no tool report can "make you compliant" with it.
This post takes no position on what any customer or agency requires. Check the specific terms in your contract or questionnaire.
What a reviewer wants to see about testing
Reviewers generally look for a repeatable process more than a single report. Useful evidence answers these questions:
- What do you test, and how often?
- Which methods do you use, and why those?
- What is the scope? Which services, which versions?
- What happened to the findings? Who triaged them, and how fast?
- How do you know the testing actually ran?
Packaging IAST output
| Evidence item | What it shows |
|---|---|
| Run log with date, build, and agent version | The test happened, on a known build |
| Coverage note | What the run exercised, and what it did not |
| Finding list with disposition | Triage happened |
| Linked fix tickets and merge records | Findings were closed |
| Retest result | The fix worked |
| Policy document | Testing is part of the process, not a one off |
The coverage note matters most. Because IAST sees only what executes, an honest report states its limits. Reviewers tend to trust a limited claim that is documented over a broad claim that is vague.
Pair it with other testing
OWASP's Application Security Verification Standard, version 5.0.0 as the current stable release, is an open list of security requirements for web applications. It can help structure what you verify, and IAST evidence can support some of it. Static analysis, dependency scanning, dynamic testing, and manual review cover other parts.
What not to say
- Do not call a tool report a certification.
- Do not imply an audit that has not happened.
- Do not state coverage you did not measure.
Quick check
Is an IAST report enough to answer a security questionnaire?
Seldom by itself. Attach it to a short description of your testing process and scope.
How long should I keep the evidence?
Follow your own retention policy and any contract terms. Ask your counsel if unsure.
Does using a tool make us compliant?
No. A framework describes practices and outcomes. Tools help you carry out and document them, and your own process shows whether you meet them.
A worked example: answering a buyer's testing question
A buyer asks how you test running software for vulnerabilities. A weak answer says we use an IAST tool. A strong answer is short and specific: we run IAST in our integration test stage on our five customer facing services, we measure route coverage on each run, findings are triaged within an agreed time, and we keep the run logs and fix records. We do not claim it covers every path, and we pair it with static analysis and dependency scanning.
The strong answer describes a process, states limits, and offers evidence. It does not claim compliance with anything. That is what makes it credible.
An evidence folder that works
Create one folder per quarter. Include run logs, coverage notes, the finding list with dispositions, links to fix tickets, retest results, and the policy in force. Add a short cover note saying what is included and what is out of scope. When someone asks a question, you can answer from the folder in minutes.
Keeping claims honest
Review any public or customer facing statement about testing with the people who run it. If the text says all, always, or every, check that it is true. Prefer wording such as we run, we measure, and we review. If a framework asks for something you do not do, say so and describe your plan. Silence or exaggeration is worse than a stated gap.
Where IAST fits among other evidence
A testing story rarely rests on one method. Static analysis covers code before it runs, dependency scanning covers components, IAST and dynamic testing cover running behavior, and manual review covers design and logic. When you describe your program, name each method, say where it runs, and state its limits. Reviewers tend to be reassured by a layered description that admits gaps. They tend to be suspicious of any single tool presented as the answer.
A short checklist before you share evidence
Check that dates and versions are correct, that sensitive values are removed from any exports, that the scope statement matches reality, and that anyone quoted has agreed. Ask a colleague to read the package as a skeptical reviewer would, and write down their questions. Fix what they raise. Finally, have the package reviewed by whoever handles legal and contract matters, since this post is not legal advice. A careful review takes an hour and avoids awkward corrections later.
Common reviewer questions
Expect questions such as: how often does testing run, who reviews the findings, how long do fixes take, what is not covered, and how do you know the tool was running? Draft short written answers in advance, with links to artifacts. Having them ready shortens the review and signals maturity. If you cannot answer one, treat it as a work item, not a problem to hide.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a single piece of evidence can map to several framework items, and where gaps show up.
Safeguard offers compliance and evidence automation, along with SBOM and dependency scanning. A free scan is at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218, Secure Software Development Framework 1.1
- OWASP Application Security Verification Standard
- OWASP DevSecOps Guideline: Interactive Application Security Testing
Last reviewed: 19 October 2026.
