Have five things ready: a dated record of dependency and code scans, a written severity and fix-time policy, a summary of any independent test, an inventory of what you ship, and an honest statement of scope and gaps. Most enterprise reviews can proceed on that, without a certification.
What reviewers are checking
A security review asks whether you find and fix problems systematically. They rarely expect perfection. They do expect proof that testing is a habit, not a one-off. NIST's Secure Software Development Framework describes practices meant to reduce vulnerabilities in released software and address their root causes, which is the idea behind most review questions.
The five items
1. Scan records. Keep dated output for dependency scanning and any static or dynamic scans. Retain a few months. A single screenshot looks staged, while a trail looks like a routine.
2. A fix policy. One page stating target fix times by severity, who is responsible, and how exceptions are approved. Make sure it reflects reality. If you miss the targets, adjust them honestly.
3. An independent test summary. If you have had a penetration test, keep a redacted summary with date, scope and the status of each finding. If you have not, say that one is planned and when, and do not imply otherwise.
4. An inventory. A list of repositories, services and key components. An SBOM for your main product is increasingly requested. It shows you know what you ship.
5. A scope statement. What is tested, what is not, and why. For example: "All production services are scanned on every change. An internal admin tool is not yet covered and is scheduled for next quarter."
Packaging it
| Item | Format | Update |
|---|---|---|
| Scan records | Exported reports with dates | Monthly |
| Fix policy | One-page document | Yearly or when practice changes |
| Test summary | Redacted PDF | After each external test |
| Inventory | SBOM and repository list | On release |
| Scope statement | Short paragraph | Quarterly |
Store them in one folder so a request takes minutes, not days.
What to avoid
- Claiming a certification or attestation you do not hold. If something is in progress, say that and no more.
- Sending raw scan output. It may hold internal names or sensitive paths.
- Overstating coverage. A reviewer who finds a gap you did not mention will doubt everything else.
A short timeline for a team starting from nothing
Week one: turn on dependency scanning for all production repositories and start saving the output. Week two: write the one-page fix policy and agree it with engineering leads. Week three: generate an SBOM for the main product and draft the scope statement. Week four: book an independent test if the customer is likely to ask, and write down the date.
After a month you will have a dated trail, even if it is short. A short honest trail beats a long vague promise, and it grows on its own as scans keep running.
Questions to expect in the call
- How often do you scan, and what happens to a critical finding?
- Who approves exceptions to your fix policy?
- When did you last have an outside party test the product?
- Can you share an inventory of the components you ship?
Rehearse short, true answers. If the honest answer is "not yet, planned for next quarter", say that. Reviewers see that answer often and respond better to it than to a bluff they later catch.
Where Safeguard fits
Safeguard's SBOM generation, dependency scanning, policies and compliance and evidence automation produce dated records for items one, two and four. Independent testing and static or dynamic scanning come from other sources. Try the free scan at https://gold.safeguard.sh/scan.
Quick check
Do we need a penetration test to pass a review?
Not always, but many reviewers ask. If you do not have one, state your plan and the date plainly.
How long should scan records be kept?
Keep several months at least, so the trail shows a routine. Match any retention period set by your contracts or policies.
Sources
Last reviewed: 19 October 2026.
