CSSLP · Secure Software Supply Chain

Implement software supply chain risk management

Establish a repeatable process to identify, assess, treat, monitor, and communicate risks arising from software components, suppliers, services, build systems, and distribution channels.

Example: Establish a repeatable process to identify, assess, treat, monitor, and communicate risks across components, suppliers, services, build systems, and distribution channels.

Counterexample: Prioritize from severity alone while omitting reachability, exposure, privilege, support, and business impact, and the available records do not support component risk. | Regard an earlier not-reachable or no-known-issue result as permanent assurance, and the bounded finding on supply chain risk governance is treated as permanent. | Let a scanner or technical owner accept residual exposure without an authorized business owner, and supply chain risk governance lacks an authorized risk owner.

Limitations: The supplier-risk process covers direct components but omits build services, distribution channels, and external service dependencies.

Tradeoffs: Establish a repeatable process to identify, assess, treat, monitor, and communicate risks across components, suppliers, services, build systems, and distribution channels.

International Organization for Standardization

ISO is an official outline example representing applicable international management and assurance standards. In supply-chain scenarios, identify the specific standard or control objective rather than treating “ISO” as one universal software-supply-chain standard.

Example: The component governance lead should identify the specific ISO standard and control objective applicable to the supplier decision instead of treating ISO as one universal supply-chain control set.

Counterexample: The component governance lead should assess functionality and cost but omit provenance, licensing, support, and security criteria, and the available records do not support standards selection. | The component governance lead should regard one framework label or approved source as conclusive assurance, and the result for standards selection is treated as valid after supplier changes. | The component governance lead should let the component team finalize the decision without business risk ownership or ongoing oversight.

Limitations: The supplier claims to be ISO compliant without identifying the applicable standard, scope, or control objective.

Tradeoffs: Identify the specific ISO standard and control objective applicable to the supplier decision instead of treating ISO as one universal supply-chain control set.

National Institute of Standards and Technology

NIST is an official outline example whose relevant guidance includes Cybersecurity Supply Chain Risk Management (SP 800-161) and the Secure Software Development Framework (SP 800-218). Use the specific publication and purpose supplied by the scenario rather than treating “NIST” as one control set.

Example: The supplier decision should select the NIST publication that matches the decision, such as SP 800-161 for supply-chain risk or SP 800-218 for secure development practices.

Counterexample: The supplier decision should evaluate the relationship at acquisition but omit support changes, testing scope, logging, subcontractors, and exit obligations. | Treat the name NIST as a complete supply-chain control set without identifying the applicable publication or control objective. | Let the supplier select the applicable NIST guidance without customer verification or accountable risk ownership.

Limitations: The acquisition package cites NIST compliance without naming the publication or explaining how it applies to the decision.

Tradeoffs: Select the NIST publication that matches the decision, such as SP 800-161 for supply-chain risk or SP 800-218 for secure development practices.

Supply-chain scope

The supply chain includes source code, dependencies, tools, build services, package repositories, artifact stores, distribution channels, cloud services, and supporting suppliers.

Example: A defensible response is to include source, dependencies, tools, build services, repositories, artifact stores, distribution channels, cloud services, and supporting suppliers in the assessment boundary.

Counterexample: A defensible response is to assess functionality and cost but omit provenance, licensing, support, and security criteria, and material facts about software ecosystem boundary remain unexamined. | A defensible response is to regard one framework label or approved source as conclusive assurance, and a scoped assertion about software ecosystem boundary becomes complete assurance. | A defensible response is to let the component team finalize the decision without business risk ownership or ongoing oversight, and the lifecycle owner for software ecosystem boundary is not defined.

Limitations: The assessment boundary excludes package mirrors, build services, artifact stores, and cloud dependencies that influence the release.

Tradeoffs: Include source, dependencies, tools, build services, repositories, artifact stores, distribution channels, cloud services, and supporting suppliers in the assessment boundary.

Identification and selection of components

Select components using security, functionality, supportability, licensing, provenance, maintainability, and business-fit criteria.

Example: The acquisition team should select components using security, functionality, supportability, licensing, provenance, maintainability, and business-fit criteria.

Counterexample: The acquisition team should assess functionality and cost but omit provenance, licensing, support, and security criteria. | The acquisition team should interpret one framework label or approved source as conclusive assurance. | The acquisition team should let the component team finalize the decision without business risk ownership or ongoing oversight.

Limitations: The preferred component was selected for features and price without reviewing provenance, licensing, support, or maintainability.

Tradeoffs: Select components using security, functionality, supportability, licensing, provenance, maintainability, and business-fit criteria.

Component inventory before selection

Candidates should know version, origin, maintainer, license, dependencies, update channel, support status, known vulnerabilities, and integrity-verification method before adoption.

Example: The next step is to document each candidate component’s version, origin, maintainer, license, dependencies, update channel, support status, known vulnerabilities, and integrity-verification method before adoption.

Counterexample: The next step is to assess functionality and cost but omit provenance, licensing, support, and security criteria, and the record supporting pre adoption inventory omits relevant versions and environments. | The next step is to frame one framework label or approved source as conclusive assurance, and pre adoption inventory is treated as settled by a framework label, approved source, or earlier component result. | The next step is to let the component team finalize the decision without business risk ownership or ongoing oversight, and the decision maker for pre adoption inventory lacks business risk authority.

Limitations: The proposed dependency lacks a verified version, origin, maintainer, license, support status, update channel, and integrity method.

Tradeoffs: Document each candidate component’s version, origin, maintainer, license, dependencies, update channel, support status, known vulnerabilities, and integrity-verification method before adoption.

Approved component repository

An approved internal or controlled repository reduces unreviewed acquisition paths and supports provenance, version pinning, scanning, and policy enforcement.

Example: A defensible response is to require acquisition through an approved controlled repository that supports provenance, version pinning, scanning, source policy, and auditability.

Counterexample: A defensible response is to allow package acquisition without binding namespace, source, fallback, and integrity rules. | A defensible response is to regard a private registry address as proof that substitution or name confusion cannot affect the controlled component source decision. | A defensible response is to let developers override source policy without logged approval or later review.

Limitations: Developers can bypass the controlled repository and obtain dependencies directly from arbitrary public sources.

Tradeoffs: Require acquisition through an approved controlled repository that supports provenance, version pinning, scanning, source policy, and auditability.

Package registry, mirror, and proxy governance

Route package acquisition through approved registries, internal mirrors, or controlled proxies that enforce registry-to-namespace mappings, authentication, source policy, integrity checks, caching rules, and audit logging. Prevent silent fallback to arbitrary public repositories when an internal source lacks a requested package.

Example: The responsible owner should route package acquisition through approved registries, mirrors, or proxies with namespace mapping, authentication, source policy, integrity checks, controlled caching, and audit logging.

Counterexample: The responsible owner should allow package acquisition without binding namespace, source, fallback, and integrity rules, and important dependencies affecting package source routing are not assessed. | The responsible owner should regard a private registry address as proof that substitution or name confusion cannot affect the package-source routing decision. | The responsible owner should let developers override source policy without logged approval or later review, and the acceptance of package source routing occurs outside accountable governance.

Limitations: The internal package proxy silently falls back to public registries when an internal package is unavailable.

Tradeoffs: Route package acquisition through approved registries, mirrors, or proxies with namespace mapping, authentication, source policy, integrity checks, controlled caching, and audit logging.

Component substitution risk

Dependency confusion occurs when a resolver selects an attacker-controlled public package that collides with an internal package name or is preferred by source or version rules. Mitigate it with scoped or reserved namespaces, explicit registry-to-scope mapping, approved internal proxies, source pinning, lockfiles, integrity verification, and controls that prevent fallback to untrusted public registries.

Example: The security review team should reserve or scope internal namespaces, bind them to approved registries, prevent public fallback, pin sources, and verify integrity before resolving a package.

Counterexample: The security review team should allow package acquisition without binding namespace, source, fallback, and integrity rules. | The security review team should use a private registry address as proof that substitution or name confusion cannot affect the reported dependency-confusion control result. | The security review team should let developers override source policy without logged approval or later review, and dependency confusion control lacks an authorized risk owner.

Limitations: A public package with the same name and a higher version can be selected instead of the intended internal dependency.

Tradeoffs: Reserve or scope internal namespaces, bind them to approved registries, prevent public fallback, pin sources, and verify integrity before resolving a package.

Typosquatting and name confusion

Typosquatting uses package names that resemble trusted packages through misspelling, transposed characters, homoglyphs, or misleading prefixes and suffixes. Reduce risk with allowlists, exact-name review, namespace controls, publisher verification, lockfiles, integrity verification, and user-interface warnings. Unlike dependency confusion, the attack relies primarily on mistaken selection rather than public-private resolver precedence.

Example: The supplier decision should verify the exact package name and publisher through an approved source, then enforce allowlists, namespace controls, lockfiles, and integrity checks.

Counterexample: The supplier decision should allow package acquisition without binding namespace, source, fallback, and integrity rules, and material facts about package name verification remain unexamined. | The supplier decision should interpret a private registry address as proof that substitution or name confusion cannot affect the package-name verification assurance conclusion, and one bounded result is used to approve every use of newly requested package. | The supplier decision should let developers override source policy without logged approval or later review, and the exception governing package name verification has no defined expiry.

Limitations: A developer selected a similarly spelled package without confirming the exact name, namespace, or publisher.

Tradeoffs: Verify the exact package name and publisher through an approved source, then enforce allowlists, namespace controls, lockfiles, and integrity checks.

Risk assessment of components

Assess component risk using likelihood, impact, exploitability, reachability, privilege, exposure, maintainer trust, update cadence, support, and compensating controls.

Example: Assess component risk using likelihood, impact, exploitability, reachability, privilege, exposure, maintainer trust, update cadence, support, and compensating controls.

Counterexample: Prioritize from severity alone while omitting reachability, exposure, privilege, support, and business impact. | Present an earlier not-reachable or no-known-issue result as permanent assurance, and the result for component risk evaluation is treated as valid after supplier changes. | Let a scanner or technical owner accept residual exposure without an authorized business owner, and the first decision about component risk evaluation is never reconsidered.

Limitations: Component priority is based on a severity score without reachability, exposure, privilege, support, or business context.

Tradeoffs: Assess component risk using likelihood, impact, exploitability, reachability, privilege, exposure, maintainer trust, update cadence, support, and compensating controls.

Mitigate component risk

Mitigation can include patching, replacement, isolation, configuration, least privilege, monitoring, contractual controls, or compensating technical safeguards.

Example: The application security architect should select a risk treatment such as patching, replacement, isolation, secure configuration, least privilege, monitoring, contractual controls, or compensating safeguards.

Counterexample: The application security architect should prioritize from severity alone while omitting reachability, exposure, privilege, support, and business impact. | The application security architect should frame an earlier not-reachable or no-known-issue result as permanent assurance, and the available evidence for component risk treatment is overextended. | The application security architect should let a scanner or technical owner accept residual exposure without an authorized business owner, and the approval for component risk treatment lacks escalation, expiry, and reassessment.

Limitations: A vulnerable component has been acknowledged but no patch, replacement, isolation, configuration, monitoring, or compensating treatment is assigned.

Tradeoffs: Select a risk treatment such as patching, replacement, isolation, secure configuration, least privilege, monitoring, contractual controls, or compensating safeguards.

Accept component risk

Risk acceptance requires authorized business ownership, documented rationale, residual-risk understanding, review dates, and any required compensating controls.

Example: The supplier decision should obtain acceptance from an authorized business risk owner with documented rationale, residual-risk understanding, review dates, and required compensating controls.

Counterexample: Base the decision about residual component risk acceptance on evidence that omits relevant supplier conditions. | The supplier decision should interpret an earlier not-reachable or no-known-issue result as permanent assurance, and independent validation of residual component risk acceptance is skipped. | The supplier decision should let a scanner or technical owner accept residual exposure without an authorized business owner.

Limitations: A developer recorded acceptance of residual component risk without an authorized business owner, review date, or rationale.

Tradeoffs: Obtain acceptance from an authorized business risk owner with documented rationale, residual-risk understanding, review dates, and required compensating controls.

Component criticality

A component is more critical when compromise can affect trust roots, privileged execution, broad dependency trees, sensitive data, or business-essential services.

Example: A defensible response is to rank a component’s criticality according to its effect on trust roots, privileged execution, dependency breadth, sensitive data, and business-essential services.

Counterexample: A defensible response is to prioritize from severity alone while omitting reachability, exposure, privilege, support, and business impact, and controls governing dependency criticality are only partially assessed. | A defensible response is to frame an earlier not-reachable or no-known-issue result as permanent assurance, and the signal supporting dependency criticality is applied to untested conditions. | A defensible response is to let a scanner or technical owner accept residual exposure without an authorized business owner, and residual risk associated with dependency criticality has no authorized owner.

Limitations: A library that controls privileged trust decisions is being treated as no more critical than an isolated user-interface dependency.

Tradeoffs: Rank a component’s criticality according to its effect on trust roots, privileged execution, dependency breadth, sensitive data, and business-essential services.

Reachability and exploitability

A vulnerability in an included component may not be reachable in the deployed context, but reachability claims require evidence and can change with configuration or code paths.

Example: The acquisition team should use evidence from the deployed version, configuration, code paths, and feature state to evaluate reachability, and reassess the conclusion when those conditions change.

Counterexample: The acquisition team should prioritize from severity alone while omitting reachability, exposure, privilege, support, and business impact, and the evidence set for reachability exploitability is incomplete. | The acquisition team should regard an earlier not-reachable or no-known-issue result as permanent assurance, and the supplier statement on reachability exploitability is treated as independent proof. | The acquisition team should let a scanner or technical owner accept residual exposure without an authorized business owner, and the organization cannot enforce ownership of reachability exploitability.

Limitations: An old reachability result is being used after configuration and feature changes altered the deployed code paths.

Tradeoffs: Use evidence from the deployed version, configuration, code paths, and feature state to evaluate reachability, and reassess the conclusion when those conditions change.

Maintaining third-party components list

Maintain an accurate, versioned, environment-aware inventory of third-party and open-source components and their dependencies.

Example: The next step is to maintain an accurate, versioned, environment-aware inventory of third-party and open-source components and their direct and indirect dependencies.

Counterexample: The next step is to record direct package declarations but omit transitive, vendored, dynamic, runtime, and release-specific items. | The next step is to use an inventory or vulnerability status as proof of authenticity, safety, reachability, and license compliance. | Assign final authority over data sensitive component record to a role that lacks business risk ownership.

