25.2 Contractual Considerations¶

Vendor assessments identify supply chain security capabilities; contracts create enforceable obligations. Without contractual requirements, vendors have no legal obligation to maintain security practices, provide vulnerability notifications, or deliver SBOMs—regardless of what they claimed during procurement. When a vendor's compromised software affects your organization, the relevant question becomes: what does the contract say?

Traditional software contracts focus on functionality, availability, and data protection. Supply chain security requires additional provisions addressing how software is built, how vulnerabilities are handled, and what transparency vendors must provide. These provisions are increasingly standard in enterprise procurement, particularly following incidents like the 2020 SolarWinds attack that highlighted gaps in vendor security obligations.

This section provides guidance on supply chain security provisions to include in vendor contracts. Note: Contract language has legal implications that vary by jurisdiction and circumstance. The examples provided are illustrative starting points—always consult qualified legal counsel before incorporating provisions into actual agreements.

Security Requirements in Contracts¶

Contracts should establish baseline security requirements for how vendors develop, build, and maintain the software you're purchasing.

Security requirement clause examples:

General secure development requirement:

SECURE DEVELOPMENT. Vendor shall maintain and follow a documented 
software development lifecycle (SDLC) that includes security 
practices consistent with industry standards, including but not 
limited to:

(a) Security requirements and threat modeling during design
(b) Secure coding practices during development
(c) Security testing, including static and dynamic analysis
(d) Security review prior to release
(e) Dependency management and vulnerability scanning
(f) Build integrity controls

Vendor shall provide documentation of its SDLC practices upon 
Customer's reasonable request.

Supply chain-specific security requirement:

SUPPLY CHAIN SECURITY. Vendor shall implement and maintain 
supply chain security practices including:

(a) Maintaining an inventory of all third-party and open source 
    components included in the Software
(b) Monitoring such components for known vulnerabilities
(c) Evaluating components for security and maintenance status 
    prior to inclusion
(d) Implementing build integrity controls to prevent unauthorized 
    modification of the Software during build and release processes
(e) Signing releases to enable verification of authenticity

Vendor shall achieve and maintain at minimum [SLSA][SLSA] Level 2
compliance for build processes, or equivalent controls as
mutually agreed in writing.

Security standards reference:

SECURITY STANDARDS. Vendor shall maintain security practices
consistent with:

(a) [NIST SP 800-218][NIST-218] (Secure Software Development Framework)
(b) [OpenSSF Best Practices][Best-Practices] criteria at the "passing" level
(c) Industry-standard supply chain security practices

Vendor shall demonstrate compliance through third-party 
certification, self-attestation, or audit upon Customer's request.

Tailoring requirements to vendor tier:

Vendor Criticality	Requirement Depth
Critical	Specific SLSA level, named certifications, audit rights
High	Industry standards reference, attestation requirements
Medium	General secure development requirement
Low	Basic security representation

SBOM Delivery Requirements¶

SBOMs enable your ongoing vulnerability management. Contractual provisions should specify format, timing, and content requirements.

SBOM delivery specification:

SOFTWARE BILL OF MATERIALS. Vendor shall provide Customer with a 
Software Bill of Materials (SBOM) for the Software:

(a) FORMAT. SBOMs shall be provided in [`CycloneDX`][CycloneDX] 1.7+ / [`SPDX`][SPDX] 2.3+
    format, in machine-readable JSON.

(b) CONTENT. Each SBOM shall include:
    (i)   All direct and transitive dependencies
    (ii)  Component names and version identifiers
    (iii) Supplier/author information where available
    (iv)  License information for each component
    (v)   Package identifiers (PURL, CPE) where available

(c) TIMING. Vendor shall provide an updated SBOM:
    (i)   With each new release or version of the Software
    (ii)  Within [30] days of Customer's request
    (iii) Within [72 hours] of any update addressing a security 
          vulnerability

(d) DELIVERY. SBOMs shall be delivered via [specified mechanism: 
    customer portal, API, email to designated contact].

(e) ACCURACY. Vendor represents that SBOMs accurately reflect the 
    components included in the corresponding Software version at 
    the time of delivery.

