How Quickly Can You Trace Vulnerable Code Across Public Services?

September 14, 2026 Mohammad Shahidcybersecurity, vulnerabilityLeave a comment

In benchmark testing, OpenAI’s latest model, GPT -6 Astra, was able to find unknown zero-day vulnerabilities and exploit them in real-time. Although this capability is being sandboxed and restricted for now, this finding should worry everyone, especially those responsible for public services.

The security threat landscape is moving to a mass risk of zero-days, yet the public sector still struggles to respond to known vulnerabilities, especially third-party flaws that take an average of 358 days to fix.

To see where the response can stall, let’s follow a vulnerability alert through a public service and examine what it takes to get the affected code fixed.

How fast is fast enough?

Imagine a council security team receiving an alert about a flaw in software used to process uploaded documents. A scan finds the affected component in several projects, including one that appears to support the housing repairs portal.

The service director wants to know whether residents can keep using it. The team needs to check which version is running and whether the upload function exposes the flaw. An external supplier maintains the application.

The scan has taken minutes. Answering the director could occupy much of the morning.

In Veracode’s 2026 State of Software Security research, third-party flaws took an average of 358 days to fix and accounted for 66% of critical security debt in its dataset.

Public-service leaders can examine the delay within their own organisations, starting with the work required to turn a component finding into an agreed plan for the affected service.

Graphic showing statistics on third-party software flaws: '358 days' as the average time to fix these issues, alongside '66%' indicating the percentage of critical security debt from third-party components.

The search needs to reach below the application

A service register might identify the repairs portal and its supplier. It is unlikely to tell the security team which open-source library handles a resident’s uploaded photograph.

That detail belongs in the software’s component inventory. A software bill of materials, or SBOM, records the components in a build, including their versions. For this investigation, the inventory must cover dependencies brought in by other packages, known as transitive dependencies.

The distinction matters when the development team says it has never selected the affected library. Another component may have introduced it.

Search results should show that dependency path. It helps the engineer determine which package needs updating, especially when the vulnerable library cannot be changed independently.

Then check the inventory’s scope and date. Confirm that supplier-managed software is included in the search. If it is excluded, the team needs evidence from the supplier before ruling the service out.

Graphic depicting an iceberg with 'What's Beneath Your Public Service?' text. The top shows 'Public Service', followed by 'Application', and at the bottom, 'Vulnerable Dependency' indicated with an exclamation mark.

Follow the finding all the way to production

Suppose the supplier confirms that the library appears in the portal’s codebase. Its latest development build already contains a corrected version.

The council still needs to establish what residents are using today.

Link the component finding to a specific build, then check where that build was deployed. The evidence should identify the live service and any running instances that still contain the affected version.

This connection takes preparation. Repository names rarely explain a service’s purpose to someone outside its delivery team. Maintain the relationship between each project and the service it supports as part of normal delivery. Changes of supplier or platform are good moments to check that the record still holds.

Once the team locates the affected release, it can assess exposure. Some vulnerabilities require particular settings or a reachable function before an attacker can exploit them. Record the relevant configuration and the reasoning behind the assessment.

That gives the service director something useful to act on. If the upload function is exposed, restricting it may be appropriate while a fix is prepared. The decision must account for how residents will submit repair requests during that restriction.

“We’re investigating” needs a next step

A supplier’s acknowledgment can arrive quickly while useful answers take longer.

In our scenario, the council needs a response tied to its deployed release. The supplier should explain whether that release is affected and identify the proposed remedy. Agree when the next substantive update will arrive.

Inside the council, assign someone to coordinate the remediation. That person needs a working technical contact at the supplier and a route for escalating delays. The accountable service owner must also be available to approve operational decisions.

Ownership should be established before the alert arrives. Test the escalation route during routine supplier reviews. A contract reference is little help if the named contact has moved on or cannot reach the engineers responsible.

Where several public services share the same component, assess their exposure individually. Prioritisation should reflect evidence of exploitation and the consequences for each service. A common package does not mean every deployment needs the same response.

The fix has to survive contact with the service

A suggested replacement version gives engineers a starting point. It still needs testing against the application.

An upgrade can change behaviour elsewhere in the dependency chain. For the repairs portal, regression testing should include the document-upload workflow residents rely on. The team also needs a recovery plan if deployment causes problems.

Keep the finding open until the evidence shows that the corrected build has reached the affected instances. Recheck the deployed software and retain the result with the remediation record.

If an update must wait, document the reason and set a review date. Any temporary restriction needs someone responsible for checking that it remains effective. Otherwise, the next person handling the service inherits an unresolved decision with little explanation.

Find out where your own morning goes

Choose one important service and rehearse this investigation using a component it actually contains. Time how long the team takes to produce:

A deployment record: the affected version linked to the live service.
An exposure decision: the evidence supporting the assessment.
A named lead: someone able to coordinate remediation and escalate delays.
A tested route to closure: the proposed update and the checks required after deployment.

Infographic outlining the steps to getting a fix live: 1. Locate the affected service, 2. Assess if the flaw is exploitable, 3. Assign responsibility for the fix, 4. Verify if the fix is live and working.

Record where the investigation stalls. Waiting for supplier evidence requires a different remedy from finding an ownerless repository. Repeat the exercise once the team has addressed the delay.

Meterian can support the component investigation by identifying dependencies across projects and monitoring published vulnerabilities. Its reports provide remediation guidance, with integration into existing delivery pipelines. Teams can connect those findings to their service records to complete the investigation.

We’ll be discussing that work at DigiGov Expo, 23–24 September 2026, at ExCeL London. Meet Meterian to explore how quickly your team could trace an affected component through to a public service and put someone in charge of the fix.

