Before launch, a product manager should ask engineering what third party code ships in the product, whether any of it has known serious flaws, who maintains it, and how a fix would reach customers. Seven short questions below turn a vague worry into a checklist.
Why this belongs to product
Dependencies affect schedule, licensing and customer trust. A flaw found a week before release is a product problem, not only an engineering one. GitHub's dependency graph description shows the kind of facts engineers can pull quickly: each dependency's version, license and known vulnerabilities.
The seven questions
- What third party components ship in this release? Ask for the list, not a summary.
- Do any have known serious vulnerabilities? Ask for the number and the names.
- Which of those are actually used by our code? Many flagged flaws sit in code paths a product never calls.
- Are any licenses a problem for how we sell this? Legal should see unusual terms early.
- Which components are abandoned or have a single maintainer?
- If a serious flaw is announced next month, how long until customers have a fix?
- Who signs off that these answers are current?
How to read the answers
| Answer you hear | What it suggests |
|---|---|
| "We would have to check" | No current inventory |
| "Forty findings, six reachable" | Triage is in place |
| "We do not know who maintains it" | Ownership gap |
| "Fix in a day" | A release path exists |
The goal is not zero findings. It is knowing where you stand and having a path to fix.
Make it routine
Put a short dependency review on the launch checklist next to testing and legal review. Ask for the same numbers each release so trends become visible. Over time the questions get quicker to answer, and fewer surprises arrive late.
Where Safeguard fits
Safeguard produces SBOMs and scans dependencies, and its reachability analysis shows which findings your code actually uses. You can run a free scan on a repository to see an inventory for yourself.
Try it yourself
Watch how the findings list shrinks when only reachable issues are shown, then think about which number you would want in a launch review.
Click through it at your own pace, or open it full screen.
Quick check
Will asking these questions slow the launch?
Rarely. The answers come from tooling and take minutes once the process exists. Finding the same issue after launch costs far more.
Do I need to understand the code?
No. You need to understand the answers: counts, owners and timelines.
Sources
Last reviewed: 19 October 2026.
