Scope the Investigation Before You Score Anything
When a software supplier enters a procurement process, the first decision is not which security score to run. It is what entity, product, and acquisition context the evidence is supposed to describe. This chapter focuses on that scoping problem: how to build a traceable subject record, choose a proportionate level of research, and keep questions about ownership, jurisdiction, and delivery capability separate from repository-security observations. The payoff is simple: later technical findings can attach to the right object and be interpreted at the depth the acquisition actually warrants.
A due-diligence process has an initial condition. The acquirer knows that a product or service is being considered, but may not yet know which legal entity stands behind it, which release or hosted service is in scope, how critical the dependency will be, or which risks would be unacceptable. If those variables remain implicit, the investigation can look thorough while answering the wrong question. A scan of a public repository is not a substitute for identifying the supplier, just as a supplier's legal name is not a substitute for understanding how the product is built.
Give the evidence an address
NIST's first steps put traceability before deep research. The useful identity is more than a brand name. It includes the company's legal name, public or private status, company description, incorporation date and location, headquarters, website, identifiers, ownership status, and office locations. Contracting data and security-clearance information can add context when the environment makes those data relevant. These fields are not bureaucratic decoration. They determine which records belong together and which claims need further checking.
Consider a software product sold through a reseller. The brand a buyer sees, the legal entity named in the contract, the organization maintaining a public repository, and the publisher of a release may be related without being identical. The evidence record should state those relationships rather than collapsing them into “the vendor.” The product name should also be tied to a version, service boundary, or release channel where that distinction can change the risk. A repository observation about an upstream project may inform the review, but it should not silently become evidence about the downstream product's entire delivery chain.
This is a question of ownership. The acquirer owns the subject record: which supplier and product are under review, what use is proposed, and what decision is being made. A public source owns only the observation it actually provides. If the source describes a project but not its corporate owner, the gap belongs in the record. If two sources use similar names but disagree about an address or relationship, the disagreement should trigger validation rather than a convenient merge.
NIST recommends pre-checks against government regulatory, exclusion, and prohibition lists before spending time on deeper research. The quick-start guide points to resources such as the International Trade Administration's Consolidated Screening List, the System for Award Management's exclusions, and the Supplier Performance Risk System's company status for relevant government acquisitions. These checks are not complete judgments about a supplier. They are early transition conditions: a material restriction may change whether further procurement research is useful, permissible, or urgent.
The order matters because investigation has a cost. If a supplier is already subject to a prohibition relevant to the intended purchase, a long review of its branch rules and dependency files may not change the immediate decision. If the pre-check is clear, that result does not establish trust; it simply allows the investigation to proceed. A negative screen is therefore a bounded observation, not a security certificate.
Cross-source validation is the next control. NIST specifically warns that research can uncover conflicting findings and recommends comparing company-derived information with government-derived sources and using multiple sources when possible. A supplier website may be the best source for a current product description, while an official filing or procurement record may be better for legal identity or contracting history. Neither source should be treated as universally authoritative for every question.
The record should preserve at least four distinctions:
- Subject: the legal supplier, product, service, release, or component being evaluated.
- Observation: what a named source actually reports.
- Interpretation: why that observation may matter to the proposed use.
- Unresolved gap: what is still unknown or requires a different source.
That structure prevents a familiar failure mode. An analyst finds a repository with a plausible name, sees strong security practices, and attaches those practices to the vendor's commercial promise. The source may genuinely show a well-managed project. It may still say nothing about the legal entity, the hosted service, a private fork, or the release that the buyer will operate. Evidence becomes decision-relevant only after its address is known.
The flowchart shows why criticality belongs early. It controls the transition from a basic public-information pass to enhanced research or a fuller supplier review. It does not mean that every low-criticality supplier is safe or that every high-criticality supplier is suspect. It means the amount of evidence needed to make a defensible decision should reflect the consequences of being wrong.
Let criticality set the depth
NIST describes basic due diligence as desktop research using publicly available information. Enhanced due diligence can add commercial datasets, proprietary sources, and supply-chain illumination tools. The two modes answer the same broad question—what is known about the supplier or product—but they differ in visibility, cost, and the kinds of evidence they can reach. The choice should be made by acquisition criticality and available resources, with findings validated against multiple sources when possible.
Criticality is not merely a label attached to a purchase order. It describes what would happen if the product were compromised, unavailable, counterfeit, unsupported, or subject to a constraint the acquirer had not discovered. A component embedded in a low-impact internal tool may justify a concise public first pass. Software that can affect a critical service, sensitive data, or a large downstream population may warrant deeper provenance research, more attention to sub-tier suppliers, enhanced data sources, or a formal supplier review. The source does not provide a universal formula or threshold, so the organization must define the concern levels that make these transitions.
Those concern levels are the decision boundary between “interesting” and “material.” A foreign ownership finding may be tolerable for one use and unacceptable for another. An old breach may be less important if its impact was limited and the supplier has credible mitigations, but more important if similar incidents recur or the product handles sensitive information. NIST's model asks the organization to make those judgments explicit rather than letting an analyst's intuition become an invisible policy.
The five research categories help set that depth without turning the review into an unstructured search.
FOCI requires organizational and jurisdictional evidence. Foreign Ownership, Control, or Influence concerns significant ties to governments or government-controlled interests outside the designated focal country that could affect management or operations. The relevant questions include who owns or invests in the company, where it is headquartered, whether a merger or acquisition is pending, and whether key leaders have ties to foreign governments. Some jurisdictions impose laws requiring entities to cooperate with security services or share sensitive information, potentially including source code, designs, or customer data.
A repository can sometimes provide clues about public affiliations or the location of visible contributors, but those clues do not establish beneficial ownership or legal compulsion. A high technical score cannot answer a FOCI question. The organization has to define which countries it considers low, moderate, or high risk, how much foreign exposure it can tolerate, and whether a concerning tie can be mitigated. Those are governance decisions, not properties generated by a code scan.
Resilience asks whether the supplier can continue to perform. NIST includes financial distress, legal difficulties, leadership turnover, regulatory violations, government exclusions, criminal associations, breaches and ransomware, forced labor or conflict materials, and environmental instability among possible organizational concerns. Product concerns include poor performance, counterfeiting, unauthorized white-labeling, repeated willful negligence, and intentionally malicious practices. The guide recommends considering the age of the information, frequency of the event, severity, and mitigations currently in place.
This category prevents a technical review from being mistaken for a delivery review. A supplier may maintain disciplined source-control practices and still be unable to support the contract, provide timely fixes, or operate in a stable location. Conversely, a historical incident does not automatically define current risk. The evidence has to be interpreted in relation to recurrence, impact, and what has changed since the event.
Foundational Cyber Practices connect the supplier's IT posture to product development. NIST separates the overall cyber health of the supplier's information-technology assets from secure product development and product-specific concerns. The first side includes public-facing weaknesses, exposed credentials, patching, obsolete software, and susceptibility to ransomware or business interruption. The second includes unpatched vulnerabilities, product lifespan, update frequency, component inventories, and the security implications of dependencies.
This is where a repository-security tool can become useful, but only within a defined boundary. Evidence about branch protection, dependency handling, release artifacts, or vulnerability findings may illuminate the development side of foundational practices. It does not automatically describe every supplier IT asset or prove that the product being purchased has the same controls. The boundary should be written into the record before the result is used.
Supply Chain Tiers determine how far the investigation should follow relationships. A first-tier supplier provides products or services directly to the end user; a second-tier supplier serves the first tier, and the chain can continue to a depth the organization chooses. Looking farther down can reveal a common dependency, sole-source concentration, or a sub-tier relationship that changes the risk. But NIST warns that visibility becomes harder and more expensive as the investigation goes deeper, with difficulty and cost increasing exponentially.
That trade-off creates a stopping rule. Continue when the next tier could change the decision—for example, when several direct suppliers rely on the same critical sub-tier component. Stop or defer when additional detail is unlikely to affect the chosen control, mitigation, or acceptance decision. The aim is not to produce a perfect map of every indirect relationship. It is to find the relationships that matter for this product, this system, and this risk tolerance.
A well-scoped investigation therefore has a lifecycle of its own. It begins with a proposed use and a subject record. Pre-checks can stop or redirect the work. Criticality selects the depth of research. Findings are classified by category and concern level. A material gap triggers a different source, a targeted supplier question, or a fuller review. At each transition, the owner and reason should be visible. Otherwise, “enhanced diligence” becomes a vague promise to look harder, and “low risk” becomes an unsupported conclusion.
The same discipline applies to supplier questions. Ask the supplier when the missing information is material and not reasonably observable from public sources—for example, the legal relationship between entities, a product-specific operational location, a nonpublic mitigation, or an alternative implementation a tool cannot detect. Ask for the narrowest evidence that could resolve the question. A response that changes the decision should carry its own source, scope, date, and verification status.
By the end of scoping, the acquirer should be able to state: this is the supplier and product under review; this is how the product will matter to the system; these are the concern levels that govern escalation; this is what basic research can reasonably establish; and this is why deeper research is or is not justified. Only then is a technical score attached to a meaningful subject.
The next question follows the product rather than the vendor's marketing language: what evidence shows where the software came from, how its components and releases relate to one another, and which sub-tier dependencies could change the risk? That is the work of provenance and tier analysis.