AI writes the code now: the software bill of materials is the control

Intekhab Nazeer, chief financial officer of Lineaje, a software supply chain security vendor founded in 2022 with offices in Silicon Valley, Washington DC and the Middle East, gave an interview to Raconteur published on 24 September. Raconteur introduced him as a finance leader of more than 20 years who helped WekaIO secure more than $300m (£225m) in funding. Asked what that taught him, he said “raising capital is not the hard part, deploying it effectively is”.

The part that matters to the UK channel came later. Nazeer told Raconteur that AI now sits across the whole software development lifecycle, writing code, testing it and deploying it, and that the same tools bring new exposure to vulnerabilities, leaked data and malicious activity. He also argued that a predictable revenue engine, built on visibility of pipeline, sales efficiency and retention, matters more than the size of the last round.

He would say that. Lineaje sells software that inventories and checks the components in other people’s code, so its CFO describing AI-written software as a new risk is also describing its market. Then notice that the National Cyber Security Centre (NCSC) has been saying something similar for two years.

Once agents write and ship code, the software bill of materials (SBOM) stops being a document produced for a procurement questionnaire and becomes a live security control. Managed security service providers (MSSPs) should be selling SBOM and supply-chain assurance to every customer that has let agents into its pipeline, now, not when a law forces the customer to ask.

What the NCSC already says

In a blog post on 4 June, the NCSC wrote that “attackers are compromising open source packages at scale to spread malware”. It cited May’s Mini Shai-hulud attack, which spread through package registries and developer tooling. Its advice: review every new dependency version rather than adopting it automatically, and deploy only through controlled continuous integration and delivery (CI/CD) pipelines, not from developer devices.

Review means knowing what you have. The NCSC’s September 2024 post on SBOMs warned that “the mere presence of a SBOM does not guarantee that a supply chain is secure”. An SBOM is the list. The control is the process that reads the list against a vulnerability feed every time the list changes.

Most UK businesses are nowhere near that. The government’s Cyber Security Breaches Survey 2025, which questioned 2,180 UK businesses between August and December 2024, found that just over one in 10 (14%) reviewed the risks posed by their immediate suppliers and 7% looked at the wider supply chain. That is the customer base.

Why agents change the arithmetic

When a developer chose a library, there was a person who could tell you why. When an agent writes the feature, picks the dependency, writes the test and opens the pull request, that memory does not exist. The choice was made at machine speed and will be made again tomorrow with a different version. The NCSC’s warning that one malicious package can spread quickly through downstream products was written about human supply chains. With agents in the loop, the gap between a poisoned package appearing and it landing in a build is however long the pipeline takes.

The 2026 minimum elements for an SBOM, published on 29 July by the US Cybersecurity and Infrastructure Security Agency (CISA) and partner agencies, describe an SBOM as an ‘ingredients list’ for software and say AI software may need elements beyond the baseline. The inventory is about to get more detailed, and someone has to maintain it. That someone is rarely a customer that adopted agents in order to have fewer people reading code.

Do not wait for the bill

It is tempting to wait for the law. The Cyber Security and Resilience (Network and Information Systems) Bill was introduced to the Commons on 12 November 2025, cleared the Commons on 16 June and began its Lords committee stage on 1 September, with report stage listed for 26 October. The government’s April 2025 policy statement said the bill would bring an estimated 900–1,100 MSPs into regulation and require them to notify their regulator and the NCSC of a significant incident within 24 hours, with a full report inside 72 hours.

The bill regulates the provider, not the customer’s development pipeline. It says nothing about which packages an agent pulled into a build last night. What it does is make an MSSP answerable, inside 24 hours, for incidents it can only explain if it knows what its customers are running. Selling the SBOM as a service is not a hedge against the bill. It is how a provider survives the bill.

What to sell, and to whom

The offer is unglamorous, which is why it will be paid for. First, a signed SBOM for every application the customer builds or buys, regenerated on every build. Second, a review gate in the pipeline that holds any new or changed dependency until it has been checked, which is the NCSC’s own advice sold as a service. Third, continuous matching of that inventory against vulnerability feeds, with a named person who calls when something turns red. Fourth, a contract clause requiring the customer’s own suppliers to hand over SBOMs, because the 7% figure says nobody else is asking.

Price it as a recurring service tied to the number of applications, not as a project. Start with the customers letting agents commit code: software houses, fintechs, ecommerce operators and any firm told to ship faster with fewer developers.

Nazeer’s line about capital applies to the channel too. Money is rarely the constraint for an MSSP; engineering hours are. Spending them on a service the NCSC recommends, that regulation will soon make necessary and that customers cannot easily do for themselves is about as disciplined as deployment gets. Sell the ingredients list before the law makes someone ask for it.