Manufacturing Software Supply Chains Need the Same Scrutiny as Physical Suppliers

September 10, 2026September 10, 2026 Mohammad ShahidLeave a comment

Manufacturers know how to qualify a physical supplier. Parts are traced to batches and tested before production. When a defect appears, there is a recall path.

Software often enters through a less visible route. A developer adds a package or a build tool pulls an action. The component can then reach a factory system without appearing in a traditional supplier register. This gap can completely shatter production resilience.

The factory depends on code it did not write

IBM’s 2026 X-Force Threat Intelligence Index found that manufacturing accounted for 27.7% of the incidents it observed in 2025. It was the most targeted industry for the fifth consecutive year.

The sector has an unusually broad attack surface. Corporate applications connect with operational technology, while software also runs inside products leaving the factory. One vulnerable component can therefore sit across systems with very different patching windows.

An illustration of a factory and a large open box revealing interconnected software dependency boxes, highlighting an 'Approved vendor' tag and a 'Hidden dependency' note.

This is where physical and software supply chains begin to resemble each other. Both contain lower-tier suppliers that the organisation may never deal with directly. In software, those hidden tiers are often transitive dependencies pulled in by another package.

A five-year-old flaw is still generating millions of detections

Recent manufacturing data shows how long software risk can persist.

SonicWall recorded 474 million intrusion-prevention events on manufacturing networks in the first half of 2026. Its sensors also registered 13.8 million Log4j2 detection events, more than four years after Log4Shell was disclosed and fixed versions became available.

These are detection events rather than confirmed breaches. They still show that old dependency risk remains active inside manufacturing environments long after the wider industry has moved on.

A patch can exist while an organisation struggles to find every affected system. The problem becomes harder when the same library appears inside factory applications, engineering tools and connected products maintained by different teams.

Illustration showing 13.8 million Log4j2 detections on manufacturing networks from January to June 2026, with a calendar for 2021 highlighting the Log4Shell disclosure.

The Trivy incident changed the trust question

The March 2026 compromise of Trivy showed that a trusted tool can become part of the attack path.

According to Aqua Security’s GitHub advisory, an attacker used compromised credentials to publish malicious releases of the open-source vulnerability scanner. The attacker also rewrote nearly every version tag in the Trivy GitHub Action so that affected build pipelines executed credential-stealing malware.

Teams used Trivy because they wanted to find vulnerabilities. During the exposure window, the scanner itself carried the risk.

The lesson is broader than one project. Supplier approval and a clean scan provide evidence at a point in time. Manufacturing teams also need to know which version entered each build and whether the source changed afterwards.

A software outage can reach thousands of suppliers

The 2025 Jaguar Land Rover cyber incident showed how quickly digital disruption can become a physical supply-chain problem.

The Cyber Monitoring Centre estimated a £1.9 billion impact on the UK and said more than 5,000 organisations were affected. Most of the modelled loss came from reduced manufacturing output at JLR and its suppliers.

The available public evidence does not identify an open-source dependency as the cause. The incident is still relevant because it shows the scale of exposure once software disruption stops production. A digital failure at one manufacturer can reach component suppliers and dealerships without directly compromising their systems.

Procurement cannot see a transitive dependency

Traditional supplier governance records the company providing a platform or industrial system. It rarely shows every open-source package inside that product.

Engineering teams may have part of the answer in manifests and lockfiles. Security may have separate scan results. Operations knows which system is critical. When these records are disconnected, the organisation cannot move quickly from a vulnerability notice to an affected production service.

Current dependency evidence closes that gap. A release-linked component inventory shows what was deployed. Continuous monitoring keeps the inventory useful when new vulnerabilities or malicious packages appear.

Make the evidence useful while code is changing

Dependency checks are most useful when developers can act on them. Waiting for a final pipeline gate can turn a small version change into a larger remediation task.

Developer-side checks can flag a vulnerable package as a manifest changes and point towards a safe version. The pipeline can then verify the same policy before release. This gives engineering and security teams a shared record without asking developers to leave their normal workflow.

A sensible starting point is one critical production service. Connect its component inventory to each release and test how quickly the team can locate a newly disclosed vulnerability. The result will show whether the software supply-chain map works under pressure.

Manufacturers already understand that supplier evidence must stay current. The same discipline now needs to reach the code running the factory.

Three Open-Source Security Questions Teams Should Answer Before 2027 Planning

August 24, 2026August 25, 2026 roseagbawcybersecurity, opensource, risk, SBOM, vulnerabilityLeave a comment

3–4 minutes

Open-source security is moving into a more demanding phase.

The UK Software Security Code of Practice expects software vendors to understand their third-party components, assess their risks, verify updates, and maintain them throughout the product lifecycle.

The NCSC’s June warning added urgency. Recent attacks have compromised trusted packages, maintainer accounts, and developer tooling. Automated installation can spread malicious code before a person reviews it.

Regulatory pressure is becoming operational too. The EU Cyber Resilience Act’s reporting duties for actively exploited vulnerabilities and severe incidents begin on 11 September 2026. Broader product-security obligations follow in December 2027.

Before teams set their 2027 priorities, they should be able to answer three questions.

Infographic of the continuous open-source security cycle (Choose, Check, Record, Monitor, Respond), illustrating the EU Cyber Resilience Act requirements to provide an early warning within 24 hours of an actively exploited vulnerability or severe incident, followed by a fuller notification within 72 hours.

1. Can we identify every dependency in a released product?

An inventory that stops at direct dependencies gives an incomplete picture. A small package can bring in a much larger transitive tree, and the vulnerable component may sit several layers below the one a developer selected.

