Software supply chain risk: how three CISOs frame trust in contracts, code and suppliers

Three security chiefs, three angles

The question of how CISOs handle software supply chain risk has no single answer in these documents. Instead, they show three security leaders working on the problem from different seats. One is a state government CISO speaking to procurement staff. One is a newly appointed CISO at an application security vendor whose remit explicitly includes supply chain. One is a consultancy CISO writing about how vulnerabilities in applications and their components are found and ranked.

Taken together, they cover three stages of the same problem. The first is buying software under contract. The second is knowing what is inside it. The third is finding the weaknesses once it is in use.

Contracts as a security control

Bill Brinkley, Chief Information Security Officer for the State of Wisconsin, presented to the state's procurement community under a title that names all three stages. The slide deck lists the session as the 2025 Wisconsin Statewide Procurement Conference.

His opening slides set the frame. They say cyber risk is not an IT problem. A second line on the same slide recasts what security is for.

The deck then moves to "Managing Risk Across the Contract Lifecycle." That section poses a set of key questions rather than stating rules. One asks where exposure enters the buying process. Another names the trade-off procurement teams face between checking a supplier thoroughly and getting a contract signed.

The slides also cover the state's Cybersecurity Business Review (CBR) process, the review step tied to technology purchases. The deck says that process is changing in a particular direction. It also signals a shift in who carries the decision.

The published deck contains the questions only. The answers given in the room are not in the slides. What the document does establish is the structure a state CISO chose for this audience. Security review sits inside solicitation, contract execution and agency decision-making, not after them.

Code provenance: SBOMs, standards and secure by design

The second section of the Wisconsin deck, "Software and Service Transparency," addresses what is inside the software a buyer receives. It names the Software Bill of Materials directly. It pairs that with a question about tracing where components come from.

The deck also connects vendor obligations to named frameworks. It refers to the state's own standards and says those standards are built on NIST guidance. The slides do not spell out the contract clauses that follow from this. Still, the framing ties software assurance to accountability that a buyer can hold a vendor to.

The final content section, "Building Resilient Supply Chains," widens the scope beyond single products. One question addresses threats at three levels. Another asks what the supplier base should look like as a whole.

Supply chain as part of the CISO's remit

The Black Duck announcement shows the supply chain question from the supplier's side. On December 19, 2024, the company announced two executive appointments.

The announcement lists supply chain among the areas Jenkins owns. The same release gives the new CIO a security role as well. Both executives therefore carry security duties, with the CISO's scope explicitly covering products and supply chain.

Jenkins's path, as the release describes it, ran through product security roles. Before that, the announcement says, he held a similar role at another software company.

The release traces the start of his security career to a specific incident during military service. It also records a current industry role focused on this topic.

In his quoted statement, Jenkins uses the same "secure by design" language that appears in the Wisconsin deck. He describes his priority as resilient, secure-by-design solutions, approached in a practical way.

Finding flaws in third-party software

The Synechron article, by CISO Aaron Momin and senior architect Bharadwaj D Jagannath, addresses the detection stage. It first defines the traditional practice. The article says this work relies on automated scanning, manual expert analysis and comparison against public vulnerability databases, including CVE. It then explains how findings have usually been ranked.

The article then describes the firm's own AI-based tool, AppSec.AI. It presents the tool as a planned release that works alongside existing scanning tools. For third-party software, the relevant detail is that its inputs include composition analysis, the scanning category that inspects the components a product is built from. The authors say prioritization looks beyond severity scores to whether an exploit exists and how important the affected application is. They also list Stakeholder-Specific Vulnerability Categorization (SSVC) among the frameworks the tool uses, alongside CVE and CVSS.

The authors also note a risk in this approach. They state that security, privacy and compliance measures are needed to protect sensitive data and maintain trust.

The author note describes Momin's background in risk disciplines that go beyond technical security. It says he held senior roles at PwC, Ernst & Young and Accenture. Before Synechron, the note says, he served as CISO at Certinia.

What the three documents share

All three documents use the language of trust. The Wisconsin deck puts it in its title. Jenkins says "it all comes down to trust." The Synechron authors list maintaining trust among the reasons for security, privacy and compliance controls.

Read in sequence, the documents trace one chain of responsibility. A state CISO places security questions inside solicitation, contracts and supplier standards. A vendor CISO is given ownership of supply chain security for the software his company ships. A consultancy CISO describes how flaws in applications and their components are detected and ranked after deployment.

The career paths behind those positions differ as well. They run through state government, through product security and military service, and through cyber risk and consulting work. Each document shows supply chain risk handled as part of the CISO's scope, whether through contracts, product design or vulnerability management.