Due Diligence as a Living Evidence System
Software-vendor due diligence answers a moving question: whether a particular supplier and product remain acceptable for a particular use as the evidence and the system change. This final chapter reconnects the central argument—evidence should come before assurances—with the operating model developed across the series. It explains how to keep a decision traceable and current, how NIST's broad C-SCRM categories and OpenSSF Scorecard's technical observations coexist, and when a questionnaire, independent research, or a fuller assessment is the right next step.
The conclusion is not that automation replaces procurement judgment or that supplier answers have no value. It is that each source should be asked to support the claim it can actually reach. NIST provides the risk-based structure for investigating suppliers and products. Scorecard can provide repeatable observations about selected software practices. The acquirer still owns identity, applicability, risk tolerance, corroboration, and the decision about what uncertainty is acceptable.
Keep the decision alive
A due-diligence decision is a state, not a permanent property of a vendor. The supplier can change ownership, leadership, operating locations, or contractual relationships. The product can acquire new dependencies, publish a new release, reach end of life, or change the data and systems it touches. A source can become stale, a vulnerability can be discovered, and a mitigation can be applied or abandoned. A result that was accurate when collected can therefore become irrelevant without ever having been false.
NIST's quick-start guide recommends a continuous-monitoring process that determines when information should be refreshed and how reports should be updated. It does not mandate one refresh interval. That is an important design choice. A fixed annual ritual may be too slow for a rapidly changing dependency and wasteful for a stable, low-impact component. Refresh conditions should follow the rate and consequence of change.
Useful triggers include:
- a new product or release entering the decision scope;
- a material change in dependencies, build or release practices, or sub-tier relationships;
- a change in supplier ownership, leadership, location, legal status, or service boundary;
- a new breach, vulnerability, regulatory action, or product-performance event;
- evidence reaching an age at which it no longer represents the relevant risk; and
- a change in the system's criticality, data, exposure, or recovery assumptions.
These are not an exhaustive calendar. They are events that can invalidate an assumption on which the decision rested. A low-criticality internal component may need a lighter monitoring burden than a product embedded in a critical service, but both need a condition that says when the previous evidence stops being sufficient.
The evidence record should make the trigger actionable. It should preserve the source, collection date, product and release scope, analyzed repository or artifact where relevant, concern level, unresolved questions, and the event that would cause re-evaluation. For technical results, retaining the repository commit and evaluator information helps a reviewer determine what was actually analyzed. For public or commercial findings, retaining the source and handling constraints helps preserve both provenance and appropriate access.
Sensitivity is part of freshness. NIST notes that aggregated vulnerability findings for some systems may need classification or CUI handling, and that findings from commercial illumination tools or special-access government systems may contain proprietary business information. A monitoring system that republishes every underlying detail to every consumer can create unnecessary exposure. The record should separate the evidence needed by an analyst from the decision signal needed by a downstream gate.
There is also a difference between refreshing evidence and rerunning a ritual. A new scan can produce a current result while leaving the scope wrong. A refreshed questionnaire can contain new answers while leaving the supplier-product relationship unresolved. Before refreshing, confirm that the object, use, and decision boundary are still the same. If they are not, the process returns to scoping rather than simply replacing old values with new ones.
A living decision is therefore conditional by design. “Accepted” should mean accepted for this product, this use, this evidence state, and this stated residual risk. It should not mean that every future release or supplier change inherits approval automatically. “Remediation required” should include the evidence that will demonstrate completion.