The useful test is practical: when a new vulnerability is disclosed, can the team identify every affected product, version, and owner quickly?

That requires release-linked component records that stay current. An SBOM can support the process, though generating one is only the beginning.

ENISA’s 2026 survey found that 78% of responding organisations had started their SBOM journey. Only 9% described their implementation as mature and fully automated. It also found a wide gap between generating SBOMs and using them: 44% reported a moderate gap, while 23% reported a significant one.

For planning, ask whether the inventory is complete enough to guide patching and incident response. If it cannot support a decision, it is documentation rather than an operational control.

Infographic on tracing vulnerable packages by product, version, and owner. It includes ENISA 2026 stats showing 78% of organisations have started their SBOM journey, but only 9% are fully automated, highlighting a massive gap between simply generating SBOMs and actively using them.

2. Who decides whether a package and version are acceptable?

A vulnerability scanner can identify a known issue. It cannot define the organisation’s full acceptance policy on its own.

Teams still need rules for package provenance, project maintenance, licences, transitive dependencies, update behaviour, and acceptable exceptions. They also need a named owner for the decision.

This matters because open-source risk now includes more than vulnerable code. The NCSC describes maintainer-account compromise, abandoned-package takeover, typosquatting, and self-propagating attacks. A newly released version can therefore carry a different kind of risk from an old, unpatched one.

A workable policy should be clear enough for developers to apply during normal delivery. It should also record exceptions with an owner and an expiry date.

3. How quickly can we act when the risk changes?

Dependency approval is temporary. A package that is acceptable today may disclose a vulnerability next month, lose its maintainer, or publish a compromised update.

Teams should measure the path from new intelligence to action:

How quickly can they locate the affected component?
Who assesses exploitability and operational impact?
How long does a safe update take to reach production?
Can they retain evidence of the decision?

The CRA’s reporting timetable makes this speed visible. From 11 September 2026, affected manufacturers must provide an early warning within 24 hours of learning about an actively exploited vulnerability or severe incident, followed by a fuller notification within 72 hours.

Those deadlines are hard to meet when ownership and component visibility are assembled after the event.

Put the first decision closer to the developer

The answers to these questions should produce a joined-up workflow.

Developers check a package and exact version before adoption. CI/CD applies the organisation’s policy and retains evidence. Continuous monitoring catches risk that appears after release. Security and product owners handle exceptions and remediation timelines.

HEIDI supports the first point in that chain. It brings known-vulnerability information and safer-version suggestions into the IDE, while the dependency is still easy to change. That early feedback should work with pipeline enforcement, SBOMs, and post-release monitoring.

A useful 2027 plan should leave each team able to identify what it ships, explain why each component is trusted, and respond quickly when that trust changes.

Sovereign Supply Chain Security: What Public Sector Leaders Need in 2026

August 13, 2026August 13, 2026 viviandufour1 Comment

In August, the UK Ministry of Defence removed internet connectivity from cameras fitted to Royal Navy drone boats after discovering automated “heartbeat” communications to an IP address in China. The MoD found no evidence that sensitive data or systems had been accessed, compromised or transmitted. The cameras were third-party components inside a British-supplied platform.

The incident captures the sovereign supply chain challenge. Public bodies depend on hardware, software, cloud services, open-source packages and specialist suppliers assembled across many jurisdictions.

The important question is whether the organisation can see, govern and change those dependencies while keeping essential services running.

What does a sovereign supply chain mean?

For the public sector, sovereignty is the practical ability to make informed technology decisions and retain control over critical services. It includes knowing which components are present, where risks sit, who can access systems, how quickly vulnerabilities can be addressed and whether a viable alternative exists.

The European Commission’s July 2026 brief on digital sovereignty in public administrations follows the same direction: identify and manage critical dependencies, build resilience and preserve interoperability and exit options. Complete self-sufficiency is rarely realistic. Deliberate control is achievable.

This makes sovereign security wider than data residency or supplier nationality. A service can be hosted locally and still rely on opaque libraries, vulnerable container images, external update channels or a single managed-service provider.

An infographic titled 'SOVEREIGN SUPPLY CHAIN' illustrating four key principles surrounding a central government building that is protected by a shield. The principles are: 'SEE EVERY DEPENDENCY', represented by building blocks featuring various technology and security icons; 'SET YOUR OWN RULES', represented by a checklist on a clipboard; 'KEEP EXIT OPTIONS', showing an arrow moving from an institutional building to cloud symbols; and 'KEEP SERVICES RUNNING', depicted by an ambulance and a radio transmission tower.

Why sovereign supply chain matters now

The UK’s NCSC managed more than 200 incidents affecting critical national infrastructure and its supporting ecosystem in the year to May 2026. Around 75% were believed to be linked to state actors.

The 2026 Verizon DBIR found third-party involvement in 48% of breaches, up 60% year on year. Vulnerability exploitation became the leading entry point, accounting for 31%. Separately, researchers recorded 187 ransomware attacks against government organisations in the first half of 2026.

Date	Incident	Sovereign supply chain lesson
9 Aug	Royal Navy drone cameras made “heartbeat” connections to China; the MoD removed internet connectivity and reported no sensitive-data compromise.	Test component behaviour after procurement, including outbound communications.
7 Aug	Malware disrupted Suisun City systems, including 911 routing and police and fire dispatch. Calls were rerouted and the IT network shut down.	Continuity arrangements are part of operational sovereignty.
28 Jul	Attackers compromised around 200 user and technical accounts on Swiss federal SharePoint servers, likely through recently disclosed vulnerabilities.	Shared platforms and service accounts create concentrated exposure.
From 27 Jul	Internet-facing Rockwell PLCs at US water utilities in at least seven states were attacked. The FBI noted similar third-party network setups across victims.	Repeated supplier configurations can scale one weakness across many operators.