Limitations: The component list omits exact versions, transitive dependencies, and differences among released environments.

Tradeoffs: Maintain an accurate, versioned, environment-aware inventory of third-party and open-source components and their direct and indirect dependencies.

Software bill of materials

An SBOM is a formal inventory of software components and dependency relationships; it supports visibility but does not prove security, provenance, or exploitability.

Example: A defensible response is to use the SBOM as a scoped component inventory and combine it with provenance, vulnerability, reachability, and licensing evidence for risk decisions.

Counterexample: A defensible response is to record direct package declarations but omit transitive, vendored, dynamic, runtime, and release-specific items. | A defensible response is to frame an inventory or vulnerability status as proof of authenticity, safety, reachability, and license compliance. | A defensible response is to keep the record unchanged after build, dependency, environment, or vulnerability evidence changes affecting the SBOM use approval process.

Limitations: The release team is treating the SBOM as proof that every listed component is secure, authentic, reachable, and license compliant.

Tradeoffs: Use the SBOM as a scoped component inventory and combine it with provenance, vulnerability, reachability, and licensing evidence for risk decisions.

Software composition analysis and SBOM generation

Software Composition Analysis identifies third-party and open-source components and may correlate versions, licenses, and known vulnerabilities or generate an SBOM. SCA and SBOM are not synonymous: tool coverage, build paths, transitive dependencies, vendored code, generated artifacts, runtime-provided components, and dynamic loading can make an SCA-derived inventory incomplete unless reconciled with the released product.

Example: The responsible owner should reconcile SCA findings with the released artifact so vendored, generated, transitive, dynamically loaded, runtime-provided, and environment-specific components are represented.

Counterexample: The responsible owner should record direct package declarations but omit transitive, vendored, dynamic, runtime, and release-specific items, and material facts about SCA to release reconciliation remain unexamined. | The responsible owner should present an inventory or vulnerability status as proof of authenticity, safety, reachability, and license compliance, and the organization skips local due diligence for SCA to release reconciliation. | The responsible owner should keep the record unchanged after build, dependency, environment, or vulnerability evidence changes affecting the SCA-to-release reconciliation approval process, and the first decision about SCA derived component inventory is never reconsidered.

Limitations: The SCA scan misses vendored code, dynamically loaded modules, generated artifacts, and runtime-provided components in the release.

Tradeoffs: Reconcile SCA findings with the released artifact so vendored, generated, transitive, dynamically loaded, runtime-provided, and environment-specific components are represented.

Vulnerability Exploitability eXchange

VEX is a machine-readable security advisory that states the vulnerability status of a specific product or component, such as affected, not affected, fixed, or under investigation, with scope and justification. It complements an SBOM by communicating product-specific exploitability status; it does not prove that a component is safe or authorize ignoring new evidence.

Example: The security review team should evaluate a VEX statement for product scope, status, justification, provenance, freshness, and supporting evidence before using it in prioritization.

Counterexample: The security review team should record direct package declarations but omit transitive, vendored, dynamic, runtime, and release-specific items, and material facts about VEX evaluation remain unexamined. | The security review team should take an inventory or vulnerability status as proof of authenticity, safety, reachability, and license compliance, and the conclusion for VEX evaluation is not revalidated after change. | The security review team should keep the record unchanged after build, dependency, environment, or vulnerability evidence changes affecting VEX evaluation approval path, and authority over product specific vulnerability statement shifts to a technical or supplier role.

Limitations: An old not-affected VEX statement is being accepted without checking product scope, justification, provenance, or freshness.

Tradeoffs: Evaluate a VEX statement for product scope, status, justification, provenance, freshness, and supporting evidence before using it in prioritization.

SBOM formats

SPDX and CycloneDX are common machine-readable SBOM formats; format choice does not by itself establish completeness or trustworthiness.

Example: The supplier decision should choose SPDX or CycloneDX according to exchange needs while validating inventory scope, completeness, creation method, and trustworthiness separately.

Counterexample: The supplier decision should record direct package declarations but omit transitive, vendored, dynamic, runtime, and release-specific items, and material facts about SBOM format selection remain unexamined. | The supplier decision should take an inventory or vulnerability status as proof of authenticity, safety, reachability, and license compliance, and independent validation of SBOM format selection is skipped. | The supplier decision should keep the record unchanged after build, dependency, environment, or vulnerability evidence changes affecting SBOM-format selection approval path, and the exception for machine readable component inventory format lacks ownership and review dates.

Limitations: The team assumes choosing a recognized SBOM format proves the inventory is complete and trustworthy.

Tradeoffs: Choose SPDX or CycloneDX according to exchange needs while validating inventory scope, completeness, creation method, and trustworthiness separately.

SBOM completeness

An SBOM should define scope, component identity, version, dependency relationship, supplier, creation method, timestamp, and known limitations.

Example: Define SBOM scope, component identity, version, dependency relationships, supplier, creation method, timestamp, and known limitations.

Counterexample: Record direct package declarations but omit transitive, vendored, dynamic, runtime, and release-specific items, and material facts about inventory completeness remain unexamined. | Present an inventory or vulnerability status as proof of authenticity, safety, reachability, and license compliance, and independent validation of inventory completeness is skipped. | Keep the record unchanged after build, dependency, environment, or vulnerability evidence changes affecting the inventory completeness approval process.

Limitations: The SBOM omits its scope, dependency relationships, creation method, timestamp, and known limitations.

Tradeoffs: Define SBOM scope, component identity, version, dependency relationships, supplier, creation method, timestamp, and known limitations.

SBOM freshness

SBOMs must be regenerated or reconciled as builds, dependencies, environments, and release artifacts change.

Example: The software supply-chain risk lead should regenerate or reconcile the SBOM whenever builds, dependencies, environments, or released artifacts change.

Counterexample: The software supply-chain risk lead should record direct package declarations but omit transitive, vendored, dynamic, runtime, and release-specific items, and material facts about inventory freshness remain unexamined. | The software supply-chain risk lead should take an inventory or vulnerability status as proof of authenticity, safety, reachability, and license compliance, and the claim about inventory freshness is generalized to later versions. | The software supply-chain risk lead should keep the record unchanged after build, dependency, environment, or vulnerability evidence changes affecting inventory freshness approval path.

Limitations: An SBOM generated for an earlier build is being reused after dependencies and the release artifact changed.

Tradeoffs: Regenerate or reconcile the SBOM whenever builds, dependencies, environments, or released artifacts change.

Transitive dependencies

Indirect dependencies can introduce vulnerabilities and licenses even when the application did not select them directly.

Example: The organization should include the business-critical component evidence record for the regulated analytics platform in inventory, vulnerability, and licensing analysis even when the application did not select them directly.

Counterexample: The organization should record direct package declarations but omit transitive, vendored, dynamic, runtime, and release-specific items, and the released context for indirect dependency coverage is not represented. | Treat an inventory or vulnerability status as proof of authenticity, safety, reachability, and license compliance, and treat one indirect-dependency signal as contextually complete evidence. | The organization should keep the record unchanged after build, dependency, environment, or vulnerability evidence changes affecting indirect dependency coverage approval path, and changes affecting business critical component record can bypass renewed authorization.

Limitations: The inventory includes direct dependencies but excludes libraries introduced through transitive dependency paths.

Tradeoffs: Include the business-critical component evidence record for the regulated analytics platform in inventory, vulnerability, and licensing analysis even when the application did not select them directly.

Monitoring for changes and vulnerabilities

Continuously monitor component versions, maintainer changes, repository events, disclosures, exploit activity, support status, and dependency updates.

Example: A defensible response is to continuously monitor versions, maintainer changes, repository events, disclosures, exploit activity, support status, and dependency updates.

Counterexample: A defensible response is to prioritize from severity alone while omitting reachability, exposure, privilege, support, and business impact, and material facts about component change monitoring remain unexamined. | A defensible response is to frame an earlier not-reachable or no-known-issue result as permanent assurance. | A defensible response is to let a scanner or technical owner accept residual exposure without an authorized business owner, and the approval of component change monitoring persists without later review.

Limitations: No process monitors maintainer transfers, repository events, support termination, disclosures, or dependency updates.

Tradeoffs: Continuously monitor versions, maintainer changes, repository events, disclosures, exploit activity, support status, and dependency updates.

Vulnerability intelligence correlation

Correlate advisories and CVEs with actual inventory, versions, configuration, reachability, exposure, and business criticality.

Example: The acquisition team should correlate advisories and CVEs with actual inventory, versions, configuration, reachability, exposure, and business criticality.

Counterexample: The acquisition team should assess functionality and cost but omit provenance, licensing, support, and security criteria, and the review of vulnerability context correlation omits material supplier conditions. | The acquisition team should frame one framework label or approved source as conclusive assurance. | The acquisition team should let the component team finalize the decision without business risk ownership or ongoing oversight, and the lifecycle owner for vulnerability context correlation is not defined.

Limitations: New advisories are prioritized without mapping them to actual versions, configuration, reachability, exposure, and business criticality.

Tradeoffs: Correlate advisories and CVEs with actual inventory, versions, configuration, reachability, exposure, and business criticality.

End-of-life component

Unsupported components lack normal security maintenance and require replacement, isolation, risk acceptance, or other explicit treatment.

Example: The next step is to replace, isolate, or otherwise explicitly treat unsupported components, with authorized risk acceptance when continued use is unavoidable.

Counterexample: The next step is to prioritize from severity alone while omitting reachability, exposure, privilege, support, and business impact, and important dependencies affecting unsupported component treatment are not assessed. | The next step is to interpret an earlier not-reachable or no-known-issue result as permanent assurance, and the available evidence for unsupported component treatment is overextended. | The next step is to let a scanner or technical owner accept residual exposure without an authorized business owner, and authority over unsupported component treatment shifts to a technical or supplier role.

Limitations: An unsupported component remains in a critical service without replacement, isolation, compensating controls, or authorized acceptance.

Tradeoffs: Replace, isolate, or otherwise explicitly treat unsupported components, with authorized risk acceptance when continued use is unavoidable.

Supplier concentration risk

Dependence on one supplier, repository, cloud service, or maintainer can create systemic operational and security risk.

Example: A defensible response is to assess concentration in suppliers, repositories, cloud services, and maintainers, then establish resilience or alternative-source treatments for material dependencies.

Counterexample: A defensible response is to prioritize from severity alone while omitting reachability, exposure, privilege, support, and business impact, and the control boundary for vendor concentration exposure is not fully examined. | A defensible response is to present an earlier not-reachable or no-known-issue result as permanent assurance, and the conclusion about vendor concentration exposure exceeds the available evidence. | A defensible response is to let a scanner or technical owner accept residual exposure without an authorized business owner, and the treatment of vendor concentration exposure remains outside documented governance.

Limitations: One supplier and repository support several critical products with no alternative source or concentration-risk treatment.

Tradeoffs: Assess concentration in suppliers, repositories, cloud services, and maintainers, then establish resilience or alternative-source treatments for material dependencies.

Continuous reassessment

Reassess components after vulnerability disclosure, maintainer transfer, acquisition, license change, integrity failure, new deployment context, or support termination.

Example: The responsible owner should reassess components after disclosures, maintainer transfers, acquisitions, license changes, integrity failures, deployment changes, or support termination.

Counterexample: The responsible owner should prioritize from severity alone while omitting reachability, exposure, privilege, support, and business impact, and material facts about component reassessment remain unexamined. | The responsible owner should frame an earlier not-reachable or no-known-issue result as permanent assurance, and later changes to component reassessment are assumed irrelevant. | The responsible owner should let a scanner or technical owner accept residual exposure without an authorized business owner, and the initial approval for component reassessment becomes effectively permanent.

Limitations: The component was not reassessed after a maintainer transfer and license change materially altered its risk context.

Tradeoffs: Reassess components after disclosures, maintainer transfers, acquisitions, license changes, integrity failures, deployment changes, or support termination.

Third-party update-channel and auto-update risk

Automatic updates can shorten exposure to known vulnerabilities but can also rapidly distribute a compromised supplier release or update service. Govern trusted update endpoints, signature and provenance verification, staged release rings, approval thresholds, emergency disablement, rollback, and monitoring; permanently disabling updates can create a different long-term vulnerability risk.

Example: The security review team should govern automatic updates through trusted endpoints, signature and provenance checks, staged rings, approval thresholds, emergency disablement, rollback, and monitoring.

Counterexample: The security review team should allow package acquisition without binding namespace, source, fallback, and integrity rules, and the control evidence for update channel governance remains partial. | The security review team should take a private registry address as proof that substitution or name confusion cannot affect update-channel governance assurance claim. | The security review team should let developers override source policy without logged approval or later review, and later changes to update channel governance can escape reassessment.

Limitations: Third-party updates are installed immediately from the supplier channel without staged rollout, provenance checks, rollback, or emergency disablement.

Tradeoffs: Govern automatic updates through trusted endpoints, signature and provenance checks, staged rings, approval thresholds, emergency disablement, rollback, and monitoring.

Analyze security of third-party software

Evaluate the security posture, evidence, origin, support, and operational fit of acquired software and services before and during use.

Example: The supplier decision should evaluate the security posture, evidence, origin, support, and operational fit of acquired software and services before and throughout use.

Counterexample: The supplier decision should grant production trust before validating origin, support, responsibilities, data flows, and operating fit, and the released context for third party security is not represented. | The supplier decision should regard paid support or public reputation as conclusive security assurance, and the conclusion about third party security exceeds the available evidence. | The supplier decision should transfer accountability to the supplier because operation is outsourced, ending customer oversight of the third-party security review approval.

Limitations: The service is scheduled for production use before its origin, security evidence, support model, and operational fit are evaluated.

Tradeoffs: Evaluate the security posture, evidence, origin, support, and operational fit of acquired software and services before and throughout use.

Third-party software analysis scope

Analysis can include product architecture, development practices, vulnerability history, dependencies, data flows, deployment model, support, contractual controls, and independent evidence.

Example: Define an analysis scope that covers architecture, development practices, vulnerability history, dependencies, data flows, deployment, support, contracts, and independent evidence.

Counterexample: Grant production trust before validating origin, support, responsibilities, data flows, and operating fit, and material facts about third party remain unexamined. | Frame paid support or public reputation as conclusive security assurance, and third party is treated as settled by supplier reputation, paid support, open-source visibility, or a successful proof of concept. | Transfer accountability to the supplier because operation is outsourced, ending customer oversight of the third-party review scope approval process, and the decision maker for external third party adoption lacks business risk authority.

