Most of the software an organisation depends on is written, maintained, and updated by other people. That dependency used to sit with the technology function. A run of high-profile attacks, and a shift in regulation, have moved it onto the board's agenda.
Why this reaches the board
NIS2 places supplier security obligations directly on essential and important entities, and DORA treats software and cloud providers as third-party ICT risk, with expectations on contracts, monitoring, and concentration. Supply chain security is now something the management body has to oversee and evidence, alongside the teams that manage it day to day.
The SolarWinds attack in 2020 compromised a widely used management tool and reached thousands of businesses and government agencies. The Dependency Confusion attack in 2021 used naming conventions in software package systems to reach targets including Microsoft, Apple, and Tesla. The Mimecast certificate compromise in 2021 and the ASUS Live Update backdoor in 2018 show how varied the routes in can be.
The SolarWinds attack in 2020 showed both the reach of a single breach and the sophistication of the techniques employed by attackers.
The method your teams use
There is a recognised standard for building security into how software is developed and delivered: NIST SP 800-204D. It sets out how to embed security across the delivery pipeline, from early design through to release, with vulnerability management, automated checks, and governance over the whole chain. What the board needs is confidence that a method like this is in place and working.
A supplier's weakness becomes your incident, and increasingly your regulatory finding.
What the board should ask
Three questions establish whether the risk is being managed: do we know which software suppliers and components our critical services depend on; is security built into how software reaches production; and could we show a regulator the evidence. Where the answers are unclear, that is the work to commission, and a named owner should hold it.