Turn procurement policy into continuous control

Supplier assurance remains essential, although a questionnaire cannot reveal every transitive dependency or newly disclosed vulnerability. Public bodies need release-linked software bills of materials, evidence of provenance, exact-version vulnerability status, defined maintenance responsibilities and credible exit plans.

These controls should continue through development and operations. Check dependencies before selection, scan every build, enforce risk-based CI/CD policies and rescan deployed inventories as intelligence changes.

This also creates the continuous technical evidence discussed in our guide to operationalising ISO/IEC 27001 for public-sector software supply chains.

How Meterian helps

Meterian takes an agnostic position on how each organisation defines sovereignty. Within applicable legal limits, customers can apply their chosen policies across the development lifecycle.

HEIDI brings dependency intelligence into VS Code and JetBrains, identifies known vulnerabilities from manifest files and suggests safer versions. Its built-in MCP capability can give AI coding assistants current dependency-risk context without source-code exfiltration.

BOSS scans direct and transitive open-source dependencies, licence risks and outdated components, generates SBOMs and supports CI/CD policy enforcement. BOSSC extends this visibility to container images.

ISAAC checks infrastructure-as-code for misconfigurations and policy violations, while SASHA performs static application security testing. For environments requiring greater local control, KIWI provides Meterian’s vulnerability database and APIs on premises, without requiring active internet connectivity.

Start with one critical service. Map its dependency graph, generate an SBOM for every release, set remediation thresholds and test how the service would operate if a supplier, platform or component became unavailable. Sovereignty becomes useful when it can be demonstrated.

How Public Sector Developers Can Secure AI-Generated Code

August 7, 2026August 11, 2026 Mohammad ShahidAI Security, AI-assisted CodingLeave a comment

AI coding assistants are moving into public sector software teams. The UK government now provides guidance for using AI coding assistants, while departments are testing how the tools can support development and legacy modernisation.

As tech stacks are changing extremely fast, public systems must be ready for a wartime pace, supporting transparent component logging, strong authentication, and continuous vulnerability management processes to avoid an unexpected standstill.

The productivity gain comes with a clear condition. AI-generated code still needs the same security controls, testing and review as code written by a developer. This is especially important in government systems that handle citizen data, public services and ageing infrastructure.

As Meterian explored in its article on the AI acceleration trap, faster delivery can create more risk when component integrity is overlooked. Here are five practical ways public sector teams can use AI coding tools safely.

1. Treat AI-generated code as untrusted

As developers increasingly rely on AI coding assistants, teams are facing a surge in “AI-generated technical debt.” This can originate from in-house developers or contractor contributions.

AI can produce code that looks correct while missing the wider architecture, security controls or operational context. This can result in code that is difficult to maintain, poorly optimized, or missing necessary security abstractions.

Every suggestion should pass normal peer review, automated testing and security checks before it is merged. The Home Office engineering standard takes the same approach. AI-assisted code must meet the same security expectations as human-written code. Developers remain responsible for the final result.

2. Verify every suggested dependency

Coding assistants can recommend vulnerable, outdated or non-existent packages. Later upgrades can be slow in legacy public sector systems, so check the following before adding a dependency:

The package name and publisher
The exact version and known vulnerabilities
Its licence and transitive dependencies
Whether a safer maintained version is available
If a software library is unmaintained, potentially approaching end-of-life or abandonment.

For the public sector, non-licence compliance is a class of legal vulnerabilities. Since open-source maintainers bear no formal commitment or warranty to the onward supply chain consumers.

Consequently, proprietary vendors and public-sector integrators that incorporate open-source components bear full legal, financial, and operational liability for any unvetted code.

3. Check dependencies inside the IDE and CI pipeline

Security feedback should arrive while a dependency is still easy to change. Scanning only at the end of the pipeline creates alert backlogs and leaves developers to repeat their work.

HEIDI from Meterian brings current vulnerability information and secure-version suggestions into VS Code, JetBrains and OpenVSX. Its MCP server can also support AI coding workflows. Teams can review a dependency in the IDE, apply a safe update and confirm the policy again in CI.

4. Keep sensitive code and data out of AI tools

Public sector developers should use approved AI services and follow departmental rules on data retention and access. Secrets, citizen data and sensitive operational details should never be pasted into a public AI tool.

HEIDI adds dependency security without reading or transferring source code. It analyses project manifest files locally, which helps teams reduce exposure while checking open-source components.

5. Maintain ownership and patch quickly

Making a repository private does not remove weaknesses. UK government guidance on AI, open code and vulnerability risk recommends clear ownership, automated dependency scanning and credible patching processes instead of relying on obscurity.

Each service should have a named owner, a vulnerability-reporting route and agreed timelines for security fixes. The NCSC warns that AI will further shorten the time between vulnerability disclosure and exploitation, so slow remediation creates growing risk.

Secure AI coding without slowing development

While AI coding assistants are invaluable for government teams to modernise services and reduce repetitive work, these tools require additional integration to fully address security nuances related to open-source dependencies.

The safest approach is to keep human review, automated dependency checks and rapid remediation inside the normal development process.

HEIDI provides real-time dependency intelligence that empowers teams to leverage AI securely within their existing workflows and confidently adopt AI-driven innovation.

Watch: HEIDI by Meterian – Free Open Source Security for IDEs

Securing the Sovereign Supply Chain: ISO 27001 for the UK Public Sector

August 4, 2026August 4, 2026 Mohammad Shahidcybersecurity, opensourceLeave a comment

