Each layer produces different proof. SCA gives dated inventories and scan history. ASPM gives a consolidated view with owners and priorities. The vulnerability management process gives policy, deadlines, exception records and time to fix data. Together they show a control operating over time, not just a tool installed.
What reviewers actually want
A customer security reviewer or an auditor wants to see that a stated practice is real. A sentence in a questionnaire says you scan dependencies. Evidence shows a dated scan, a finding, a ticket and a verified fix. Do not claim any certification or attestation you do not hold. Describe the practice and offer the records.
NIST's Secure Software Development Framework, SP 800-218, describes secure development practices in a shared vocabulary that producers and buyers can use when they communicate. It is a handy way to name what you do without overstating it.
Evidence by layer
| Layer | Evidence examples | What it shows |
|---|---|---|
| SCA | SBOM per release, dated scan results, list of applications scanned | Components are known and checked |
| ASPM | Consolidated findings view, owner mapping, priority rules | Findings are tracked and assigned |
| VM process | Written policy, deadlines by tier, exception log, closure records | Rules exist and are followed |
Records worth keeping
- A written vulnerability policy with tiers, deadlines and exception rules, with a version date.
- Scan history showing runs over time for each in-scope application.
- SBOM snapshots for each released version.
- Ticket trail from finding to fix, with the rescan that confirmed it.
- Exception records with approver, reason and expiry.
- Period reports with median time to fix and count of items past deadline.
Keep them in a place you can export. Evidence you cannot retrieve in a day will slow a review.
How to answer common questions
"How often do you scan dependencies?" State the actual cadence and offer the last three scan dates.
"How quickly do you fix critical findings?" Give your policy deadline and your measured median, and say plainly where you missed.
"Do you have an SBOM?" Offer one for a named release. CISA describes an SBOM as a nested inventory of the ingredients that make up software.
"Do you track known exploited vulnerabilities?" Explain whether you use the CISA catalog as a ranking input.
Be accurate about what you hold
- A policy and operating records are not an attestation report.
- A framework alignment statement is not certification.
- If you are in an audit period, say so with the right wording and do not state a completion you have not reached.
For legal or contractual interpretation, ask your counsel. This post is about practice, not legal advice.
A worked example
A prospective customer sends a questionnaire with three dependency related questions. Here is how a team might answer, using the evidence listed above.
Question 1: Do you scan third party libraries for known vulnerabilities? Answer: Yes. We scan dependencies in CI on every pull request and nightly against deployed builds. We can provide the dates of the last three scans for a named service and a sample of the resulting inventory.
Question 2: How do you prioritize and remediate? Answer: We rank by known exploitation, reachability and exposure, and apply deadlines by tier from our written policy. Our measured median time to fix for the top tier last quarter was available on request, along with the count of items that missed the deadline.
Question 3: Do you maintain a software bill of materials? Answer: We generate one per release and can share one for a named version under an appropriate agreement.
Each answer states a practice, names a record and avoids claiming anything the team cannot show.
Step by step: prepare an evidence folder
- Create a folder with a stable structure by quarter.
- Store the policy with its version and approval date.
- Export scan history monthly, one file per service or one combined file.
- Save SBOM snapshots for each release.
- Save the exception log with approvers and expiry dates.
- Add a monthly metrics page with five numbers and one paragraph of commentary.
- Test retrieval. Ask a colleague to find a specific item in under 10 minutes.
Common reviewer follow ups
| Follow up | Evidence that answers it |
|---|---|
| Show us a critical finding and how it was fixed | Ticket, pull request, rescan result with dates |
| How do you handle a vulnerability with no fix? | Exception record with mitigation and expiry |
| Who approves risk acceptance? | Policy section and exception examples |
| How do you know the inventory is complete? | Application catalog compared with scan coverage |
Cautions
- Do not backfill records to make history look better. Reviewers notice, and it damages trust.
- Do not overstate. If scans cover 80 percent of services, say so and describe the plan for the rest.
- Do not confuse a tool with a control. A control is a practice that operates over time. The tool is how you run it.
When in doubt, describe what you do, show a dated record, and note what is still in progress. That approach holds up under questions better than a confident claim with nothing behind it.
Try it yourself
See how technical controls map onto framework requirements and what evidence each one produces.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard offers SBOM generation and dependency scanning, plus compliance and evidence automation to collect these records. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a scanner report enough as evidence?
One report shows one moment. Reviewers prefer a history, a policy and a trail from finding to verified fix.
Can I say we are aligned with a framework?
Only if you can describe which practices you follow and offer records. Do not imply certification you do not hold.
How far back should evidence go?
Keep at least as far back as your reviews or audits ask about, and keep the history consistent so trends are easy to explain.
Sources
Last reviewed: 19 October 2026.