Limitations: The third-party review is limited to a questionnaire and omits architecture, dependencies, data flows, vulnerability history, and deployment responsibilities.

Tradeoffs: Define an analysis scope that covers architecture, development practices, vulnerability history, dependencies, data flows, deployment, support, contracts, and independent evidence.

Certifications

Certifications provide scoped assurance against defined criteria at a point in time; they do not prove that every product feature or deployment is secure.

Example: The vendor security assessor should use certification as scoped, time-bound evidence and verify the covered product, version, environment, exclusions, assessment date, and continuing applicability.

Counterexample: The vendor security assessor should review the report title and result but omit scope, period, exclusions, exceptions, and customer controls. | The vendor security assessor should interpret a certification, report, or questionnaire as a guarantee, and the stated uncertainty around every deployment covered by the certification is ignored. | The vendor security assessor should let procurement accept residual exposure without local due diligence or accountable ownership, and the exception governing supplier evidence has no defined expiry.

Limitations: A certification is being treated as a guarantee that every feature, version, environment, and future deployment is secure.

Tradeoffs: Use certification as scoped, time-bound evidence and verify the covered product, version, environment, exclusions, assessment date, and continuing applicability.

Certification scope

Evaluate certified product, version, environment, control boundary, exclusions, assessment date, assessor independence, and continuing validity.

Example: Verify the certified product, version, environment, control boundary, exclusions, assessment date, assessor independence, and continuing validity.

Counterexample: Review the report title and result but omit scope, period, exclusions, exceptions, and customer controls. | Regard a certification, report, or questionnaire as a guarantee. | Let procurement accept residual exposure without local due diligence or accountable ownership.

Limitations: The certificate covers a different product version and environment and predates material changes to the service.

Tradeoffs: Verify the certified product, version, environment, control boundary, exclusions, assessment date, assessor independence, and continuing validity.

Certification versus attestation

Certification generally involves assessment against a scheme; attestation is a statement of conformity or control status. Neither replaces local due diligence.

Example: A defensible response is to distinguish scheme-based certification from a party’s attestation and supplement either form with local due diligence and deployment-specific evidence.

Counterexample: A defensible response is to review the report title and result but omit scope, period, exclusions, exceptions, and customer controls, and the control boundary for certification attestation distinction is not fully examined. | A defensible response is to interpret a certification, report, or questionnaire as a guarantee, and the claim about deployment covered by the certification attestation distinction ignores stated limitations. | A defensible response is to let procurement accept residual exposure without local due diligence or accountable ownership, and the exception for certification attestation distinction lacks ownership and review dates.

Limitations: A supplier self-attestation is being described as equivalent to independent certification and local due diligence.

Tradeoffs: Distinguish scheme-based certification from a party’s attestation and supplement either form with local due diligence and deployment-specific evidence.

Assessment reports

Review third-party assessment reports for scope, methodology, exceptions, testing period, control ownership, findings, remediation, and evidence quality.

Example: The acquisition team should review each assessment report for scope, methodology, exceptions, testing period, control ownership, findings, remediation, and evidence quality.

Counterexample: The acquisition team should review the report title and result but omit scope, period, exclusions, exceptions, and customer controls, and important dependencies affecting supplier evidence are not assessed. | The acquisition team should use a certification, report, or questionnaire as a guarantee, and the available signal for every deployment covered by the report is treated as universal proof. | The acquisition team should let procurement accept residual exposure without local due diligence or accountable ownership, and later changes to supplier evidence can escape reassessment.

Limitations: The assessment summary omits methodology, covered period, exceptions, control ownership, remediation, and evidence quality.

Tradeoffs: Review each assessment report for scope, methodology, exceptions, testing period, control ownership, findings, remediation, and evidence quality.

Cloud Controls Matrix

The Cloud Security Alliance Cloud Controls Matrix can structure cloud-control assessment and shared-responsibility analysis.

Example: The next step is to use the Cloud Controls Matrix to structure cloud-control and shared-responsibility analysis, then validate implementation and customer responsibilities.

Counterexample: The next step is to review the report title and result but omit scope, period, exclusions, exceptions, and customer controls, and material facts about cloud control remain unexamined. | The next step is to interpret a certification, report, or questionnaire as a guarantee. | The next step is to let procurement accept residual exposure without local due diligence or accountable ownership, and the final decision on cloud control is assigned to the wrong role.

Limitations: The team completed a Cloud Controls Matrix checklist but did not validate implementation or customer responsibilities.

Tradeoffs: Use the Cloud Controls Matrix to structure cloud-control and shared-responsibility analysis, then validate implementation and customer responsibilities.

SOC reports

SOC reports can provide control evidence, but report type, period, subservice organizations, complementary user controls, exceptions, and management responses matter.

Example: The acquisition team should review the SOC report type, period, scope, exceptions, subservice organizations, complementary user controls, and management responses before relying on it.

Counterexample: The acquisition team should review the report title and result but omit scope, period, exclusions, exceptions, and customer controls, and material facts about SOC report remain unexamined. | The acquisition team should regard a certification, report, or questionnaire as a guarantee, and the claim about every deployment covered by the SOC report ignores stated limitations. | The acquisition team should let procurement accept residual exposure without local due diligence or accountable ownership, and later changes to SOC report can escape reassessment.

Limitations: The SOC report excludes a critical subservice and requires complementary customer controls that have not been implemented.

Tradeoffs: Review the SOC report type, period, scope, exceptions, subservice organizations, complementary user controls, and management responses before relying on it.

Penetration-test report review

A third-party penetration-test summary should be assessed for scope, timing, methodology, tester independence, unresolved findings, retesting, and applicability.

Example: The responsible owner should review the penetration-test report’s scope, timing, methodology, tester independence, unresolved findings, retesting, and applicability to the proposed use.

Counterexample: The responsible owner should review the report title and result but omit scope, period, exclusions, exceptions, and customer controls, and material facts about penetration report remain unexamined. | The responsible owner should frame a certification, report, or questionnaire as a guarantee, and the claim about every deployment covered by the penetration report ignores stated limitations. | The responsible owner should let procurement accept residual exposure without local due diligence or accountable ownership, and the treatment of penetration report remains outside documented governance.

Limitations: The penetration-test summary covers an old version, a narrow interface, and unresolved findings without retest evidence.

Tradeoffs: Review the penetration-test report’s scope, timing, methodology, tester independence, unresolved findings, retesting, and applicability to the proposed use.

Origin and support

Determine where software originated, who maintains it, how updates are delivered, how vulnerabilities are handled, and whether support will remain available.

Example: The security review team should determine the software’s origin, maintainer, update path, vulnerability-handling process, and expected duration of support.

Counterexample: The security review team should grant production trust before validating origin, support, responsibilities, data flows, and operating fit. | The security review team should take paid support or public reputation as conclusive security assurance, and one bounded result is used to approve every use of publisher lineage and maintenance. | The security review team should transfer accountability to the supplier because operation is outsourced, ending customer oversight of publisher lineage and maintenance approval path.

Limitations: The organization cannot establish the software publisher, maintainer, update path, vulnerability process, or remaining support life.

Tradeoffs: Determine the software’s origin, maintainer, update path, vulnerability-handling process, and expected duration of support.

Software origin

Origin includes source repository, publisher, signing identity, build path, distribution channel, and custody history—not merely a download URL.

Example: The supplier decision should establish origin from the source repository, publisher, signing identity, build path, distribution channel, and custody history rather than a download URL alone.

Counterexample: The supplier decision should grant production trust before validating origin, support, responsibilities, data flows, and operating fit. | Present paid support or public reputation as conclusive security assurance and skip local artifact-origin due diligence. | The supplier decision should transfer accountability to the supplier because operation is outsourced, ending customer oversight of the artifact origin approval process, and the approval of data sensitive third party adoption persists without later review.

Limitations: A download URL is being accepted as sufficient proof of repository, publisher, signing identity, build path, and custody history.

Tradeoffs: Establish origin from the source repository, publisher, signing identity, build path, distribution channel, and custody history rather than a download URL alone.

Commercial support

Commercial support may offer contractual response, updates, warranties, and escalation, but it does not automatically imply stronger security.

Example: Evaluate the continuity-critical third-party adoption decision for the customer identity platform by its contractual response, update, warranty, escalation, and continuity capabilities without assuming that payment guarantees stronger security.

Counterexample: Grant production trust before validating origin, support, responsibilities, data flows, and operating fit, and the stated scope for commercial support evaluation omits relevant dependencies. | Regard paid support or public reputation as conclusive security assurance, and commercial support evaluation is treated as settled by supplier reputation, paid support, open-source visibility, or a successful proof of concept. | Transfer accountability to the supplier because operation is outsourced, ending customer oversight of the commercial-support evaluation approval, and changes affecting continuity critical third party adoption can bypass renewed authorization.

Limitations: Commercial support is being treated as automatic evidence that the product is more secure than community-supported alternatives.

Tradeoffs: Evaluate the continuity-critical third-party adoption decision for the customer identity platform by its contractual response, update, warranty, escalation, and continuity capabilities without assuming that payment guarantees stronger security.

Community support

Community-supported software may be transparent and well maintained, but risk depends on governance, maintainer capacity, release discipline, and response history.

Example: The cloud assurance lead should evaluate the legacy third-party adoption decision for the public-sector case-management system through governance, maintainer capacity, release discipline, transparency, and vulnerability-response history.

Counterexample: The cloud assurance lead should grant production trust before validating origin, support, responsibilities, data flows, and operating fit, and the assessment of community support evaluation excludes architecture, dependencies, data flows, update channels, support history, and shared responsibilities. | The cloud assurance lead should take paid support or public reputation as conclusive security assurance, and limited evidence for community support evaluation is generalized across unassessed changes. | The cloud assurance lead should transfer accountability to the supplier because operation is outsourced, ending customer oversight of community-support evaluation approval path, and the organization has no accountable owner for legacy third party adoption.

Limitations: A community-supported component is being rejected solely because it lacks a commercial vendor, without reviewing governance or response history.

Tradeoffs: Evaluate the legacy third-party adoption decision for the public-sector case-management system through governance, maintainer capacity, release discipline, transparency, and vulnerability-response history.

Security questionnaire

Questionnaires collect supplier claims efficiently but require validation, risk-based follow-up, and evidence for material controls.

Example: Validate material questionnaire claims with risk-based follow-up and evidence rather than accepting the supplier’s answers at face value.

Counterexample: Review the report title and result but omit scope, period, exclusions, exceptions, and customer controls, and material facts about questionnaire validation remain unexamined. | Regard a certification, report, or questionnaire as a guarantee, and later changes to every deployment covered by the questionnaire validation are assumed irrelevant. | Let procurement accept residual exposure without local due diligence or accountable ownership, and later changes to questionnaire validation can escape reassessment.

Limitations: Material supplier questionnaire answers are being accepted without reports, artifacts, demonstrations, interviews, or other validation.

Tradeoffs: Validate material questionnaire claims with risk-based follow-up and evidence rather than accepting the supplier’s answers at face value.

Proof of concept and sandbox evaluation

Evaluate unknown or high-risk software in an isolated environment before granting production data, identities, network access, or trust.

Example: A defensible response is to evaluate unknown or high-risk software in an isolated environment before granting production data, identities, network access, or trust.

Counterexample: A defensible response is to grant production trust before validating origin, support, responsibilities, data flows, and operating fit, and material facts about sandbox evaluation remain unexamined. | A defensible response is to interpret paid support or public reputation as conclusive security assurance. | A defensible response is to transfer accountability to the supplier because operation is outsourced, ending customer oversight of ongoing sandbox evaluation oversight.

Limitations: Unknown software will receive production data, credentials, and network access before isolated evaluation.

Tradeoffs: Evaluate unknown or high-risk software in an isolated environment before granting production data, identities, network access, or trust.

Shared responsibility analysis

Cloud and managed-service security depends on explicit division of responsibilities; outsourced operation does not outsource accountability.

Example: The acquisition team should define explicit cloud and managed-service responsibilities for supplier and customer while retaining the organization’s accountability.

Counterexample: The acquisition team should grant production trust before validating origin, support, responsibilities, data flows, and operating fit, and material facts about shared responsibility allocation remain unexamined. | The acquisition team should regard paid support or public reputation as conclusive security assurance. | The acquisition team should transfer accountability to the supplier because operation is outsourced, ending customer oversight of the shared-responsibility allocation approval.

Limitations: The managed-service provider operates the platform, so the customer assumes it retains no configuration, monitoring, or response responsibilities.

Tradeoffs: Define explicit cloud and managed-service responsibilities for supplier and customer while retaining the organization’s accountability.

Residual third-party risk

After assessment and treatment, residual risk must be owned, monitored, and reconsidered when supplier or operating conditions change.

Example: The next step is to assign the multi-tenant component risk decision for the software distribution portal to an authorized owner, monitor it, and reconsider it when supplier or operating conditions change.

Counterexample: The next step is to prioritize from severity alone while omitting reachability, exposure, privilege, support, and business impact, and the record supporting remaining supplier exposure omits relevant versions and environments. | The next step is to interpret an earlier not-reachable or no-known-issue result as permanent assurance, and remaining supplier exposure is treated as settled by a severity score, clean scan, or earlier not-reachable conclusion. | The next step is to let a scanner or technical owner accept residual exposure without an authorized business owner, and the approval path for remaining supplier exposure bypasses escalation and reconciliation.

Limitations: Residual supplier risk has no accountable owner or review trigger after the service and operating conditions changed.

Tradeoffs: Assign the multi-tenant component risk decision for the software distribution portal to an authorized owner, monitor it, and reconsider it when supplier or operating conditions change.

Verify pedigree and provenance

Establish and verify the origin, custody, transformation history, authenticity, and integrity of software and related artifacts.

Example: The responsible owner should establish and verify origin, custody, transformation history, authenticity, and integrity for software and related artifacts.

Counterexample: The responsible owner should use a download location or repository name without producer, inputs, transformations, or custody evidence. | The responsible owner should frame an authenticated channel or one signature as complete source-to-artifact assurance, and the organization assumes lineage and provenance verification needs no further validation. | The responsible owner should extend trust from one supplier to all subcontractors and connected systems participating in the lineage and provenance verification approval process.

Limitations: The released artifact cannot be traced reliably to its origin, custody, inputs, transformations, and integrity evidence.