SBOM timing considerations:

Scenario	Delivery Requirement
New release	SBOM available at release, or within defined window
Security update	Expedited SBOM delivery (24-72 hours)
Customer request	Reasonable timeframe (30 days typical)
Major version	SBOM plus summary of significant dependency changes

For vendors unable to provide full SBOMs:

DEPENDENCY INFORMATION. If Vendor cannot provide a complete SBOM, 
Vendor shall provide:

(a) A list of all direct dependencies, including names and versions
(b) Notification when significant dependency changes occur
(c) A commitment to develop full SBOM capability within [timeframe]

Vendor acknowledges that Customer may require full SBOM capability 
as a condition of contract renewal.

Vulnerability Notification Obligations¶

Vendors must notify you when vulnerabilities affect software you use. Without contractual obligations, notification is discretionary.

Notification timeline requirements:

SECURITY VULNERABILITY NOTIFICATION. Vendor shall notify Customer 
of security vulnerabilities affecting the Software as follows:

(a) CRITICAL VULNERABILITIES (CVSS 9.0-10.0 or actively exploited):
    Notification within twenty-four (24) hours of Vendor's awareness.

(b) HIGH VULNERABILITIES (CVSS 7.0-8.9):
    Notification within seventy-two (72) hours of Vendor's awareness.

(c) MEDIUM VULNERABILITIES (CVSS 4.0-6.9):
    Notification within seven (7) days of Vendor's awareness.

(d) Notifications shall include:
    (i)   Description of the vulnerability
    (ii)  Affected versions of the Software
    (iii) Severity assessment (CVSS score)
    (iv)  Known exploitation status
    (v)   Available mitigations or workarounds
    (vi)  Expected timeline for patch availability
    (vii) CVE identifier when assigned

(e) Vendor shall provide updates as additional information becomes 
    available and upon release of patches.

Notification mechanism specification:

NOTIFICATION DELIVERY. Security vulnerability notifications shall 
be delivered via:

(a) Email to Customer's designated security contact(s): [addresses]
(b) Posting to Vendor's security advisory page: [URL]
(c) [Additional mechanisms as appropriate]

Customer shall maintain current contact information for security 
notifications. Vendor shall confirm receipt of critical and high 
severity notifications.

Scope of notification obligation:

Scope Element	Specification
Vendor's own code	Clearly in scope
Third-party dependencies	Should be in scope when vendor is aware
Infrastructure vulnerabilities	In scope if affecting the delivered software
Remediation of upstream issues	Notification of vendor's remediation timeline

Patch SLAs and Support Commitments¶

Notification is insufficient without remediation. Patch SLAs establish expectations for how quickly vendors will address vulnerabilities.

Patch SLA tiers:

VULNERABILITY REMEDIATION. Vendor shall remediate security 
vulnerabilities in the Software according to the following 
timelines, measured from Vendor's awareness of the vulnerability:

(a) CRITICAL (CVSS 9.0-10.0 or actively exploited):
    Patch available within seven (7) calendar days.
    If a patch cannot be provided within this timeframe, Vendor 
    shall provide a workaround or mitigation within forty-eight 
    (48) hours.

(b) HIGH (CVSS 7.0-8.9):
    Patch available within thirty (30) calendar days.

(c) MEDIUM (CVSS 4.0-6.9):
    Patch available within ninety (90) calendar days.

(d) LOW (CVSS 0.1-3.9):
    Patch available in next scheduled release, or within one 
    hundred eighty (180) calendar days, whichever is sooner.

Where vulnerabilities exist in third-party dependencies, Vendor 
shall use commercially reasonable efforts to work with upstream 
maintainers and shall provide interim mitigations if upstream 
remediation is delayed.

Version support commitments:

SECURITY SUPPORT. Vendor shall provide security patches for:

(a) The current major version of the Software
(b) The immediately prior major version for [12/24] months 
    following release of a new major version
(c) Versions deployed by Customer under active support agreements

Vendor shall provide at least [12] months' notice before ending 
security support for any version deployed by Customer.

