Answer in four parts: you keep an inventory of direct and transitive dependencies, you scan it on every change and on a schedule, you have written rules for updating and removing components, and a named team owns the result. Then offer one piece of evidence for each part.
The four parts of a good answer
Inventory. Say how the list is produced. A lockfile parsed in CI or an SBOM generated per build is concrete. A spreadsheet maintained by hand is not, and a buyer will notice.
Scanning. State when it runs: on pull request, on release and on a schedule. The schedule matters because new advisories appear after code is merged. GitHub documents the same pattern in its own alerting: an alert is created when a new advisory is added and matched to your dependency graph, not only when you push code.
Update rules. Describe how you decide. For example: critical findings with a fix are patched within the timeline in your policy, and components with no fix get a recorded decision. The decision record is the evidence.
Ownership. Name a role, not a person. "The platform team owns dependency health and reports monthly to the security lead" survives staff changes.
A model answer you can adapt
"We maintain an automated inventory of direct and transitive open source components for each product, generated from lockfiles in CI. We scan the inventory on every pull request and daily against public advisory data. Findings are triaged by severity, whether a fix exists and whether the vulnerable code is reachable in our product. Our policy sets target timelines by severity, and exceptions are recorded with an owner and review date. We can provide the latest SBOM and a redacted sample of remediation tickets under NDA."
Edit every sentence to match what you actually do. If you do not check reachability, delete that clause.
Evidence to attach
| Claim | Evidence |
|---|---|
| Inventory exists | SBOM excerpt, anonymised if needed |
| Scanning runs | CI configuration screenshot or log with dates |
| Policy exists | Policy page with version and owner |
| Exceptions are controlled | Sample exception record |
Common mistakes
Saying "we use a scanner" without saying what it covers. Forgetting transitive dependencies, which are most of the tree in many projects. Claiming zero known vulnerabilities, which is rarely true and easy to disprove. Prefer "no known critical vulnerabilities with an available fix older than our policy window" if that is what your data shows.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are grouped and prioritised. That is the triage step your answer describes.
Quick check
Should I list our dependencies in the questionnaire?
Usually no. Offer an SBOM under NDA instead. A pasted list goes stale immediately.
What if we have no formal policy yet?
Say so, describe the current practice, and give a date for the written policy. A true partial answer is safer than an invented one.
Safeguard provides SBOM and dependency scanning with reachability analysis, and you can run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