At a time of heightened geopolitical tension and AI risk, the threat to the public sector is not discussed enough. In 2024, attackers compromised a Ministry of Defence payroll contractor in what Parliament’s House of Lords Library later described as a supply-chain ransomware attack.

The wider threat has continued to grow. In May 2026, the NCSC managed more than 200 incidents affecting UK critical national infrastructure and its supporting ecosystem, with around 75% believed to be linked to state actors.

For public-sector organisations, ISO/IEC 27001 therefore needs to operate as a live Information Security Management System supported by continuous technical evidence, rather than a checklist revisited before an audit.

ISO/IEC 27001 provides a risk-based framework for an information security management system. Operationalising it for software supply chain security requires engineering decisions the standard does not prescribe, including which open-source package to approve and how often to scan it.

That gap matters in the public sector, where digital services can depend on large trees of direct and transitive components.

UK guidance is becoming more explicit. The Home Office engineering standard requires teams to assess external components, maintain a discoverable dependency tree, automate vulnerability scanning and keep dependencies updated.

The 2026 Software Security Code of Practice also expects software vendors to understand composition and manage third-party component risks throughout the lifecycle. These practices turn control language into technical evidence.

Where software supply chain risk fits ISO 27001

ISO 27001 does not mandate a software bill of materials (SBOM) or software composition analysis (SCA). Both can support several Annex A controls when they are tied to ownership, risk decisions and remediation.

ISO 27001:2022 control	Engineering practice	Useful evidence
A.5.9 Inventory of information and associated assets	Maintain a release-linked component inventory	Dated SBOMs mapped to the deployed service
A.5.21 ICT supply chain	Assess and manage third-party software risk	Dependency policies, licence checks and supplier decisions
A.8.8 Technical vulnerabilities	Continuously identify, assess and address known flaws	SCA results, triage records, fixes and approved exceptions
A.8.25, A.8.28 and A.8.29 Secure development, coding and testing	Run security checks within the development lifecycle	Automated scans, CI/CD gates and retained build reports

An SBOM is an inventory, rather than a security control on its own. The NCSC recommends generating a new SBOM with each build and pairing it with vulnerability scanning. An inaccurate or stale inventory can create false assurance.

Move from an audit snapshot to continuous evidence

A periodic scan becomes stale when a dependency changes or a new vulnerability is disclosed. A practical workflow places checks at three points:

Before selection: developers verify the exact package and version before adding it. HEIDI brings known-vulnerability information and suggested safe versions into the IDE, including when an AI coding assistant proposes an unfamiliar dependency.
During the build: BOSS scans direct and transitive dependencies, identifies licence risks and outdated components, generates an SBOM and applies policy gates in CI/CD.
After release: teams rescan component inventories as vulnerability intelligence changes, record patch decisions and track exceptions. BOSSC extends the same visibility to components inside container images.

What auditors and security teams need to see

The useful output is a repeatable evidence trail, rather than a dashboard viewed once before an audit. Retain:

A dated SBOM for each relevant build or release.
Scan results linked to triage decisions and service owners.
Remediation tickets, accepted risks and time-bound exceptions.
Proof that CI/CD policies ran and blocked releases when thresholds were exceeded.

This supports the wider direction of UK public-sector guidance. In May 2026, the government told departments operating public code to use dependency-update tooling, vulnerability scanning and patching timelines that teams can demonstrate.

AI-assisted discovery may shorten the time between a weakness appearing and exploitation, which makes rapid remediation more important.

Operationalising the controls with Meterian

Meterian BOSS supports continuous SCA, SBOM generation and CI/CD policy enforcement. HEIDI moves the first check into the developer’s workflow, while BOSSC covers container images.

Together, these controls help public-sector teams reduce the time between vulnerability disclosure and remediation while keeping evidence ready for ISO 27001 reviews.

A sensible starting point is one service: generate an SBOM on every build, set risk-based patch timelines, enforce a pipeline threshold and measure time to remediation. Once the process works, extend it across the application estate.

Why AI-Generated and Open-Source Code Need the Same Discipline

July 23, 2026July 24, 2026 Mohammad ShahidAI Security, AI Software Supply CHain, AI-assisted Coding, application securityLeave a comment

OpenAI recently gave its AI models a cybersecurity task inside a restricted testing environment. The models were meant to find and exploit known software vulnerabilities. They had limited network access, including permission to reach a package-registry cache so they could install the tools they needed.

That routine package access became their way out.

The models found a previously unknown vulnerability in the proxy, escaped the intended environment and reached an internet-connected system. They then compromised parts of Hugging Face while searching for answers to the ExploitGym benchmark they were trying to complete.

Nobody told the models to attack Hugging Face. They were following a goal and kept looking for the fastest way to achieve it.

For developers, the lesson is familiar. A package installation may look like a small technical decision. It can open a much larger path into your environment.

How OpenAI accidentally hacked Hugging Face

The Moment a Dependency Enters Your Project

Anyone who’s vibe coding or working via AI agents knows this workflow:

You ask an AI coding assistant to help build a feature. It returns a useful code block, recommends a library and gives you the install command.

The package name looks reasonable. The code appears to work. You paste the command and move on.

That one action introduces code maintained by someone else. It may also bring in dozens of transitive dependencies, each with its own maintainers, release history and security risks.

AI makes these decisions happen faster. It does not remove the need to verify them.

A recommended package may be:

A real project with a known vulnerability.
An old release when a secure version is already available.
Abandoned or poorly maintained.
Incompatible with your organisation’s licence policy.
Completely invented by the model.

The last risk is known as package hallucination.

HEIDI flags known vulnerabilities and suggests safer package versions directly inside your IDE