SLA exception handling:

SLA EXCEPTIONS. If Vendor cannot meet the remediation timelines 
specified above, Vendor shall:

(a) Notify Customer of the delay and provide a revised timeline
(b) Provide temporary mitigations or workarounds
(c) Provide weekly status updates until remediation is complete
(d) Document the root cause of delay for Customer's review

Repeated failures to meet remediation timelines shall constitute 
a material breach under Section [X] of this Agreement.

Audit Rights and Evidence Access¶

Contracts should grant you rights to verify vendor security claims, either directly or through third parties.

Audit right language:

SECURITY AUDIT RIGHTS. 

(a) RIGHT TO AUDIT. Customer may, upon reasonable notice and at 
    Customer's expense, audit Vendor's compliance with the security 
    requirements of this Agreement. Audits may be conducted by 
    Customer or a mutually agreed third-party auditor, not more 
    frequently than once per [12-month period / contract year].

(b) SCOPE. Audits may include review of:
    (i)   Security policies and procedures
    (ii)  Development and build practices
    (iii) Vulnerability management processes
    (iv)  Third-party component management
    (v)   Incident response capabilities
    (vi)  Evidence supporting security attestations

(c) COOPERATION. Vendor shall cooperate with audits, provide 
    requested documentation, and make relevant personnel available 
    for interviews within reasonable timeframes.

(d) CONFIDENTIALITY. Audit findings shall be treated as Vendor 
    Confidential Information. Customer may share findings with 
    regulators as required by law.

(e) REMEDIATION. Vendor shall remediate material findings within 
    a mutually agreed timeframe, not to exceed [90] days for 
    critical findings.

Alternative: reliance on third-party audits:

THIRD-PARTY CERTIFICATIONS. In lieu of direct audits, Vendor shall 
maintain and provide Customer with current copies of:

(a) SOC 2 Type II report covering relevant control objectives
(b) ISO 27001 certification for development operations
(c) [Other relevant certifications]

Vendor shall notify Customer within [30] days if any certification 
is revoked, suspended, or materially qualified. Customer retains 
the right to conduct direct audits if certifications lapse or do 
not adequately cover supply chain security practices.

Evidence access provisions:

EVIDENCE ACCESS. Upon Customer's reasonable request, Vendor shall 
provide:

(a) Current SBOMs for deployed Software versions
(b) Build provenance attestations
(c) Vulnerability scan results and remediation status
(d) Security assessment or penetration test summaries
(e) Documentation of security incident response

Vendor may redact information that would compromise security or 
disclose other customers' information.

Liability and Indemnification Clauses¶

Liability provisions allocate risk when security failures cause harm. These are among the most negotiated contract terms.

Indemnification considerations:

