Leaders can learn most of what they need about dependency health by asking ten plain questions and listening for specific answers. Vague replies are themselves a finding. Use the list below in a staff meeting, a quarterly review or a 1 to 1, and note which answers come with a number and which with a shrug.
The questions
1. How long would it take to learn which services use a given library? A good answer is minutes from an inventory. A weak one is "we would ask around."
2. What is the oldest runtime we run, and when does it lose support? Python and Node.js publish status per release, so there is a date to quote.
3. Do we have vulnerabilities that are known to be exploited and still open? CISA's catalog of known exploited vulnerabilities is the usual reference.
4. How many major versions behind are our core frameworks? Under semantic versioning, each major is a set of breaking changes.
5. From advisory published to fix in production, what is our typical time? Ask for the last three examples.
6. Who owns dependencies for each service? A name, not a team alias that nobody checks.
7. What gets updated automatically, and who reviews it? Automated pull requests for outdated dependencies exist in common platforms, but they need reviewers.
8. What are we deliberately not updating, and why? There should be a short list with reasons and review dates.
9. How do we decide which findings are urgent? Look for use of exploitation status and reachability rather than only severity scores.
10. What would we do if a critical fix required a major upgrade tonight? Listen for a rehearsed fast path.
Reading the answers
| Answer style | What it suggests |
|---|---|
| Specific number and source | A working process |
| "Roughly, I think" | Process exists but is not measured |
| "We would need to check" | No inventory or ownership |
| Defensive tone | Past blame, so reduce it first |
Using it well
Do not turn this into an audit that teams dread. Ask in a spirit of wanting to remove blockers. After each answer, ask a follow up: "What would make this easier?" The responses often point to cheap fixes, such as a missing calendar entry or an unowned repository.
What to do with gaps
Pick the two weakest answers and assign one action each, with an owner and a date. Revisit next quarter. Improvement over three quarters is more valuable than a perfect score in one.
A note on tone
OWASP's guidance says organizations should have an ongoing plan for monitoring, triaging and applying updates for the lifetime of the application or portfolio. That wording is useful: it frames updates as continuous work, not a project with an end. Say so in the meeting.
Safeguard's SBOM and dependency scanning lists direct and transitive packages with their versions, and reachability analysis shows which outdated or vulnerable ones your code actually calls. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Who should ask these questions?
The CTO, VP of engineering or an engineering director, with security present. Keep it supportive rather than punitive.
How often?
Quarterly is enough for most teams, with a lighter monthly look at the scorecard numbers.
Sources
- Status of Python versions
- Node.js releases
- CISA Known Exploited Vulnerabilities Catalog
- Semantic Versioning 2.0.0
- OWASP Top 10:2021, A06 Vulnerable and Outdated Components
- About version updates, GitHub Docs
Last reviewed: 19 October 2026.