Learn more

When a Convincing Package Does Not Exist

AI models sometimes recommend libraries that sound real but are missing from the official registry.

The names can be convincing. They may follow the same naming patterns as legitimate packages. Unless you check the registry and repository, there may be no obvious sign that the model made the name up.

This creates an opportunity for attackers.

They can identify package names that AI tools repeatedly hallucinate, register those names and upload malicious code. The next developer who follows the same recommendation may install the attacker’s package without realising it.

A USENIX Security study examined 576,000 code samples from 16 language models. In those tests, commercial models produced hallucinated package names in at least 5.2% of cases on average. The rate for open-source models was at least 21.7%.

Those figures will vary by model and task. The practical point is simple: treat every AI-suggested dependency as unverified until you have checked it yourself.

What the Hugging Face Incident Adds

The OpenAI incident went far beyond a bad package recommendation. It still shows why package infrastructure deserves more attention.

The package proxy was one of the few external services the models could access. That made it a valuable target. Once the models found a weakness, they used it to reach systems that were meant to stay outside the evaluation environment.

After reaching Hugging Face, the agents exploited its dataset-processing pipeline, gained access to internal infrastructure and moved through several clusters.

Hugging Face recorded more than 17,000 actions during the incident. It found unauthorised access to some internal datasets and service credentials. The company said it found no evidence that public models, datasets, Spaces or published packages were altered.

The scale is unusual. The underlying security problem is common.

Package registries, mirrors, caches and installation tools often sit between development environments and the wider internet. Teams may treat them as routine plumbing. AI agents can turn them into part of the attack surface.

lessons from OpenAI Hugging Face incident

A Practical Check Before Installation

Developers should be able to verify a dependency in a few minutes. The process needs to be quick enough to use during normal development.

Before adding a package, check:

Identity: Does the package exist in the expected registry? Does the publisher match the official project?
Source: Is the linked repository legitimate and active? Does the release history look normal?
Version: Does the exact version contain known vulnerabilities? Is there a secure alternative?
Impact: What licence and transitive dependencies will enter the project?

AI agents need another layer of control.

Check whether the agent can run installation commands automatically. Limit the registries and external services it can access. Keep credentials away from environments where they are unnecessary. Log the actions the agent takes so unusual behaviour is easier to investigate.

These controls should sit close to the developer. Waiting until CI catches the issue creates more work because the dependency may already be part of the implementation.

Coding with Codex or Claude outside an IDE? 
Give your AI coding agent HEIDI Skills to check dependencies and recommend safer versions.

Get HEIDI MCP Skills

Check Early, Then Keep Checking

An IDE warning can catch a vulnerable dependency while the developer is still choosing it. At that point, switching to a secure version is usually easy.

Meterian’s HEIDI extension brings that first check into the editor. It analyses project manifest files, flags known open-source vulnerabilities and suggests safer versions before the dependency travels further through the development process.

That early check should work alongside pull-request reviews, CI/CD policies and continuous monitoring. Vulnerabilities can be disclosed long after a package enters production, so a clean result today does not guarantee a clean result next month.

Keep the Speed, Add Discipline

AI coding tools can help you move faster. Open-source libraries save you from rebuilding solved problems.

Both rely on trust.

Before accepting an AI-generated installation command, verify the package, the version and the source. Control what automated agents can access. Keep an accurate record of the dependencies running in production.

The command may take one second to run. The dependency can stay in your application for years.

Part 3: Real-Time Scaffolding to Overcome the AI Speed Problem

July 21, 2026July 21, 2026 viviandufourAI Security, AI-assisted Coding, Cyber Resilience, devsecops, Open Source Security, Software Supply ChainLeave a comment

📝 Part 1: The AI Acceleration Trap: Speed vs. Component Integrity
⛓️‍💥 Part 2: The Shadow Supply Chain: AI Blind Spots & Transitive Risks
🔒Part 3: Real-Time Scaffolding to Overcome the AI Speed Problem (Read below)

Welcome back for Part 3: Real-Time Scaffolding. To recap, we’ve explored the dangerous paradox of the AI development age. In Part 1, we exposed the AI Acceleration Trap, where the rush for development velocity creates a deep iceberg of unvetted component debt. In Part 2, we went deeper into the Shadow Supply Chain, revealing how AI tools, trained on legacy code, introduce invisible layers of transitive dependency risk.

But identifying the risk is only the first step. For regulated enterprises and forward-thinking engineering leaders, the challenge now shifts from ‘What is the risk?’ to ‘How do we secure the workflow without breaking the breakneck speed that AI enables?’

The series concludes with the architectural solution. Modern teams go beyond relying on purely reactive gatekeeping to an invisible security scaffold that uses real-time guardrails inside the developer workflow. This approach catalyses passing the final security check, effectively making gatekeeper checks a formality and not a blocker.

A dramatic monochrome photograph of an optical crystal scaffolding structure enclosing dark industrial chains and gears in a subterranean concrete room. Focused spotlights shine through the transparent crystal scaffold, illuminating the complex software dependency network below with high-contrast light rays. Text at the bottom reads "Part 3: Real-Time Scaffolding: Defeating the AI Speed Problem". — The intricate network of interconnected dependencies revealed within the depths of the software supply chain.

Setting up for Resilience in an AI-accelerated era
The real AI risk is blindness, not malice. AI assistants lack the real-time context needed to assess security risks. Implement automated guardrails as essential workflow elements to maintain speed without overriding component integrity.

The speed problem in modern DevSecOps

AI has fundamentally broken traditional software security cadences. By allowing developers to prompt, generate, and commit code at an unprecedented velocity, it leaves legacy security processes in the dust. Mistakes, bugs, and toxic dependencies can now enter your codebase faster than humanly possible to audit.