Tradeoffs: Establish and verify origin, custody, transformation history, authenticity, and integrity for software and related artifacts.

Pedigree

Pedigree describes the history, ownership, quality, and development lineage of a component or artifact.

Example: The responsible owner should document the component’s ownership, development history, quality record, and lineage rather than limiting the record to its current location.

Counterexample: The responsible owner should use a download location or repository name without producer, inputs, transformations, or custody evidence, and important dependencies affecting component lineage are not assessed. | The responsible owner should present an authenticated channel or one signature as complete source-to-artifact assurance. | The responsible owner should extend trust from one supplier to all subcontractors and connected systems participating in the component lineage approval process.

Limitations: The pedigree record lists the current owner and version but omits development lineage, quality history, and prior custody.

Tradeoffs: Document the component’s ownership, development history, quality record, and lineage rather than limiting the record to its current location.

Provenance

Provenance records where an artifact came from, how and by whom it was produced, inputs used, and transformations applied.

Example: The security review team should record the artifact source, producer, inputs, build parameters, environment, and transformations so the released output can be traced and verified.

Counterexample: The security review team should use a download location or repository name without producer, inputs, transformations, or custody evidence. | The security review team should use an authenticated channel or one signature as complete source-to-artifact assurance. | The security review team should extend trust from one supplier to all subcontractors and connected systems participating in the artifact production history approval lifecycle.

Limitations: The provenance statement omits the builder identity, source inputs, dependencies, parameters, and transformations used for the release.

Tradeoffs: Record the artifact source, producer, inputs, build parameters, environment, and transformations so the released output can be traced and verified.

Secure transfer

Protect software and metadata during transfer against substitution, tampering, interception, replay, and unauthorized access.

Example: The supplier decision should protect software and metadata in transit against substitution, tampering, interception, replay, and unauthorized access.

Counterexample: The supplier decision should use a download location or repository name without producer, inputs, transformations, or custody evidence, and material facts about artifact transfer protection remain unexamined. | The supplier decision should regard an authenticated channel or one signature as complete source-to-artifact assurance, and a scoped assertion about artifact transfer protection becomes complete assurance. | The supplier decision should extend trust from one supplier to all subcontractors and connected systems participating in the artifact transfer protection approval.

Limitations: Software and metadata are transferred over a path that permits interception, replay, substitution, or unauthorized access.

Tradeoffs: Protect software and metadata in transit against substitution, tampering, interception, replay, and unauthorized access.

Chain of custody

Chain of custody documents possession, transfer, handling, and control of artifacts so unauthorized substitution or gaps can be detected.

Example: Record each possession, transfer, handler, time, and control point so custody gaps or unauthorized substitutions can be detected.

Counterexample: Use a download location or repository name without producer, inputs, transformations, or custody evidence, and material facts about artifact custody remain unexamined. | Use an authenticated channel or one signature as complete source-to-artifact assurance, and the claim about artifact custody is generalized to later versions. | Extend trust from one supplier to all subcontractors and connected systems participating in the artifact custody approval lifecycle.

Limitations: The artifact changed hands through an undocumented custody gap before reaching the controlled repository.

Tradeoffs: Record each possession, transfer, handler, time, and control point so custody gaps or unauthorized substitutions can be detected.

Authenticity during transfer

Verify that an artifact came from the claimed source using trusted identities, signatures, certificates, channels, or repository controls.

Example: The provenance assurance lead should verify the claimed source through trusted identities, signatures, certificates, authenticated channels, or controlled repositories.

Counterexample: The provenance assurance lead should use a download location or repository name without producer, inputs, transformations, or custody evidence, and material facts about transfer authenticity remain unexamined. | The provenance assurance lead should regard an authenticated channel or one signature as complete source-to-artifact assurance, and independent validation of transfer authenticity is skipped. | The provenance assurance lead should extend trust from one supplier to all subcontractors and connected systems participating in the transfer authenticity approval.

Limitations: The artifact came from a familiar URL, but no trusted identity, signature, certificate, or repository control establishes the claimed source.

Tradeoffs: Verify the claimed source through trusted identities, signatures, certificates, authenticated channels, or controlled repositories.

Integrity during transfer

Use cryptographic hashes, signatures, authenticated channels, and controlled storage to detect unauthorized modification.

Example: A defensible response is to use trusted hashes, signatures, authenticated channels, and controlled storage to detect unauthorized changes during transfer.

Counterexample: A defensible response is to use a download location or repository name without producer, inputs, transformations, or custody evidence, and material facts about transfer integrity remain unexamined. | A defensible response is to present an authenticated channel or one signature as complete source-to-artifact assurance, and independent validation of transfer integrity is skipped. | A defensible response is to extend trust from one supplier to all subcontractors and connected systems participating in the transfer integrity approval process.

Limitations: The expected hash is obtained from the same untrusted location as the artifact and therefore cannot establish a trusted integrity reference.

Tradeoffs: Use trusted hashes, signatures, authenticated channels, and controlled storage to detect unauthorized changes during transfer.

System sharing and interconnections

Evaluate supply-chain risk created by shared services, repositories, identities, data exchanges, APIs, and interconnected build or delivery systems.

Example: A defensible response is to assess risks from shared services, repositories, identities, data exchanges, APIs, and interconnected build or delivery systems.

Counterexample: A defensible response is to evaluate the relationship at acquisition but omit support changes, testing scope, logging, subcontractors, and exit obligations, and the review of interconnection risk omits material supplier conditions. | A defensible response is to interpret a clean track record or available telemetry as complete assurance, and the claim about interconnection risk ignores stated limitations. | A defensible response is to continue after material supplier changes without reassessment, transition planning, or accountable approval, and later changes to interconnection risk can escape reassessment.

Limitations: An interconnected build service shares privileged identities and repositories without explicit trust boundaries or responsibility analysis.

Tradeoffs: Assess risks from shared services, repositories, identities, data exchanges, APIs, and interconnected build or delivery systems.

Trust transitivity

Trust in one supplier or connection should not automatically extend to all of its subcontractors, dependencies, tenants, or connected systems.

Example: The acquisition team should validate subcontractors, dependencies, tenants, and connected systems independently rather than extending a supplier’s trust transitively.

Counterexample: The acquisition team should evaluate the relationship at acquisition but omit support changes, testing scope, logging, subcontractors, and exit obligations. | Interpret a clean track record or available telemetry as complete assurance and treat one transitive-trust signal as contextually complete evidence. | Continue after material supplier changes without reassessment, transition planning, or accountable approval, and assign no accountable owner to transitive-trust decisions.

Limitations: Trust in the prime supplier is being extended automatically to its subcontractors, dependencies, tenants, and connected systems.

Tradeoffs: Validate subcontractors, dependencies, tenants, and connected systems independently rather than extending a supplier’s trust transitively.

Code repository security

Protect repositories with strong identity, least privilege, branch protection, signed changes, review, audit, secret scanning, and recovery.

Example: The next step is to protect repositories with strong identity, least privilege, branch protection, signed changes, review, audit, secret scanning, and tested recovery.

Counterexample: The next step is to allow package acquisition without binding namespace, source, fallback, and integrity rules, and material facts about repository protection remain unexamined. | The next step is to interpret a private registry address as proof that substitution or name confusion cannot affect the repository protection assurance conclusion. | The next step is to let developers override source policy without logged approval or later review, and customer accountability for repository protection is transferred to the supplier.

Limitations: Repository administrators can bypass branch protection, alter integrations, and rewrite history without separation, monitoring, or recovery controls.

Tradeoffs: Protect repositories with strong identity, least privilege, branch protection, signed changes, review, audit, secret scanning, and tested recovery.

Repository administrator risk

Repository administrators can alter history, permissions, protections, and integrations; privileged actions require separation, monitoring, and recovery controls.

Example: The responsible owner should separate and monitor repository administrator privileges, protect recovery paths, and review changes to history, permissions, branch controls, and integrations.

Counterexample: The responsible owner should allow package acquisition without binding namespace, source, fallback, and integrity rules, and repository-administrator privileges remain outside the control evidence. | The responsible owner should interpret a private registry address as proof that substitution or name confusion cannot affect the repository-admin control assurance conclusion. | The responsible owner should let developers override source policy without logged approval or later review, and later changes to repository admin control can escape reassessment.

Limitations: A repository administrator can change permissions and history without independent logging, review, or tested recovery.

Tradeoffs: Separate and monitor repository administrator privileges, protect recovery paths, and review changes to history, permissions, branch controls, and integrations.

Commit signing

Signed commits or tags help attribute changes and detect substitution, but signature trust, key protection, review, and build provenance remain necessary.

Example: The responsible owner should verify signed commits or tags against trusted identities while retaining review, key-protection, repository, and build-provenance controls.

Counterexample: The responsible owner should rely on one signature, hash, or build property without verifying signer trust, inputs, runners, caches, or provenance, and important dependencies affecting signed source attribution are not assessed. | The responsible owner should take a hermetic, ephemeral, signed, or reproducible build as proof that the source is secure, and the claim about signed source attribution ignores stated limitations. | The responsible owner should override failed integrity evidence without policy-defined rejection, quarantine, escalation, or exception authority, and the organization cannot enforce ownership of signed source attribution.

Limitations: A signed commit is accepted without validating signer trust, key protection, code review, or the build provenance of the released artifact.

Tradeoffs: Verify signed commits or tags against trusted identities while retaining review, key-protection, repository, and build-provenance controls.

Build environment security

Protect build hosts, runners, toolchains, dependencies, caches, credentials, network access, and outputs from tampering and unauthorized influence.

Example: The security review team should protect build hosts, runners, toolchains, dependencies, caches, credentials, network access, and outputs from unauthorized influence.

Counterexample: The security review team should rely on one signature, hash, or build property without verifying signer trust, inputs, runners, caches, or provenance. | The security review team should use a hermetic, ephemeral, signed, or reproducible build as proof that the source is secure, and the claim about build environment protection ignores stated limitations. | The security review team should override failed integrity evidence without policy-defined rejection, quarantine, escalation, or exception authority, and later changes to build environment protection can escape reassessment.

Limitations: Shared runners, caches, credentials, and unrestricted network access can influence the build without verifiable isolation.

Tradeoffs: Protect build hosts, runners, toolchains, dependencies, caches, credentials, network access, and outputs from unauthorized influence.

Hermetic build

A hermetic build uses declared, controlled inputs and limited external dependencies, improving reproducibility and provenance without guaranteeing secure source code.

Example: The supplier decision should build from declared controlled inputs with restricted external access, and treat hermeticity as provenance support rather than proof of secure source code.

Counterexample: The supplier decision should rely on one signature, hash, or build property without verifying signer trust, inputs, runners, caches, or provenance. | The supplier decision should use a hermetic, ephemeral, signed, or reproducible build as proof that the source is secure, and independent validation of hermetic build is skipped. | The supplier decision should override failed integrity evidence without policy-defined rejection, quarantine, escalation, or exception authority, and later changes to hermetic build can escape reassessment.

Limitations: A hermetic build is being treated as proof that the source code has no vulnerabilities or malicious logic.

Tradeoffs: Build from declared controlled inputs with restricted external access, and treat hermeticity as provenance support rather than proof of secure source code.

Ephemeral build runner

Short-lived runners can reduce persistence and cross-build contamination but still require trusted images, isolation, least privilege, and secure secrets.

Example: Use trusted, isolated, least-privileged ephemeral runners with securely delivered secrets and controlled images.

Counterexample: Rely on one signature, hash, or build property without verifying signer trust, inputs, runners, caches, or provenance, and material facts about ephemeral runner remain unexamined. | Interpret a hermetic, ephemeral, signed, or reproducible build as proof that the source is secure. | Override failed integrity evidence without policy-defined rejection, quarantine, escalation, or exception authority.

Limitations: Short-lived runners use an untrusted base image and shared secrets that can contaminate multiple builds.

Tradeoffs: Use trusted, isolated, least-privileged ephemeral runners with securely delivered secrets and controlled images.

Build cache poisoning

Attackers may inject malicious or stale content into shared caches; keys, scope, integrity, invalidation, and provenance must be controlled.

Example: The build security engineer should protect shared build caches with scoped keys, integrity verification, provenance, invalidation, and isolation against malicious or stale content.

Counterexample: The build security engineer should rely on one signature, hash, or build property without verifying signer trust, inputs, runners, caches, or provenance, and the acquisition evidence for build cache integrity is incomplete. | The build security engineer should present a hermetic, ephemeral, signed, or reproducible build as proof that the source is secure, and the bounded finding on build cache integrity is treated as permanent. | The build security engineer should override failed integrity evidence without policy-defined rejection, quarantine, escalation, or exception authority, and later changes to build cache integrity can escape reassessment.

Limitations: A shared build cache accepts entries without scoped keys, integrity checks, provenance, or reliable invalidation.

Tradeoffs: Protect shared build caches with scoped keys, integrity verification, provenance, invalidation, and isolation against malicious or stale content.

Cryptographically hashed components

Hashes enable integrity comparison but do not identify a trustworthy publisher unless the expected hash is obtained securely.

Example: A defensible response is to compare the component with an expected hash obtained through a trusted channel and use separate evidence to establish publisher identity.

Counterexample: A defensible response is to rely on one signature, hash, or build property without verifying signer trust, inputs, runners, caches, or provenance, and material facts about trusted hash verification remain unexamined. | A defensible response is to interpret a hermetic, ephemeral, signed, or reproducible build as proof that the source is secure, and the claim about trusted hash verification ignores stated limitations. | A defensible response is to override failed integrity evidence without policy-defined rejection, quarantine, escalation, or exception authority, and the approval path for trusted hash verification bypasses escalation and reconciliation.

Limitations: A component matches a hash published beside the download, but the expected value was not obtained through a trusted path.

Tradeoffs: Compare the component with an expected hash obtained through a trusted channel and use separate evidence to establish publisher identity.

Digitally signed components

Digital signatures bind artifact integrity to a signing identity, subject to key protection, certificate trust, timestamping, revocation, and verification.

Example: A defensible response is to verify the signature, signer trust, certificate status, timestamp, and key protection before accepting the component.

Counterexample: A defensible response is to rely on one signature, hash, or build property without verifying signer trust, inputs, runners, caches, or provenance, and controls governing signature verification are only partially assessed. | A defensible response is to use a hermetic, ephemeral, signed, or reproducible build as proof that the source is secure. | A defensible response is to override failed integrity evidence without policy-defined rejection, quarantine, escalation, or exception authority, and later changes to signature verification can escape reassessment.