SECURITY INDEMNIFICATION. Vendor shall defend, indemnify, and hold 
harmless Customer from and against any claims, damages, losses, 
and expenses (including reasonable attorneys' fees) arising from:

(a) A breach of Vendor's security obligations under this Agreement
(b) A security vulnerability in the Software that Vendor knew or 
    should have known about and failed to disclose or remediate
(c) Vendor's failure to meet notification or remediation timelines 
    specified in this Agreement
(d) Unauthorized code, malware, or backdoors introduced into the 
    Software by Vendor or through Vendor's supply chain

This indemnification is subject to the limitations of liability 
in Section [X], except that [certain exclusions may apply for 
gross negligence or willful misconduct].

Liability considerations:

Provision	Customer Interest	Vendor Interest
Liability cap	Exclude security breaches from cap	Include in general cap
Consequential damages	Carve-out for security incidents	Exclude all consequential damages
Insurance	Require cyber liability coverage	Standard coverage
Subcontractor liability	Vendor liable for subcontractor failures	Pass-through to subcontractors

Important: Liability and indemnification provisions have significant legal and financial implications. The examples above illustrate concepts but require careful legal review and negotiation based on deal specifics, jurisdiction, and risk tolerance.

Insurance requirements:

INSURANCE. Vendor shall maintain cyber liability insurance 
covering security breaches, data breaches, and related claims, 
with limits of not less than [$X million] per occurrence and 
[$Y million] aggregate. Vendor shall provide certificate of 
insurance upon Customer's request.

Termination Rights for Security Failures¶

Contracts should provide exit options when vendors fail to meet security obligations.

Termination trigger clauses:

TERMINATION FOR SECURITY FAILURE. Customer may terminate this 
Agreement immediately upon written notice if:

(a) Vendor experiences a security breach affecting Customer data 
    that Vendor fails to contain and remediate within [timeframe]

(b) Vendor materially fails to meet security vulnerability 
    notification or remediation obligations more than [X] times 
    in any [12-month period]

(c) Vendor's security certifications lapse and are not reinstated 
    within [60] days

(d) Vendor refuses to provide required security evidence or 
    cooperate with audit requests

(e) Vendor experiences a supply chain security incident affecting 
    the Software and fails to notify Customer within required 
    timeframes

Upon termination for security failure:
(i)   Customer shall receive a pro-rata refund of prepaid fees
(ii)  Vendor shall provide reasonable transition assistance
(iii) Vendor shall continue security support during transition 
      period not to exceed [90] days

Suspension rights:

SUSPENSION. Customer may suspend use of the Software pending 
resolution if:

(a) An unpatched critical vulnerability exists beyond the 
    remediation SLA
(b) Vendor is investigating a potential supply chain compromise
(c) Customer's security team determines continued use poses 
    unacceptable risk

During suspension, any time-based fees shall be abated. Suspension 
does not waive Customer's termination rights.

Transition assistance:

TRANSITION ASSISTANCE. Upon termination for any reason, Vendor shall:

(a) Provide final SBOMs for all deployed versions
(b) Continue security notifications for [90] days post-termination
(c) Provide reasonable technical assistance for migration
(d) Return or destroy Customer data per Customer's instruction

Contract Negotiation Strategy¶

Prioritizing provisions:

Priority	Provisions	Negotiation Approach
Must-have	Vulnerability notification, patch SLAs, SBOM delivery	Non-negotiable for critical vendors
Important	Audit rights, termination triggers	Standard ask; accept alternatives
Valuable	Enhanced indemnification, insurance requirements	Push for; accept reasonable limits
Nice-to-have	Specific SLSA levels, expanded liability	Request; don't die on this hill

Vendor pushback responses:

Vendor Objection	Possible Response
"No one asks for SBOMs"	"SBOM requirements are increasingly standard and regulatory trends point toward mandates"
"We can't commit to notification timelines"	"What timeline can you commit to? We need predictability for our risk management"
"Audit rights are too intrusive"	"We'll accept reliance on SOC 2 or equivalent third-party certification"
"Patch SLAs are unrealistic"	"Let's discuss what's achievable and document that"

Recommendations¶

We recommend the following approach to supply chain security contract provisions:

Include explicit supply chain security requirements: Don't assume general security language covers supply chain. Specify build integrity, dependency management, and related practices.
Require SBOM delivery in standard formats: Specify CycloneDX or SPDX, timing of delivery, and content requirements. SBOMs should be a standard contract deliverable.
Establish vulnerability notification timelines: Define specific timelines by severity. Notifications are useless if they arrive after you've learned of issues elsewhere.
Set patch SLAs appropriate to criticality: More critical vendors warrant more aggressive SLAs. Ensure SLAs include provisions for when upstream dependencies are the source.
Secure audit rights or certification requirements: You need ability to verify vendor claims. Direct audit rights or reliance on third-party certifications both work.
Define termination triggers for security failures: Ensure you can exit relationships when vendors fail to meet security obligations. Include transition assistance requirements.
Consult legal counsel: Contract provisions have legal implications beyond security. Work with qualified attorneys to adapt example language to your specific situation and jurisdiction.
Negotiate proportionally to criticality: Not every vendor needs every provision. Focus intensive negotiation on critical vendors; accept lighter requirements for low-risk relationships.

Contracts create accountability. When security obligations are clearly documented, vendors invest in meeting them. When they're absent, security becomes optional—and optional often means omitted.