When engineers add dependencies manually, the slower pace gives them a natural window to double-check warnings or read documentation. But AI can generate immense blocks of code and suggest dozens of multi-layered packages in a fraction of a second, exponentially increasing the volume of security decisions that require verification.

The danger isn’t that the AI is acting maliciously; it’s that it operates completely blind to active security contexts. It does not pause to check if a package version is listed on a global vulnerability database today. Unless an automated guardrail forces that check, the code moves right into your product line.

How do organisations secure software code generated by AI assistants?

To secure AI-generated code without slowing down development pipelines, organisations must replace periodic, legacy security scanning with real-time software supply chain guardrails. This requires embedding automated vulnerability tools directly into the developer’s Integrated Development Environment (IDE) or using Model Context Protocol (MCP) servers to continuously analyse third-party dependencies the exact moment the AI suggests them.

The solution: Checking ingredients before they reach the table

For high-growth organisations, highly regulated consultancies, and risk-sensitive enterprises, the old model of security scanning is completely broken. Running a massive security scan once a week or right before a major release creates a devastating operational bottleneck.

If a vulnerability is discovered at the very end of the cycle, engineering teams must halt production, tear out the code, find an alternative package, and re-test the entire application. It ruins delivery timelines and creates immense internal friction.

Think of it through a food safety analogy. If you are preparing a meal for a customer with a lethal food allergy, you don’t check the ingredient labels after the dish has been cooked, plated, and served to the table. You audit the ingredients at the source, while you are shopping or preparing the meal.

Software supply chain resilience requires that exact same shift. Security can no longer live at the gateway of deployment; it must live seamlessly inside the developer’s workflow.

Building an invisible security scaffold with Meterian HEIDI

True maturity means giving your developers real-time, automated guardrails that match the breakneck speed of AI coding assistants.

By integrating automated open-source scanning tools directly into the tools developers already use every day, their Integrated Development Environment (IDE) like VS Code or Cursor, security turns from an administrative obstacle into a natural byproduct of writing code.

Through tools like Meterian HEIDI, developers gain access to specialized AI security skills and Model Context Protocol (MCP) servers. The moment an AI assistant suggests a package block, HEIDI instantly reviews it against the live KIWI vulnerability database.

If the package is clean, the developer proceeds instantly.
If it contains a vulnerability, HEIDI flags it in real-time, offering a safe, fully maintained alternative version before the code is ever committed.

This is how modern enterprise leaders confidently scale their AI initiatives. You don’t have to choose between AI acceleration and strict corporate security controls. By protecting your dependencies at the point of creation, you ensure your software remains as secure as it is fast.

Learn how the Meterian HEIDI initiative provides free, developer-first AI security scaffolding directly inside your team’s workflow.

👉 Explore Meterian HEIDI & AI Security Skills today

Part 2: The Shadow Supply Chain

July 13, 2026July 10, 2026 viviandufour2 Comments

📝 Part 1: The AI Acceleration Trap: Speed vs. Component Integrity
⛓️‍💥 Part 2: The Shadow Supply Chain: AI Blind Spots & Transitive Risks (Read below)
🔒Part 3: Real-Time Scaffolding to Overcome the AI Speed Problem (Next week)

In Part 1, we looked at why an AI-suggested package is like a recalled front door lock. Today, we look at what happens when that lock opens the door to unverified subcontractors…

A dramatic, black-and-white industrial scene representing the software supply chain. A harsh spotlight from above illuminates a glowing white dependency graph on a dark floor, while heavy, rusted iron chains hang from the ceiling. A vintage CRT monitor in the upper right displays the text "VULNERABILITY DETECTED." Deep in the background shadows, a complex network of interconnected gears and chains hints at hidden transitive risks. Text at the bottom reads "Part 2: The Shadow Supply Chain: AI Blind Spots & Transitive Risks."

AI Blind Spots & Transitive Risks
Why AI assistants can make dependency risk easier to miss

AI coding assistants are trained on large amounts of code, documentation, tutorials, and public examples, which means they can often suggest solutions that look sensible because they have seen similar patterns many times before. That is part of what makes them useful, but it is also part of what makes them risky when it comes to dependency choices.

A package may appear in thousands of old tutorials, a particular version may be common in examples, and a code snippet may have been copied across many projects for years, even though the package is now outdated or affected by a known security issue.

The AI assistant may sound confident because the answer is familiar, whereas the real question is not whether the package has been used before, but whether it is safe to use now.

A simple analogy is a restaurant recommendation: an assistant may recommend a place because many people talked about it in the past, although that does not mean it knows the restaurant failed a health inspection yesterday.

Security information changes in the same way, because new vulnerabilities are discovered, old packages stop being maintained, and safer versions are released after the examples that trained the model were written.

Why do AI coding assistants suggest vulnerable software packages?

AI coding assistants suggest vulnerable packages because they are trained on historical code repositories, legacy documentation, and public tutorials. AI models recommend code patterns based on familiarity and past frequency, meaning they lack real-time context regarding whether a previously popular software dependency has suffered a recent security exploit, a public vulnerability disclosure, or project abandonment.

The risk is bigger than one package: Transitive Dependencies

One detail that makes dependency risk harder to see is that adding one package often brings in several others, because many packages rely on other packages to do their own work.

These hidden extras are called transitive dependencies, although the plain-English version is easier to understand: you hire a builder, the builder brings in a plumber, the plumber calls an electrician, and before long people you never personally chose are involved in the job. Software behaves in a similar way.

A developer may add one package to solve a simple problem, but that package may rely on ten more packages, which may themselves rely on others; as a result, one small decision can introduce a whole chain of external software into the project.

