Software-Vendor Due Diligence: Evidence First

Connect scope, provenance, technical signals, and decisions

8 chapters91 min total
Keywords
Due diligenceSoftware supply chainOpenSSF ScorecardC-SCRMProvenanceSBOMDependenciesEvidenceResilienceRisk tolerance
Overview

Software-vendor due diligence is an investigation of a particular supplier, product, release, and intended use—not a completed questionnaire or a universal security score. The series starts by resolving identity, criticality, jurisdiction, provenance, dependencies, and tiers; builds a source-backed evidence packet; then examines OpenSSF Scorecard findings, outcomes, aggregation, access, and output formats as bounded technical observations. It shows how to route gaps to public research, corroborating artifacts, targeted supplier questions, remediation, acceptance, escalation, or policy gates. The organizing rule is to preserve each source’s scope, date, detection conditions, and uncertainty: NIST’s broader C-SCRM categories and Scorecard’s selected software signals inform different parts of the decision. A living record then refreshes evidence when suppliers, releases, dependencies, incidents, or system use change. The series supports traceable, proportionate decisions, but it does not turn partial visibility, supplier claims, or a score into proof that a vendor or product is secure.

Learning outcomes
  • A supplier questionnaire is evidence only when it closes a material gap with a scoped, dated, verifiable claim or artifact.
  • OpenSSF Scorecard shows selected repository signals; it does not establish supplier-wide security, provenance, resilience, or ownership.
  • Criticality and risk tolerance should determine research depth, escalation, and how far provenance and sub-tier analysis continues.
  • A defensible decision preserves observations, claims, unknowns, boundaries, and refresh triggers as the supplier and product change.
Keywords
Due diligenceSoftware supply chainOpenSSF ScorecardC-SCRMProvenanceSBOMDependenciesEvidenceResilienceRisk tolerance

Chapters

Preview every chapter · Unlock full text, audio, and video from chapter 4

Plans
Ch.1-3 FreeCh.4-8 Premium

FAQ

What is evidence-first software-vendor due diligence?

Evidence-first software-vendor due diligence investigates a particular supplier, product, release, and use before relying on supplier assurances. It corroborates source-backed findings, preserves gaps, and matches research depth to criticality and risk tolerance.

What can OpenSSF Scorecard prove in a vendor review?

OpenSSF Scorecard can provide bounded observations about selected software-development, dependency, vulnerability, release, and governance practices in an analyzed repository. It does not prove supplier-wide security, ownership, resilience, or complete product provenance.

When should a buyer send a targeted supplier question?

A buyer should send a targeted supplier question when a material gap is not reasonably observable through public or independent evidence. The request should name the product or release, scope, date, and artifact or explanation that could change the decision.

How should software-vendor due diligence stay current?

Software-vendor due diligence stays current by recording scope, evidence dates, unresolved questions, and refresh triggers. Reevaluate when ownership, releases, dependencies, incidents, system criticality, or intended use changes.