# Shifting Liability in the Supply Chain

Source: https://www.testifysec.com/blog/shifting-liability-in-the-supply-chain

Author: Chris Hughes

Published: 2024-03-15

Updated: 2026-10-06

How software liability is evolving in the context of supply chain security.

From the archive · editorial update October 6, 2026

The 2023 strategy described policy proposals, not a new general software-liability law. CISA released the common self-attestation form in March 2024. The SEC announced dismissal with prejudice of its SolarWinds and Timothy Brown enforcement action in November 2025. The original discussion below must be read in that historical context.

- [CISA’s released form ↗](https://www.cisa.gov/resources-tools/resources/secure-software-development-attestation-form)
- [SEC dismissal notice ↗](https://www.sec.gov/enforcement-litigation/litigation-releases/lr-26423)
- [Current TestifySec docs →](https://www.testifysec.com/docs)
- [Trust architecture →](https://www.testifysec.com/docs/cilock/trust)

The 2023 debate about software liability asked a useful engineering question: what can a software producer show about the work behind a release?

 

This article originally discussed federal policy proposals and the developing SolarWinds matter. Those events need dates and context. A policy proposal, an executive declaration, and a technical attestation make different claims.

 

## The 2023 policy discussion

 

The [July 2023 National Cybersecurity Strategy Implementation Plan](https://www.whitehouse.gov/wp-content/uploads/2023/07/National-Cybersecurity-Strategy-Implementation-Plan-WH.gov_.pdf) included work toward a software liability framework. It proposed policy development; it did not itself create a general statutory liability rule for all software vendors.

 

The original article treated that possible direction as a settled transformation. That framing has been removed. This page is a historical discussion, not a statement of the procurement or legal requirements that apply to a particular organization today.

 

## Self-attestation and technical evidence

 

The original text described the federal software attestation form while it was still a draft. CISA subsequently reported that it and OMB [released the form on March 11, 2024](https://content.govdelivery.com/accounts/USDHSCISA/bulletins/3913718).

 

A software producer’s declaration and an in-toto statement are not interchangeable. A declaration addresses organizational practices within its stated scope. A technical statement can record an observed build, test, or artifact. One does not automatically satisfy the other.

 

Engineering records can help an organization examine a claim before making it. For example, a release review can retain the source revision, build inputs, test configuration, result, artifact digest, and reviewer decision. Whether those records satisfy a requirement depends on the requirement and the quality of the evidence.

 

## The SolarWinds case changed

 

The original article discussed enforcement scrutiny before the case had concluded. On November 20, 2025, the SEC announced that it [filed a joint stipulation to dismiss its action against SolarWinds and Timothy Brown with prejudice](https://www.sec.gov/enforcement-litigation/litigation-releases/lr-26423). The SEC said its decision did not necessarily reflect its position on another case.

 

The article’s earlier predictions must not be treated as an outcome, finding of liability, or current precedent.

 

## What engineering teams can do

 

Choose a technical claim that can be checked. Keep the result connected to the artifact or system it describes. Record who produced the evidence and which policy was used to accept it. Preserve exceptions and failed checks alongside successful ones.

 [Witness](https://witness.dev/docs/) can capture configured observations and verify evidence against policy; [Archivista](https://github.com/in-toto/archivista) provides storage and retrieval. A valid signature detects alteration and supports attribution under a trust model. It does not make a false report true or transfer legal responsibility. 

For current commercial workflows, start with the [TestifySec documentation](https://www.testifysec.com/docs). Technical evidence supports a review; it is not a substitute for deciding which obligations apply.