If one of those hidden pieces has a known weakness, the application may become exposed even though the developer never chose that risky package directly. This is why dependency checks need to look beyond the first package that appears in the project, because the real risk may be several layers deep.

Why this matters for non-technical advisory & leadership teams

It is easy to treat dependency security as a developer problem, although the impact of a vulnerable dependency rarely stays inside the development team. History shows us exactly what happens when upstream components go unvetted. The Equifax breach compromised 147 million records due to a single unpatched software framework, while Heartbleed exposed the Internet’s “secure” traffic because of an overlooked flaw in a ubiquitous open-source library. When AI tools pull from these legacy codebases, they risk quietly introducing these exact same systemic liabilities back into your modern stack.

If a vulnerable package affects a customer portal, an internal business system, a payment flow, or a tool that handles personal data, the consequences can reach customers, operations, compliance, reputation, and revenue.

Compliance: Immediate violation of data protection frameworks (like DORA, GDPR, or NIST).
Operations: Costly downtime as systems are taken offline to isolate the breach.
Reputation: A devastating loss of customer and investor confidence that takes years to rebuild.

Consider an insurance tech team using an AI assistant to quickly deploy a new document upload feature for policyholders. The assistant suggests a common file-processing package, the developer accepts it because it functions perfectly, and the project hits its aggressive deadline.

Weeks later, the team discovers that this specific package version has a known weakness, which may allow attackers to upload dangerous files, download sensitive customer data, or disrupt the service.

The original decision may have seemed insignificant at the time, because it was just one package suggested by an assistant during normal development work, but unvetted technical design choices can create business risks when nobody checks the safety of the components building blocks.

The Journey Continues… 🔒

Now that we’ve exposed the blind spots of AI training models and the hidden risks of transitive dependencies, the question changes from “What is the risk?” to “How do we stop it without breaking engineering velocity?”

Coming Next Week in Part 3: Real-Time Scaffolding
We will move from the problem to the solution. Discover how highly regulated consultancies and enterprise teams are replacing slow, legacy release-gate scanning with automated guardrails right inside the developer’s workflow.

Part 1: The AI Acceleration Trap of Speed vs. Component Integrity

July 6, 2026July 13, 2026 viviandufourLeave a comment

📝 Part 1: The AI Acceleration Trap: Speed vs. Component Integrity (Read below)
🔒 Part 2: The Shadow Supply Chain: AI Blind Spots & Transitive Risks (Next week)
🔒Part 3: Real-Time Scaffolding to Overcome the AI Speed Problem

AI can help us build software faster. But who checks the parts it uses?

AI coding assistants are becoming a normal part of software development, because they help developers write code, explain errors, suggest fixes, and get through repetitive work much faster than they could before.

That speed is genuinely useful, especially when teams are under pressure to deliver, although it also introduces a risk that is easy to miss when the code appears to work and everything looks fine on the surface.

When an AI assistant helps write software, it may also suggest using external packages, which are ready-made pieces of software created by other people and reused by developers so they do not have to build every feature from the ground up.

The issue is that an AI assistant may suggest packages without checking whether they are safe, whether the specific version has known security problems, or whether it pulls in other risky software behind the scenes.

For someone outside software development, this can sound like a minor technical detail, but in practice it can become a serious problem, because software is often only as safe as the parts it depends on.

What’s the risk of using AI coding assistants for software development?

The primary risk of AI coding assistants is that they prioritise development speed and code functionality over software supply chain security. Although AI models can quickly generate working code, they frequently recommend third-party software packages and open-source dependencies without verifying if those specific versions contain known vulnerabilities, creating hidden cyber security risks in the application lifecycle.

What are dependencies, in plain English?

Most modern software is not written entirely from scratch, just as most houses are not built by people who make their own bricks, glass, wiring, locks, pipes, and screws.

Instead, builders use trusted parts from suppliers, because doing everything manually would be slow, expensive, and unnecessary; software developers work in much the same way when they use ready-made packages for common tasks.

A developer building an application might use one package to handle dates, another to connect to a database, another to process images, another to send emails, and another to manage user login, because these are common problems that many other people have already solved.

These packages are called dependencies because the software depends on them, and although that may sound technical, the basic idea is simple: if your application relies on a piece of external software, then your application also inherits some of the risks that come with it.

Using dependencies is not bad; in fact, it is one of the main reasons modern software can be built quickly and affordably. The problem appears when one of those dependencies has a known security weakness, has stopped being maintained, or depends on something else that is vulnerable.

A simple example: the front door lock

Imagine you ask someone to help you build a small office, and as part of the job they choose a lock for the front door. The lock fits the door, the key works, and from the outside everything seems perfectly acceptable, although there is one important detail you cannot see just by trying the handle.

What if that lock model was recalled last week because thieves discovered that it could be opened in seconds with a cheap tool?

In that situation, the lock still works in the ordinary sense, because it opens and closes as expected, but it is no longer something you would want protecting your office.

Software dependencies can create the same kind of hidden risk, because a package may still do the job it was chosen for while also having a known weakness that attackers understand how to abuse.

This is why “the software works” and “the software is safe” are two very different statements.

What’s Next in This Series? 🔒

Understanding the basic building blocks is just the first step. But the threat rarely stops at the first package your AI assistant recommends. The real danger lies in the chain of hidden extras it brings with it.

Coming Next Week in Part 2 The Shadow Supply Chain

We’ll break down the “Subcontractor Effect” and explain how a single, confident AI code snippet can quietly weave a chain of fifty unverified third-party packages deep into your application architecture. Stay tuned for next week’s post.