Limitations: The artifact has a mathematically valid signature, but signer trust, certificate status, timestamp, and key protection were not verified.

Tradeoffs: Verify the signature, signer trust, certificate status, timestamp, and key protection before accepting the component.

Signature verification failure

A missing, invalid, expired, revoked, or untrusted signature should trigger policy-defined rejection, quarantine, or escalation.

Example: The acquisition team should reject, quarantine, or escalate components with missing, invalid, expired, revoked, or untrusted signatures according to policy.

Counterexample: The acquisition team should rely on one signature, hash, or build property without verifying signer trust, inputs, runners, caches, or provenance, and material facts about signature failure handling remain unexamined. | The acquisition team should present a hermetic, ephemeral, signed, or reproducible build as proof that the source is secure, and independent validation of signature failure handling is skipped. | The acquisition team should override failed integrity evidence without policy-defined rejection, quarantine, escalation, or exception authority.

Limitations: A missing or untrusted signature is being overridden without the rejection, quarantine, escalation, or exception path required by policy.

Tradeoffs: Reject, quarantine, or escalate components with missing, invalid, expired, revoked, or untrusted signatures according to policy.

Right to audit

Contractual audit rights allow verification of supplier controls, records, facilities, development practices, or relevant evidence.

Example: The next step is to define contractual audit rights that permit verification of relevant supplier controls, records, facilities, development practices, and evidence.

Counterexample: The next step is to use supplier policy or machine-readable data without validating implementation and effectiveness, and the supplier record for supplier audit right omits relevant control details. | The next step is to interpret one audit clause or control format as complete independent assurance, and limited evidence for supplier audit right is generalized across unassessed changes. | The next step is to let the supplier define evidence sufficiency and remediation closure without customer verification, and the supplier controls acceptance of supplier audit right without customer authority.

Limitations: The contract contains a right-to-audit sentence but does not identify accessible controls, records, facilities, practices, or evidence.

Tradeoffs: Define contractual audit rights that permit verification of relevant supplier controls, records, facilities, development practices, and evidence.

Audit-right practicality

Audit rights require defined scope, notice, frequency, confidentiality, subcontractor coverage, remediation, and access to meaningful evidence.

Example: The responsible owner should make audit rights usable by defining scope, notice, frequency, confidentiality, subcontractor coverage, remediation, and access to meaningful evidence.

Counterexample: The responsible owner should use supplier policy or machine-readable data without validating implementation and effectiveness. | The responsible owner should frame one audit clause or control format as complete independent assurance, and the evidence for workable audit right is extended beyond its assessed environment. | The responsible owner should let the supplier define evidence sufficiency and remediation closure without customer verification, and later changes to workable audit right can escape reassessment.

Limitations: The audit clause omits subcontractor coverage, notice, frequency, confidentiality, evidence access, and remediation obligations.

Tradeoffs: Make audit rights usable by defining scope, notice, frequency, confidentiality, subcontractor coverage, remediation, and access to meaningful evidence.

SLSA provenance

Supply-chain Levels for Software Artifacts (SLSA) is a versioned, track-specific framework for progressively stronger supply-chain integrity evidence. As of this archive, SLSA v1.2 defines Build and Source tracks. Durable exam reasoning should focus on provenance, verification, source controls, build isolation, and increasing assurance rather than memorizing an unqualified universal level ladder. SLSA evidence does not prove that source code is free from vulnerabilities or malicious logic.

Example: The responsible owner should evaluate current track-specific SLSA evidence for provenance, source controls, and build isolation without treating it as proof that the source is vulnerability-free.

Counterexample: The responsible owner should use a download location or repository name without producer, inputs, transformations, or custody evidence, and the build-provenance record omits source and transformation evidence. | The responsible owner should frame an authenticated channel or one signature as complete source-to-artifact assurance, and later changes to artifact lineage are assumed irrelevant. | The responsible owner should extend trust from one supplier to all subcontractors and connected systems participating in the SLSA evidence approval process.

Limitations: The supplier cites an obsolete universal SLSA level and treats it as proof that the source is vulnerability-free.

Tradeoffs: Evaluate current track-specific SLSA evidence for provenance, source controls, and build isolation without treating it as proof that the source is vulnerability-free.

Source provenance versus binary and build provenance

Source provenance establishes where source originated, who changed it, and which review and version-control history applies. Build or binary provenance links a released artifact to source inputs, dependencies, parameters, and a build environment. A valid binary signature establishes signer identity and post-signing integrity but does not by itself prove a complete, trustworthy source-to-binary chain.

Example: The security review team should verify source history separately from the build record that links released binaries to source, dependencies, parameters, and the build environment.

Counterexample: The security review team should use a download location or repository name without producer, inputs, transformations, or custody evidence, and material facts about source to binary provenance remain unexamined. | The security review team should regard an authenticated channel or one signature as complete source-to-artifact assurance, and independent validation of source to binary provenance is skipped. | The security review team should extend trust from one supplier to all subcontractors and connected systems participating in the source-to-binary provenance approval.

Limitations: A signed binary is being treated as proof of complete source history and a trustworthy source-to-build chain.

Tradeoffs: Verify source history separately from the build record that links released binaries to source, dependencies, parameters, and the build environment.

Reproducible build

Independent reproduction can detect some build tampering when source, toolchain, environment, and process are sufficiently controlled.

Example: The supplier decision should rebuild the artifact independently under controlled inputs and compare outputs to detect some classes of build tampering.

Counterexample: The supplier decision should rely on one signature, hash, or build property without verifying signer trust, inputs, runners, caches, or provenance, and the stated scope for reproducible build omits relevant dependencies. | The supplier decision should present a hermetic, ephemeral, signed, or reproducible build as proof that the source is secure, and independent validation of reproducible build is skipped. | The supplier decision should override failed integrity evidence without policy-defined rejection, quarantine, escalation, or exception authority, and later changes to reproducible build can escape reassessment.

Limitations: A successful independent rebuild is being treated as proof that the source, design, and build process are secure in every respect.

Tradeoffs: Rebuild the artifact independently under controlled inputs and compare outputs to detect some classes of build tampering.

Ensure and verify supplier security requirements in the acquisition process

Define, evaluate, contract for, and verify supplier security obligations before acquisition and throughout the relationship.

Example: Define, evaluate, contract for, and verify supplier security obligations before acquisition and throughout the relationship.

Counterexample: Use supplier policy or machine-readable data without validating implementation and effectiveness. | Frame one audit clause or control format as complete independent assurance, and later changes to supplier controls are assumed irrelevant. | Let the supplier define evidence sufficiency and remediation closure without customer verification, and customer accountability for supplier controls is transferred to the supplier.

Limitations: The acquisition is proceeding without binding supplier obligations, verification evidence, remedies, or ongoing assurance requirements.

Tradeoffs: Define, evaluate, contract for, and verify supplier security obligations before acquisition and throughout the relationship.

Supplier due diligence

Evaluate ownership, financial stability, security governance, development process, incident history, subcontractors, support, and legal or geopolitical exposure.

Example: The third-party risk manager should perform due diligence on ownership, financial stability, security governance, development practices, incident history, subcontractors, support, and legal or geopolitical exposure.

Counterexample: The third-party risk manager should use supplier policy or machine-readable data without validating implementation and effectiveness, and material facts about vendor background remain unexamined. | The third-party risk manager should present one audit clause or control format as complete independent assurance, and the limitations of the evidence for vendor background are not considered. | The third-party risk manager should let the supplier define evidence sufficiency and remediation closure without customer verification, and the governance of vendor background omits exception approval and review dates.

Limitations: Due diligence omits ownership, financial stability, subcontractors, incident history, and legal or geopolitical exposure.

Tradeoffs: Perform due diligence on ownership, financial stability, security governance, development practices, incident history, subcontractors, support, and legal or geopolitical exposure.

Audit of security policy compliance

Verify that suppliers follow required security policies, standards, and secure development practices using evidence proportional to risk.

Example: The supplier decision should verify supplier compliance with required policies, standards, and secure-development practices using evidence proportional to risk.

Counterexample: The supplier decision should use supplier policy or machine-readable data without validating implementation and effectiveness, and important dependencies affecting supplier policy compliance are not assessed. | The supplier decision should interpret one audit clause or control format as complete independent assurance. | The supplier decision should let the supplier define evidence sufficiency and remediation closure without customer verification.

Limitations: The supplier states that it follows required policies, but no risk-proportionate evidence verifies compliance.

Tradeoffs: Verify supplier compliance with required policies, standards, and secure-development practices using evidence proportional to risk.

Secure software development practices

Supplier requirements may address threat modeling, secure coding, code review, testing, dependency management, build security, disclosure, and remediation.

Example: A defensible response is to require supplier practices covering threat modeling, secure coding, review, testing, dependency management, build security, disclosure, and remediation.

Counterexample: A defensible response is to use supplier policy or machine-readable data without validating implementation and effectiveness, and material facts about supplier development practices remain unexamined. | A defensible response is to interpret one audit clause or control format as complete independent assurance, and the evidence for supplier development practices is extended beyond its assessed environment. | A defensible response is to let the supplier define evidence sufficiency and remediation closure without customer verification, and the supplier retains authority over supplier development practices that belongs to the customer.

Limitations: The supplier claims to use secure development practices but provides no evidence for modeling, coding, review, testing, dependencies, or build security.

Tradeoffs: Require supplier practices covering threat modeling, secure coding, review, testing, dependency management, build security, disclosure, and remediation.

Evidence-based verification

Policies and questionnaires are claims; higher-risk acquisition may require reports, artifacts, interviews, demonstrations, tests, or audit evidence.

Example: The acquisition team should treat policies and questionnaires as claims and obtain reports, artifacts, interviews, demonstrations, tests, or audit evidence in proportion to risk.

Counterexample: The acquisition team should evaluate the relationship at acquisition but omit support changes, testing scope, logging, subcontractors, and exit obligations, and material facts about based supplier verification remain unexamined. | The acquisition team should frame a clean track record or available telemetry as complete assurance, and the signal supporting based supplier verification is applied to untested conditions. | The acquisition team should continue after material supplier changes without reassessment, transition planning, or accountable approval, and the initial approval for based supplier verification becomes effectively permanent.

Limitations: Policies and questionnaire responses are being accepted as proof that material controls are implemented and effective.

Tradeoffs: Treat policies and questionnaires as claims and obtain reports, artifacts, interviews, demonstrations, tests, or audit evidence in proportion to risk.

Open Security Controls Assessment Language

OSCAL is a NIST-led set of machine-readable XML, JSON, and YAML models for representing control catalogs, profiles, system security plans, assessment plans, assessment results, and related control evidence. In acquisition and supplier assurance, OSCAL can improve interoperability and automate exchange or validation of control information, but machine-readable formatting does not independently prove that controls are implemented or effective.

Example: The next step is to use OSCAL to exchange and validate structured control or assessment information while independently verifying that represented controls operate effectively.

Counterexample: The next step is to assess functionality and cost but omit provenance, licensing, support, and security criteria, and the control evidence for OSCAL exchange remains partial. | The next step is to frame one framework label or approved source as conclusive assurance, and the supplier statement on OSCAL exchange is treated as independent proof. | The next step is to let the component team finalize the decision without business risk ownership or ongoing oversight, and the acceptance of OSCAL exchange occurs outside accountable governance.

Limitations: A machine-readable OSCAL package is being treated as independent proof that the supplier controls operate effectively.

Tradeoffs: Use OSCAL to exchange and validate structured control or assessment information while independently verifying that represented controls operate effectively.

Vulnerability and incident notification, response, coordination, and reporting

This compound official subtopic establishes the supplier-assurance requirement to define timely notification, coordinated response, and appropriate reporting for vulnerabilities and security incidents. The following nodes separate those obligations for independently testable acquisition and contract scenarios.

Example: A defensible response is to define contractually how suppliers notify, coordinate, respond, and report for vulnerabilities and incidents, including timing, scope, evidence, and responsibilities.

Counterexample: A defensible response is to define notification without thresholds, timing, channels, evidence, updates, or affected-party coordination. | A defensible response is to interpret an initial supplier statement as complete impact and recovery evidence, and the claim about supplier incident obligations ignores stated limitations. | A defensible response is to let the supplier control disclosure and closure without customer escalation, validation, or residual-risk review.

Limitations: The contract mentions notification but does not define coordinated response, evidence sharing, reporting, communication, or recovery responsibilities.

Tradeoffs: Define contractually how suppliers notify, coordinate, respond, and report for vulnerabilities and incidents, including timing, scope, evidence, and responsibilities.

Vulnerability and incident notification

Contracts should define what must be reported, severity thresholds, timing, channels, content, updates, and affected-customer coordination.

Example: The responsible owner should define reportable conditions, severity thresholds, notification timing, channels, required content, updates, and affected-customer coordination.

Counterexample: The responsible owner should define notification without thresholds, timing, channels, evidence, updates, or affected-party coordination, and material facts about supplier incident notice remain unexamined. | The responsible owner should regard an initial supplier statement as complete impact and recovery evidence, and independent validation of supplier incident notice is skipped. | The responsible owner should let the supplier control disclosure and closure without customer escalation, validation, or residual-risk review, and the approval for supplier incident notice lacks escalation, expiry, and reassessment.

Limitations: The notification clause lacks reportable conditions, severity thresholds, timing, channels, content, updates, and customer coordination.

Tradeoffs: Define reportable conditions, severity thresholds, notification timing, channels, required content, updates, and affected-customer coordination.

Response coordination

Supplier and customer should define containment, evidence sharing, remediation, communication, disclosure, and recovery responsibilities.

Example: The security review team should assign supplier and customer responsibilities for containment, evidence sharing, remediation, communication, disclosure, and recovery.

Counterexample: The security review team should define notification without thresholds, timing, channels, evidence, updates, or affected-party coordination. | The security review team should interpret an initial supplier statement as complete impact and recovery evidence, and the conclusion for joint incident handling is not revalidated after change. | The security review team should let the supplier control disclosure and closure without customer escalation, validation, or residual-risk review, and later changes to joint incident handling can escape reassessment.

Limitations: Supplier and customer teams disagree about containment, evidence sharing, remediation, disclosure, communication, and recovery ownership.

Tradeoffs: Assign supplier and customer responsibilities for containment, evidence sharing, remediation, communication, disclosure, and recovery.

Reporting obligations

Reports should identify affected products and versions, impact, indicators, mitigations, fixes, timelines, and residual risk as appropriate.

