Ask how dependencies are added, where the inventory comes from, how often it is regenerated, who approves new packages, how updates and vulnerabilities are handled, and what happens when a package is abandoned. Specific, dated answers signal a controlled process. Vague answers signal the opposite.
How to run the conversation
Keep it to 45 minutes and ask for examples, not policies. "Show me the last dependency you added" beats "Do you have a process?" Ask for one repository on screen if access allows.
The questions
| # | Question | A good answer includes |
|---|---|---|
| 1 | How does a new dependency get approved? | Named reviewer, criteria, a recent example |
| 2 | Where does your inventory come from? | A tool, a trigger, a storage location |
| 3 | How often is it regenerated? | Every build or release |
| 4 | Do you commit lockfiles? | Yes for applications, with locked installs in CI |
| 5 | Do you keep copies of libraries in the repository? | A list, with upstream and version |
| 6 | Do you maintain forks? | Who owns them and when last synced |
| 7 | How do you hear about new vulnerabilities in what you use? | Automated scanning plus an owner |
| 8 | What was your last urgent dependency fix and how long did it take? | A real timeline |
| 9 | How do you treat abandoned packages? | A replace or adopt rule |
| 10 | Which repositories have no inventory? | A number, not "none" |
| 11 | What do you know you do not know? | Honest, specific gaps |
| 12 | Who left recently who knew the dependency story? | Awareness of knowledge risk |
Why question 11 matters
The NTIA minimum elements report asks authors to state known unknowns explicitly. A lead who names them is applying that discipline. A lead who says there are none is either very good or has not looked.
Scoring the answers
Use three levels per question: shown, described, or unclear. Shown means they produced evidence during the call. Described means plausible but unchecked. Unclear means follow up. Add the counts and note which areas to verify with data.
Follow up with data
An interview is a map, not proof. After the call, check two or three answers against the repositories: the last added dependency, one lockfile, one inventory timestamp.
Questions to avoid
- Yes or no questions about policy, which invite yes.
- Questions that assume a tool, such as asking about a specific scanner.
- Asking for blame about past incidents. Ask what changed afterwards.
Safeguard offers SBOM and dependency scanning, asset discovery and compliance and evidence automation, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Who else should be in the room?
A platform or release engineer, since they know what the build really does.
What if the lead is evasive?
Write the question in the gap register and verify it from the repositories directly.
Sources
Last reviewed: 19 October 2026.