Example: The supplier decision should require reports to identify affected products and versions, impact, indicators, mitigations, fixes, timelines, and relevant residual risk.

Counterexample: The supplier decision should define notification without thresholds, timing, channels, evidence, updates, or affected-party coordination, and the decision on supplier reporting lacks sufficient supporting evidence. | The supplier decision should regard an initial supplier statement as complete impact and recovery evidence. | The supplier decision should let the supplier control disclosure and closure without customer escalation, validation, or residual-risk review, and the supplier retains authority over supplier reporting that belongs to the customer.

Limitations: The supplier report omits affected versions, impact, indicators, mitigations, fixes, timelines, and remaining risk.

Tradeoffs: Require reports to identify affected products and versions, impact, indicators, mitigations, fixes, timelines, and relevant residual risk.

Maintenance and support structure

Evaluate how updates, vulnerability handling, escalation, documentation, expertise, and lifecycle support are provided.

Example: Evaluate how the supplier provides updates, vulnerability handling, escalation, documentation, expertise, and lifecycle support.

Counterexample: Evaluate the relationship at acquisition but omit support changes, testing scope, logging, subcontractors, and exit obligations, and material facts about support structure remain unexamined. | Present a clean track record or available telemetry as complete assurance. | Continue after material supplier changes without reassessment, transition planning, or accountable approval.

Limitations: The proposed support model does not define updates, vulnerability handling, escalation, documentation, expertise, or lifecycle coverage.

Tradeoffs: Evaluate how the supplier provides updates, vulnerability handling, escalation, documentation, expertise, and lifecycle support.

Community versus commercial support

Community and commercial models have different governance, contractual, staffing, disclosure, and continuity characteristics; neither is inherently superior.

Example: The supplier assurance manager should assess community and commercial support on governance, staffing, response, continuity, transparency, and contractual needs rather than assuming either model is superior.

Counterexample: The supplier assurance manager should evaluate the relationship at acquisition but omit support changes, testing scope, logging, subcontractors, and exit obligations, and material facts about support model comparison remain unexamined. | The supplier assurance manager should present a clean track record or available telemetry as complete assurance, and support model comparison is treated as settled by a clean public record, current availability, or one stable ownership snapshot. | The supplier assurance manager should continue after material supplier changes without reassessment, transition planning, or accountable approval, and residual risk associated with support model comparison has no authorized owner.

Limitations: The selection decision assumes commercial support is always safer than community support without evaluating actual governance and capability.

Tradeoffs: Assess community and commercial support on governance, staffing, response, continuity, transparency, and contractual needs rather than assuming either model is superior.

Licensing

License terms affect use, redistribution, modification, support, disclosure, audit, indemnity, and termination rights.

Example: The supplier decision should review license terms for permitted use, redistribution, modification, support, disclosure, audit, indemnity, and termination rights.

Counterexample: The supplier decision should use one clause while omitting distinct rights, evidence, remedies, data limits, triggers, and transition terms. | The supplier decision should regard the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls, and the claim about license obligations ignores stated limitations. | The supplier decision should proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability, and later changes to license obligations can escape reassessment.

Limitations: The component license may not permit the intended modification, redistribution, audit, disclosure, or termination arrangement.

Tradeoffs: Review license terms for permitted use, redistribution, modification, support, disclosure, audit, indemnity, and termination rights.

Security track record

Assess disclosed vulnerabilities, response speed, transparency, recurrence, secure-update behavior, support history, and evidence of improvement.

Example: A defensible response is to assess disclosed vulnerabilities, response speed, transparency, recurrence, secure-update behavior, support history, and evidence of improvement.

Counterexample: A defensible response is to evaluate the relationship at acquisition but omit support changes, testing scope, logging, subcontractors, and exit obligations, and the decision on supplier track record lacks sufficient supporting evidence. | A defensible response is to present a clean track record or available telemetry as complete assurance, and the claim about supplier track record ignores stated limitations. | A defensible response is to continue after material supplier changes without reassessment, transition planning, or accountable approval, and no owner reevaluates the supplier security history after change.

Limitations: A clean public record is being treated as proof of security without reviewing response speed, transparency, recurrence, and update behavior.

Tradeoffs: Assess disclosed vulnerabilities, response speed, transparency, recurrence, secure-update behavior, support history, and evidence of improvement.

Track-record limitation

A clean public record may reflect limited disclosure or visibility rather than absence of vulnerabilities.

Example: The acquisition team should treat a clean public record as limited evidence and investigate disclosure practices, assessment coverage, visibility, and response history.

Counterexample: The acquisition team should evaluate the relationship at acquisition but omit support changes, testing scope, logging, subcontractors, and exit obligations, and material facts about public record limitation remain unexamined. | The acquisition team should use a clean track record or available telemetry as complete assurance, and independent validation of public record limitation is skipped. | The acquisition team should continue after material supplier changes without reassessment, transition planning, or accountable approval.

Limitations: The supplier has no public security incidents, but disclosure practices and assessment visibility are limited.

Tradeoffs: Treat a clean public record as limited evidence and investigate disclosure practices, assessment coverage, visibility, and response history.

Scope of testing

Define which components, interfaces, environments, controls, tenants, and responsibilities are included or excluded from supplier testing.

Example: The next step is to define which components, interfaces, environments, controls, tenants, and responsibilities supplier testing includes or excludes.

Counterexample: The next step is to evaluate the relationship at acquisition but omit support changes, testing scope, logging, subcontractors, and exit obligations, and the organization evaluates supplier test from an incomplete record. | The next step is to present a clean track record or available telemetry as complete assurance, and the available signal for supplier test is treated as universal proof. | The next step is to continue after material supplier changes without reassessment, transition planning, or accountable approval, and the decision about supplier test has no expiry or reassessment trigger.

Limitations: Supplier testing excludes a critical API, tenant boundary, shared control, and production-relevant environment.

Tradeoffs: Define which components, interfaces, environments, controls, tenants, and responsibilities supplier testing includes or excludes.

Shared responsibility model

Clarify which party configures, monitors, patches, tests, logs, responds, recovers, and proves control effectiveness.

Example: A defensible response is to clarify which party configures, monitors, patches, tests, logs, responds, recovers, and demonstrates control effectiveness.

Counterexample: A defensible response is to grant production trust before validating origin, support, responsibilities, data flows, and operating fit, and the acquisition evidence for shared responsibility model is incomplete. | A defensible response is to use paid support or public reputation as conclusive security assurance, and the claim about shared responsibility model ignores stated limitations. | A defensible response is to transfer accountability to the supplier because operation is outsourced, ending customer oversight of the shared-responsibility model approval lifecycle.

Limitations: Supplier and customer have not assigned configuration, monitoring, patching, testing, logging, response, recovery, and evidence responsibilities.

Tradeoffs: Clarify which party configures, monitors, patches, tests, logs, responds, recovers, and demonstrates control effectiveness.

Log integration into SIEM

Require relevant supplier or service logs to integrate with security monitoring in a usable, timely, protected, and contractually permitted form.

Example: The responsible owner should require relevant supplier or service logs to integrate with monitoring in a usable, timely, protected, and contractually permitted form.

Counterexample: The responsible owner should evaluate the relationship at acquisition but omit support changes, testing scope, logging, subcontractors, and exit obligations, and the organization evaluates supplier log integration from an incomplete record. | The responsible owner should frame a clean track record or available telemetry as complete assurance. | The responsible owner should continue after material supplier changes without reassessment, transition planning, or accountable approval, and ownership of log-integration obligations remains undefined.

Limitations: Security-relevant supplier logs are unavailable, delayed, unprotected, or contractually restricted from monitoring integration.

Tradeoffs: Require relevant supplier or service logs to integrate with monitoring in a usable, timely, protected, and contractually permitted form.

Log-integration requirements

Define event types, timestamps, identity fields, retention, integrity, latency, format, access, privacy, and outage behavior.

Example: The security review team should define required event types, timestamps, identity fields, retention, integrity, latency, format, access, privacy, and outage behavior.

Counterexample: The security review team should evaluate the relationship at acquisition but omit support changes, testing scope, logging, subcontractors, and exit obligations, and material facts about log integration details remain unexamined. | The security review team should use a clean track record or available telemetry as complete assurance, and independent validation of log integration details is skipped. | The security review team should continue after material supplier changes without reassessment, transition planning, or accountable approval, and later changes to log integration details can escape reassessment.

Limitations: Available logs lack reliable timestamps, identity fields, retention, integrity, privacy controls, and defined outage behavior.

Tradeoffs: Define required event types, timestamps, identity fields, retention, integrity, latency, format, access, privacy, and outage behavior.

Subcontractor flow-down

Material security, notification, evidence, incident-coordination, data-handling, and remediation obligations should flow down to subcontractors and fourth parties whose components, services, data, or infrastructure affect the acquired product. The prime supplier remains accountable for demonstrating that required flow-down controls are implemented.

Example: The supplier decision should flow material security, notification, evidence, incident, data-handling, and remediation obligations to relevant subcontractors while retaining prime-supplier accountability.

Counterexample: The supplier decision should evaluate the relationship at acquisition but omit support changes, testing scope, logging, subcontractors, and exit obligations, and material facts about subcontractor obligation flow down remain unexamined. | The supplier decision should present a clean track record or available telemetry as complete assurance, and the organization treats visibility into subcontractor obligation flow down as proof of security. | The supplier decision should continue after material supplier changes without reassessment, transition planning, or accountable approval, and later changes to subcontractor obligation flow down can escape reassessment.

Limitations: Critical notification, evidence, data-handling, and remediation obligations do not flow to material subcontractors and fourth parties.

Tradeoffs: Flow material security, notification, evidence, incident, data-handling, and remediation obligations to relevant subcontractors while retaining prime-supplier accountability.

Supplier offboarding

Plan data return or destruction, access revocation, key and certificate transition, escrow use, support transition, and retained obligations.

Example: Plan data return or destruction, access revocation, key and certificate transition, escrow use, support transition, and retained obligations before offboarding.

Counterexample: Evaluate the relationship at acquisition but omit support changes, testing scope, logging, subcontractors, and exit obligations, and the scope for supplier exit controls excludes key dependencies and controls. | Regard a clean track record or available telemetry as complete assurance, and the organization treats visibility into supplier exit controls as proof of security. | Continue after material supplier changes without reassessment, transition planning, or accountable approval, and supplier exit duties lack a responsible transition owner.

Limitations: Offboarding has no plan for data return or destruction, access revocation, key transition, escrow, or support handover.

Tradeoffs: Plan data return or destruction, access revocation, key and certificate transition, escrow use, support transition, and retained obligations before offboarding.

Ongoing supplier monitoring

Acquisition approval is not permanent; monitor changes in ownership, controls, vulnerabilities, support, certifications, dependencies, and service scope.

Example: The security procurement lead should continuously monitor supplier ownership, controls, vulnerabilities, support, certifications, dependencies, and service scope after acquisition approval.

Counterexample: The security procurement lead should prioritize from severity alone while omitting reachability, exposure, privilege, support, and business impact, and the scope for supplier excludes key dependencies and controls. | The security procurement lead should regard an earlier not-reachable or no-known-issue result as permanent assurance, and independent validation of supplier is skipped. | The security procurement lead should let a scanner or technical owner accept residual exposure without an authorized business owner, and the supplier controls acceptance of supplier without customer authority.

Limitations: Acquisition approval is treated as permanent despite ownership, certification, dependency, support, and service-scope changes.

Tradeoffs: Continuously monitor supplier ownership, controls, vulnerabilities, support, certifications, dependencies, and service scope after acquisition approval.

Support contractual requirements

Ensure contracts allocate rights, obligations, evidence, remedies, security responsibilities, and lifecycle commitments consistent with risk.

Example: The responsible owner should ensure contracts allocate rights, obligations, evidence, remedies, security responsibilities, and lifecycle commitments in proportion to risk.

Counterexample: The responsible owner should use one clause while omitting distinct rights, evidence, remedies, data limits, triggers, and transition terms. | The responsible owner should regard the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls. | The responsible owner should proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability.

Limitations: The proposed contract does not allocate evidence rights, security responsibilities, remedies, and lifecycle commitments consistently with risk.

Tradeoffs: Ensure contracts allocate rights, obligations, evidence, remedies, security responsibilities, and lifecycle commitments in proportion to risk.

Intellectual property ownership

Define ownership and permitted use of source code, modifications, models, data, documentation, derivative works, and security findings.

Example: A defensible response is to define ownership and permitted use of source code, modifications, models, data, documentation, derivative works, and security findings.

Counterexample: A defensible response is to use one clause while omitting distinct rights, evidence, remedies, data limits, triggers, and transition terms, and material facts about intellectual property allocation remain unexamined. | A defensible response is to present the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls, and the claim about intellectual property allocation ignores stated limitations. | A defensible response is to proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability, and later changes to intellectual property allocation can escape reassessment.

Limitations: Ownership and permitted use of modifications, models, data, documentation, derivative works, and security findings are unclear.

Tradeoffs: Define ownership and permitted use of source code, modifications, models, data, documentation, derivative works, and security findings.

Code escrow

A neutral party holds source code or related materials for release under defined trigger conditions such as supplier failure or discontinued support.

Example: The acquisition team should define workable escrow release triggers and require current, complete, buildable deposits that support continuity if the supplier fails or ends support.

Counterexample: The acquisition team should use one clause while omitting distinct rights, evidence, remedies, data limits, triggers, and transition terms, and material facts about escrow continuity remain unexamined. | The acquisition team should use the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls, and the claim about escrow continuity ignores stated limitations. | The acquisition team should proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability, and later changes to escrow continuity can escape reassessment.

Limitations: Escrow release is limited to an impractical trigger and the deposited materials have never been verified as current or buildable.

Tradeoffs: Define workable escrow release triggers and require current, complete, buildable deposits that support continuity if the supplier fails or ends support.

Escrow completeness

Useful escrow may require source, build instructions, dependencies, tools, keys or key-transition procedures, documentation, and periodic verification.

Example: The next step is to require escrow deposits to include the source, build instructions, dependencies, tools, documentation, and necessary key-transition material, with periodic verification.

Counterexample: The next step is to use one clause while omitting distinct rights, evidence, remedies, data limits, triggers, and transition terms, and material facts about viable escrow deposit remain unexamined. | The next step is to frame the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls. | The next step is to proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability, and later changes to viable escrow deposit can escape reassessment.

Limitations: The escrow deposit lacks dependencies, build instructions, tooling, documentation, and key-transition material needed for continuity.

Tradeoffs: Require escrow deposits to include the source, build instructions, dependencies, tools, documentation, and necessary key-transition material, with periodic verification.

Liability

Allocate responsibility for losses, breaches, infringement, failure to meet obligations, and limits or exclusions of damages.

Example: The technology contracts lead should allocate responsibility for losses, breaches, infringement, unmet obligations, and applicable limits or exclusions of damages.

Counterexample: The technology contracts lead should use one clause while omitting distinct rights, evidence, remedies, data limits, triggers, and transition terms, and material facts about liability allocation remain unexamined. | The technology contracts lead should take the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls, and independent validation of liability allocation is skipped. | The technology contracts lead should proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability.

Limitations: Responsibility for breach losses, infringement, unmet obligations, and damage limits is ambiguous.

Tradeoffs: Allocate responsibility for losses, breaches, infringement, unmet obligations, and applicable limits or exclusions of damages.

Warranty

A warranty states promised characteristics or performance and available remedies; it is not the same as indemnity or service-level commitment.

Example: The responsible owner should use the warranty to define promised characteristics and remedies while keeping it distinct from indemnity, liability allocation, and service commitments.

Counterexample: The responsible owner should use one clause while omitting distinct rights, evidence, remedies, data limits, triggers, and transition terms, and material facts about warranty protection remain unexamined. | The responsible owner should take the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls, and the claim about warranty protection ignores stated limitations. | The responsible owner should proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability, and later changes to warranty protection can escape reassessment.

Limitations: The contract uses a warranty as though it were an indemnity, liability allocation, and service-level commitment.

Tradeoffs: Use the warranty to define promised characteristics and remedies while keeping it distinct from indemnity, liability allocation, and service commitments.

End-User License Agreement

An EULA defines permitted use, restrictions, ownership, disclaimers, termination, data handling, and other user obligations.

Example: The security review team should review the EULA for permitted use, restrictions, ownership, disclaimers, termination, data handling, and user obligations before acceptance.

Counterexample: Use a generic EULA that omits data handling, termination, ownership, and permitted-use restrictions. | The security review team should regard the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls, and independent validation of EULA obligations is skipped. | The security review team should proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability, and later changes to EULA obligations can escape reassessment.

Limitations: The EULA contains use, ownership, termination, or data-handling terms that conflict with the intended deployment.

Tradeoffs: Review the EULA for permitted use, restrictions, ownership, disclaimers, termination, data handling, and user obligations before acceptance.

Service-level agreement

An SLA defines measurable service commitments, responsibilities, reporting, exclusions, support, and remedies.

Example: The supplier decision should define measurable service commitments, responsibilities, reporting, exclusions, support, and remedies without treating the SLA as a security control or risk acceptance.

Counterexample: Use a service commitment that omits measurement, exclusions, reporting, support responsibilities, and remedies. | The supplier decision should interpret the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls, and independent validation of service level commitment is skipped. | The supplier decision should proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability, and later changes to service level commitment can escape reassessment.

Limitations: An availability SLA is being treated as proof of security control effectiveness and authority to accept residual risk.

Tradeoffs: Define measurable service commitments, responsibilities, reporting, exclusions, support, and remedies without treating the SLA as a security control or risk acceptance.

Security addendum

A security addendum can define controls, data protection, incident notice, audits, subcontractors, vulnerability handling, deletion, and evidence.

Example: Add contractual terms for security controls, data protection, incident notice, audits, subcontractors, vulnerability handling, deletion, and evidence.

Counterexample: Add a generic security clause without defining audit rights, incident notice, subcontractor duties, deletion, or evidence. | Take the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls, and independent validation of supplemental security terms is skipped. | Proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability, and later changes to supplemental security terms can escape reassessment.

Limitations: The main agreement lacks specific terms for controls, data protection, incident notice, audits, subcontractors, vulnerabilities, deletion, and evidence.

Tradeoffs: Add contractual terms for security controls, data protection, incident notice, audits, subcontractors, vulnerability handling, deletion, and evidence.

Indemnification

Indemnity allocates responsibility for specified third-party claims or losses and should be distinguished from warranty and liability caps.

Example: The vendor governance manager should define which third-party claims or losses the supplier must defend or reimburse, separately from warranties and liability caps.

Counterexample: Treat a general liability clause as sufficient without defining the third-party claims or losses covered by indemnity. | Regard limited evidence as proof that indemnity allocation needs no further review. | The vendor governance manager should proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability, and later changes to indemnity allocation can escape reassessment.

Limitations: Indemnity for third-party claims is being confused with product warranty and the general liability cap.

Tradeoffs: Define which third-party claims or losses the supplier must defend or reimburse, separately from warranties and liability caps.

Data-use restrictions

Contracts should limit supplier use, retention, disclosure, training use, and secondary processing of customer data.

Example: The responsible owner should limit supplier use, retention, disclosure, training use, and secondary processing of customer data through enforceable contract terms.

Counterexample: Permit supplier data use under broad service terms without limiting retention, disclosure, training use, or secondary processing. | The responsible owner should regard the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls, and supplier data use limits is treated as settled by one SLA, warranty, escrow, license, indemnity, or security clause. | The responsible owner should proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability, and the governance of supplier data use limits omits exception approval and review dates.

Limitations: The supplier can retain customer data and use it for model training or secondary processing without defined limits.

Tradeoffs: Limit supplier use, retention, disclosure, training use, and secondary processing of customer data through enforceable contract terms.

Breach-notification clause

Define notification trigger, timing, content, cooperation, regulator or customer communication, and continuing updates.

Example: A defensible response is to define the breach-notification trigger, timing, content, cooperation, regulator or customer communication, and continuing updates.

Counterexample: Use a breach clause that omits the notification trigger, deadline, required content, cooperation, and continuing updates. | A defensible response is to regard the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls, and independent validation of breach notification terms is skipped. | A defensible response is to proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability, and later changes to breach notification terms can escape reassessment.

Limitations: The breach clause lacks a clear trigger, deadline, required content, cooperation, communication, and continuing updates.

Tradeoffs: Define the breach-notification trigger, timing, content, cooperation, regulator or customer communication, and continuing updates.

Termination assistance

Define transition support, data export, access revocation, destruction evidence, license continuity, and service handover at termination.

Example: The acquisition team should define transition support, data export, access revocation, destruction evidence, license continuity, and service handover at termination.

Counterexample: Rely on ordinary termination language without requiring data export, access revocation, destruction evidence, or handover. | The acquisition team should interpret the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls, and independent validation of termination transition is skipped. | The acquisition team should proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability, and later changes to termination transition can escape reassessment.

Limitations: Termination terms omit data export, access revocation, destruction evidence, license continuity, and service handover.

Tradeoffs: Define transition support, data export, access revocation, destruction evidence, license continuity, and service handover at termination.

Contractual right versus operational capability

A contractual right is only useful when the organization can invoke it, collect evidence, enforce remedies, and transition services.

Example: The next step is to confirm the organization can exercise the contractual right, obtain evidence, enforce remedies, and transition the service before relying on the clause.

Counterexample: Accept broad contractual rights without confirming that the organization can collect evidence, enforce remedies, or transition service. | The next step is to take the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls, and independent validation of enforceable contractual rights is skipped. | The next step is to proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability, and later changes to enforceable contractual rights can escape reassessment.

Limitations: The organization has a contractual audit right but lacks the people, evidence access, enforcement path, and transition capability to use it.

Tradeoffs: Confirm the organization can exercise the contractual right, obtain evidence, enforce remedies, and transition the service before relying on the clause.

Conflict between contract and security policy

Security and legal stakeholders should resolve conflicting terms before acceptance and document authorized exceptions.

Example: The security counsel should resolve conflicts between supplier terms and security policy before acceptance, documenting any authorized exception and treatment.

Counterexample: Accept the supplier terms despite their conflict with security policy and without an authorized exception. | The security counsel should interpret the clause as equivalent to warranty, liability, indemnity, service levels, ownership, and security controls, and later changes to contract policy conflict are assumed irrelevant. | The security counsel should proceed with the term despite policy conflict or inability to invoke, verify, enforce, or transition the capability, and later changes to contract policy conflict can escape reassessment.

Limitations: Supplier terms conflict with security policy, but the conflict is being accepted without legal and security resolution or an authorized exception.

Tradeoffs: Resolve conflicts between supplier terms and security policy before acceptance, documenting any authorized exception and treatment.

AI ecosystem supply-chain expansion

The software supply chain includes external foundation models, public datasets, model weights, ML libraries, inference services, and specialized tooling.

Example: The responsible owner should include external foundation models, public datasets, model weights, ML libraries, inference services, and specialized tooling within the supply-chain boundary.

Counterexample: The responsible owner should use automated mapping or supplier results without validating data access, attack coverage, populations, or accountable review. | The responsible owner should regard one generated map, benchmark, or evaluation as exhaustive proof, and the claim about AI ecosystem ignores stated limitations. | The responsible owner should give approval authority to the AI tool or supplier without organizational security, legal, privacy, fairness, and ethics ownership, and later changes to AI ecosystem can escape reassessment.

Limitations: The supply-chain inventory excludes external models, training datasets, weights, ML libraries, inference services, and specialized AI tooling.

Tradeoffs: Include external foundation models, public datasets, model weights, ML libraries, inference services, and specialized tooling within the supply-chain boundary.

External foundation-model dependency

Reliance on third-party foundation models introduces provider, model-version, availability, confidentiality, provenance, and behavior risks.

Example: The security review team should assess provider, model-version, availability, confidentiality, provenance, behavior, and vendor-control risks before relying on an external foundation model.

Counterexample: The security review team should validate a model name or hash but omit publisher trust, version changes, provenance, hidden triggers, and provider dependencies. | The security review team should frame a model card, red-team summary, reputation, or pinned version as complete assurance. | The security review team should continue after material model, policy, hosting, subprocessor, or safety changes without notice or reassessment.

Limitations: The external model provider can change versions, behavior, controls, hosting, or availability without sufficient visibility or governance.

Tradeoffs: Assess provider, model-version, availability, confidentiality, provenance, behavior, and vendor-control risks before relying on an external foundation model.

Massive public dataset risk

Public training datasets may contain poisoned, biased, unlawful, sensitive, mislabeled, or low-quality content.

Example: The supplier decision should assess public training data for poisoning, bias, unlawful or sensitive content, labeling errors, quality limitations, and intended-use fit.

Counterexample: The supplier decision should use a supplier summary without verifying lineage, ownership, collection basis, preprocessing, licenses, sensitivity, or bias, and material facts about public dataset risk remain unexamined. | The supplier decision should equate a single piece of dataset evidence with complete assurance. | The supplier decision should let the supplier determine license compliance and risk acceptance without organizational review, and later changes to public dataset risk can escape reassessment.

Limitations: A massive public dataset is being adopted without evidence about poisoning, bias, legality, sensitivity, labeling, or quality.

Tradeoffs: Assess public training data for poisoning, bias, unlawful or sensitive content, labeling errors, quality limitations, and intended-use fit.

AI Bill of Materials

An AI-BOM extends component inventory to include model weights, training datasets, ML libraries, model lineage, and related AI artifacts.

Example: Extend the inventory to model weights, training datasets, ML libraries, lineage, configuration, and related AI artifacts.

Counterexample: Use one AI inventory as the entire AI-BOM record. | Interpret the AI inventory as proof of safety, legality, fairness, and absence of hidden behavior, and the organization assumes AI BOM inventory needs no further validation. | Leave the inventory unchanged after model, dataset, library, provider, configuration, or deployment changes affecting ongoing AI-BOM inventory oversight.

Limitations: The AI inventory lists a model name but omits exact weights, datasets, ML libraries, lineage, and related artifacts.

Tradeoffs: Extend the inventory to model weights, training datasets, ML libraries, lineage, configuration, and related AI artifacts.

Model-weight inventory

Model versions and weights should be uniquely identified, integrity-protected, traced to sources, and linked to deployment context.

Example: The AI supply-chain assurance lead should uniquely identify model versions and weights, protect their integrity, trace them to sources, and link them to approved deployment contexts.

Counterexample: The AI supply-chain assurance lead should list a model family but omit exact weights, datasets, libraries, lineage, licenses, integrity, and deployment context. | The AI supply-chain assurance lead should frame the AI inventory as proof of safety, legality, fairness, and absence of hidden behavior. | The AI supply-chain assurance lead should leave the inventory unchanged after model, dataset, library, provider, configuration, or deployment changes affecting the model artifact catalog approval process.

Limitations: Model files are identified by informal names without unique versions, trusted hashes, source lineage, or deployment linkage.

Tradeoffs: Uniquely identify model versions and weights, protect their integrity, trace them to sources, and link them to approved deployment contexts.

Training-dataset inventory

Record dataset source, ownership, collection basis, version, preprocessing, licenses, sensitivity, and known quality or bias limitations.

Example: The organization should record dataset source, ownership, collection basis, version, preprocessing, licenses, sensitivity, and known quality or bias limitations.

Counterexample: The organization should list a model family but omit exact weights, datasets, libraries, lineage, licenses, integrity, and deployment context. | The organization should regard the AI inventory as proof of safety, legality, fairness, and absence of hidden behavior. | The organization should leave the inventory unchanged after model, dataset, library, provider, configuration, or deployment changes affecting the dataset lineage catalog approval.

Limitations: The dataset inventory omits collection basis, ownership, preprocessing, licenses, sensitivity, and known quality or bias limits.

Tradeoffs: Record dataset source, ownership, collection basis, version, preprocessing, licenses, sensitivity, and known quality or bias limitations.

Open-source AI model selection criteria

Select open-source AI models using provenance, license, maintainer, evaluation, architecture, update, security, and ethical criteria.

Example: A defensible response is to select open-source models using provenance, license, maintainer, evaluation, architecture, update, security, and ethical criteria.

Counterexample: A defensible response is to stop the assessment after reviewing a single piece of model evidence. | A defensible response is to present a model card, red-team summary, reputation, or pinned version as complete assurance, and later changes to open model selection are assumed irrelevant. | A defensible response is to continue after material model, policy, hosting, subprocessor, or safety changes without notice or reassessment, and later changes to open model selection can escape reassessment.

Limitations: An open-source model is selected from leaderboard performance without provenance, license, maintainer, security, update, or ethical review.

Tradeoffs: Select open-source models using provenance, license, maintainer, evaluation, architecture, update, security, and ethical criteria.

Malicious model backdoors

Pre-trained models may contain hidden triggers or behaviors that activate under specific inputs.

Example: The acquisition team should evaluate pretrained models for hidden triggers and context-dependent malicious behavior before granting production trust.

Counterexample: The acquisition team should base the review on a single piece of model evidence. | The acquisition team should regard a model card, red-team summary, reputation, or pinned version as complete assurance, and the limitations of the evidence for model backdoor risk are not considered. | The acquisition team should continue after material model, policy, hosting, subprocessor, or safety changes without notice or reassessment, and the decision about model backdoor risk has no expiry or reassessment trigger.

Limitations: A pretrained model may contain a hidden trigger, but no evaluation targets backdoor behavior before production trust is granted.

Tradeoffs: Evaluate pretrained models for hidden triggers and context-dependent malicious behavior before granting production trust.

AI-assisted supply-chain mapping

AI tools can help discover and correlate deeply nested components and relationships but require validation and governed data access.

Example: The next step is to validate AI-generated supply-chain maps against authoritative inventories and govern the data and access used by the mapping tool.

Counterexample: The next step is to use automated mapping or supplier results without validating data access, attack coverage, populations, or accountable review. | The next step is to frame one generated map, benchmark, or evaluation as exhaustive proof. | The next step is to give approval authority to the AI tool or supplier without organizational security, legal, privacy, fairness, and ethics ownership.

Limitations: An AI-generated dependency map is accepted without validation against authoritative inventories or governance of the data it accessed.

Tradeoffs: Validate AI-generated supply-chain maps against authoritative inventories and govern the data and access used by the mapping tool.

Model-poisoning risk quantification

Assess likelihood and impact of poisoned training data, compromised model updates, malicious contributors, and corrupted pipelines.

Example: Supply-chain governance should assess the likelihood and impact of poisoned data, compromised model updates, malicious contributors, and corrupted training or delivery pipelines.

Counterexample: Supply-chain governance should validate a model name or hash but omit publisher trust, version changes, provenance, hidden triggers, and provider dependencies. | Supply-chain governance should use a model card, red-team summary, reputation, or pinned version as complete assurance. | Supply-chain governance should continue after material model, policy, hosting, subprocessor, or safety changes without notice or reassessment.

Limitations: The assessment does not quantify poisoning risk from training data, model updates, malicious contributors, or compromised pipelines.

Tradeoffs: Assess the likelihood and impact of poisoned data, compromised model updates, malicious contributors, and corrupted training or delivery pipelines.

Bias assessment of pretrained models

Evaluate whether inherited model behavior creates discriminatory, unsafe, or policy-violating outcomes in the intended context.

Example: The responsible owner should evaluate inherited model behavior for discriminatory, unsafe, or policy-violating outcomes in the intended populations and use context.

Counterexample: The responsible owner should use a single piece of model evidence as the entire assessment record. | The responsible owner should interpret a model card, red-team summary, reputation, or pinned version as complete assurance, and the claim about pretrained model bias ignores stated limitations. | The responsible owner should continue after material model, policy, hosting, subprocessor, or safety changes without notice or reassessment, and later changes to pretrained model bias can escape reassessment.

Limitations: A supplier aggregate benchmark is being used without evaluating discriminatory, unsafe, or policy-violating outcomes in the intended context.

Tradeoffs: Evaluate inherited model behavior for discriminatory, unsafe, or policy-violating outcomes in the intended populations and use context.

AI component ethical standards

AI supply-chain components should satisfy organizational security, legal, privacy, fairness, transparency, and ethical requirements.

Example: The security review team should require AI components to meet organizational security, legal, privacy, fairness, transparency, and ethical standards.

Counterexample: The security review team should use automated mapping or supplier results without validating data access, attack coverage, populations, or accountable review, and material facts about AI component ethics remain unexamined. | Regard limited evidence as proof that AI component ethics needs no further review. | The security review team should assign final approval of AI component ethics to the technical reviewer, and later changes to business critical AI supplier can escape reassessment.

Limitations: The model meets performance targets but has not been evaluated against organizational privacy, fairness, transparency, legal, and ethical requirements.

Tradeoffs: Require AI components to meet organizational security, legal, privacy, fairness, transparency, and ethical standards.

AI-BOM limitation

An AI-BOM improves transparency but does not prove dataset legality, model safety, absence of backdoors, or fitness for purpose.

Example: The supplier decision should use the AI-BOM for transparency while separately validating dataset legality, model safety, backdoor risk, bias, and fitness for intended use.

Counterexample: The supplier decision should use automated mapping or supplier results without validating data access, attack coverage, populations, or accountable review, and material facts about AI inventory limitation remain unexamined. | The supplier decision should frame one generated map, benchmark, or evaluation as exhaustive proof, and independent validation of AI inventory limitation is skipped. | The supplier decision should give approval authority to the AI tool or supplier without organizational security, legal, privacy, fairness, and ethics ownership, and later changes to AI inventory limitation can escape reassessment.

Limitations: The AI-BOM is being treated as proof of dataset legality, model safety, fitness, fairness, and absence of backdoors.

Tradeoffs: Use the AI-BOM for transparency while separately validating dataset legality, model safety, backdoor risk, bias, and fitness for intended use.

Model-card and data-card evidence

Model cards and data cards can summarize intended use, limitations, evaluation results, and data characteristics. They are supplier-provided transparency artifacts that support due diligence but do not replace independent validation, contractual evidence, provenance review, or operational monitoring.

Example: Use model cards and data cards as supplier transparency evidence, then perform independent validation, provenance review, contractual verification, and operational monitoring.

Counterexample: Validate a model name or hash but omit publisher trust, version changes, provenance, hidden triggers, and provider dependencies, and material facts about model card remain unexamined. | Interpret a model card, red-team summary, reputation, or pinned version as complete assurance, and the claim about model card ignores stated limitations. | Continue after material model, policy, hosting, subprocessor, or safety changes without notice or reassessment, and later changes to model card can escape reassessment.

Limitations: Model cards and data cards are being accepted as independent assurance without provenance review, validation, contracts, or operational monitoring.

Tradeoffs: Use model cards and data cards as supplier transparency evidence, then perform independent validation, provenance review, contractual verification, and operational monitoring.

Model signature and hash verification

Verify model artifacts before use and deployment; hashes detect change while trusted signatures add publisher identity.

Example: The model governance lead should verify model hashes through a trusted reference and validate trusted signatures to add publisher identity before use or deployment.

Counterexample: The model governance lead should treat a single piece of model evidence as sufficient coverage of model artifact verification. | The model governance lead should frame a model card, red-team summary, reputation, or pinned version as complete assurance, and the claim about model artifact verification ignores stated limitations. | The model governance lead should continue after material model, policy, hosting, subprocessor, or safety changes without notice or reassessment, and later changes to model artifact verification can escape reassessment.

Limitations: A model matches a hash obtained from the same untrusted source, and no trusted signature establishes publisher identity.

Tradeoffs: Verify model hashes through a trusted reference and validate trusted signatures to add publisher identity before use or deployment.

Dataset provenance gap

Large datasets may have incomplete lineage, mixed licenses, or unverifiable collection history; uncertainty is itself a risk input.

Example: The organization should record incomplete dataset lineage, mixed licensing, and unverifiable collection history as explicit risk inputs requiring treatment.

Counterexample: The organization should stop the assessment after reviewing a single piece of dataset evidence. | The organization should present public availability or one benchmark as proof that the data is lawful, unbiased, unpoisoned, and suitable, and the claim about dataset lineage uncertainty ignores stated limitations. | The organization should let the supplier determine license compliance and risk acceptance without organizational review, and later changes to dataset lineage uncertainty can escape reassessment.

Limitations: Incomplete dataset lineage and mixed licensing are being dismissed rather than recorded as risk inputs.

Tradeoffs: Record incomplete dataset lineage, mixed licensing, and unverifiable collection history as explicit risk inputs requiring treatment.

Remote model API opacity

Hosted AI APIs may conceal model updates, training sources, safety controls, and subcontractors, requiring contractual and monitoring controls.

Example: A defensible response is to address hosted-model opacity through contractual change notice, data-use controls, version monitoring, service evidence, and operational detection.

Counterexample: A defensible response is to validate a model name or hash but omit publisher trust, version changes, provenance, hidden triggers, and provider dependencies, and material facts about hosted model opacity remain unexamined. | Treat the provider's service description as complete assurance despite undisclosed model updates, training sources, controls, and subprocessors. | A defensible response is to continue after material model, policy, hosting, subprocessor, or safety changes without notice or reassessment, and later changes to hosted model opacity can escape reassessment.

Limitations: The hosted model API conceals version changes, training sources, safety controls, and subprocessors.

Tradeoffs: Address hosted-model opacity through contractual change notice, data-use controls, version monitoring, service evidence, and operational detection.

AI supplier change notification

Require notice of material model, dataset, policy, safety, hosting, subprocessors, or retention changes that affect risk.

Example: The acquisition team should require notice of material changes to models, datasets, policies, safety controls, hosting, subprocessors, or retention practices.

Counterexample: The acquisition team should use automated mapping or supplier results without validating data access, attack coverage, populations, or accountable review, and important dependencies affecting AI supplier change notice are not assessed. | The acquisition team should frame one generated map, benchmark, or evaluation as exhaustive proof. | Allow the provider to make material model, dataset, policy, hosting, or subprocessor changes without customer notice or reassessment.

Limitations: The supplier is not required to notify material model, dataset, policy, hosting, safety, subprocessor, or retention changes.

Tradeoffs: Require notice of material changes to models, datasets, policies, safety controls, hosting, subprocessors, or retention practices.

Model version pinning

Pinning can improve repeatability and change control but may delay security or safety updates and requires lifecycle monitoring.

Example: The next step is to pin a model version when repeatability is required, but monitor lifecycle changes and evaluate security or safety updates before remaining on it.

Counterexample: The next step is to validate a model name or hash but omit publisher trust, version changes, provenance, hidden triggers, and provider dependencies, and important dependencies affecting model version are not assessed. | Generalize the available result to every version and use of model version. | Keep the pinned model indefinitely without an owner for security updates, exception expiry, or lifecycle reassessment.

Limitations: The model version is pinned indefinitely even when security or safety updates require lifecycle review.

Tradeoffs: Pin a model version when repeatability is required, but monitor lifecycle changes and evaluate security or safety updates before remaining on it.

AI red-team evidence from suppliers

Supplier red-team results should be evaluated for scope, attack classes, model version, independence, unresolved findings, and applicability.

Example: Supply-chain governance should review supplier red-team evidence for scope, attack classes, model version, independence, unresolved findings, and applicability.

Counterexample: Supply-chain governance should use automated mapping or supplier results without validating data access, attack coverage, populations, or accountable review, and the supplier record for supplier AI red team omits relevant control details. | Treat a supplier red-team summary as complete assurance without checking model version, attack scope, independence, or unresolved findings. | Supply-chain governance should give approval authority to the AI tool or supplier without organizational security, legal, privacy, fairness, and ethics ownership.

Limitations: The supplier red-team summary omits attack classes, model version, independence, unresolved findings, and applicability.

Tradeoffs: Review supplier red-team evidence for scope, attack classes, model version, independence, unresolved findings, and applicability.

Training-data license compliance

Verify that dataset and model licenses permit intended training, fine-tuning, redistribution, and commercial use.

Example: The responsible owner should verify that dataset and model licenses permit the intended training, fine-tuning, redistribution, and commercial use.

Counterexample: The responsible owner should stop the assessment after reviewing a single piece of dataset evidence. | The responsible owner should present public availability or one benchmark as proof that the data is lawful, unbiased, unpoisoned, and suitable. | The responsible owner should let the supplier determine license compliance and risk acceptance without organizational review, and later changes to dataset license validation can escape reassessment.

Limitations: The dataset and model licenses do not clearly permit the intended fine-tuning, redistribution, or commercial use.

Tradeoffs: Verify that dataset and model licenses permit the intended training, fine-tuning, redistribution, and commercial use.

AI supply-chain incident coordination

Incident plans should address compromised models, poisoned datasets, leaked weights, malicious packages, and supplier-driven model changes.

Example: The security review team should define supplier coordination for compromised models, poisoned datasets, leaked weights, malicious packages, and provider-driven model changes.

Counterexample: The security review team should define notification without thresholds, timing, channels, evidence, updates, or affected-party coordination, and important dependencies affecting AI supplier incident coordination are not assessed. | The security review team should use an initial supplier statement as complete impact and recovery evidence. | The security review team should let the supplier control disclosure and closure without customer escalation, validation, or residual-risk review.

Limitations: The incident process does not address compromised models, poisoned datasets, leaked weights, malicious packages, or supplier-driven changes.

Tradeoffs: Define supplier coordination for compromised models, poisoned datasets, leaked weights, malicious packages, and provider-driven model changes.

Cloud Service Provider (CSP)

A Cloud Service Provider is the organization that owns and operates the cloud infrastructure, platform, or software delivered to a customer. Engaging a CSP is a supplier relationship: the CSP's security posture, contractual commitments, and evidence require the same due diligence as any other third party, scoped to the specific service and deployment model in use.

Example: Evaluate a Cloud Service Provider like any other supplier — verifying its security evidence, contractual commitments, and shared-responsibility boundaries — rather than assuming cloud delivery is inherently secure.

Counterexample: Assume that using a well-known Cloud Service Provider removes the need for supplier due diligence or contractual security requirements. | Treat the CSP's infrastructure-level certifications as evidence that the customer's specific application or configuration is secure. | Overlook that responsibilities differ by service model (IaaS, PaaS, SaaS), applying the same due-diligence checklist regardless of which model is in use.

CSP due diligence and exit strategy

Beyond initial security assessment, CSP relationships require ongoing due diligence and a documented exit strategy — data portability, format and retrieval guarantees, transition assistance, and contractual notice periods — so an organization is not effectively locked in by an inability to leave a provider securely.

Example: Negotiate data portability, retrieval format, and transition-assistance terms with a CSP before onboarding, and revisit the exit strategy periodically rather than only at contract renewal.

Counterexample: Assume a signed contract with a CSP is sufficient without verifying data can actually be extracted in a usable format if the relationship ends. | Treat vendor lock-in as strictly a cost or convenience issue rather than a security and continuity risk. | Defer exit-strategy planning until a CSP relationship is already ending, rather than establishing it during initial due diligence.