Imagine a council officer using AI to summarise a resident’s case. The summary reads well. Checking it means reopening the original documents, and the next appointment starts in five minutes.
How much time has the tool actually saved? Who takes responsibility if it missed something important?
For public sector leaders planning for 2027, the biggest AI challenge is making room for careful judgement inside services already under pressure.
At DigiGov, our team heard speakers acknowledge staff anxiety about AI and job losses. Conversations also returned to the quality of data feeding these systems and the need for people to assess their outputs.
Those concerns echo wider findings. In July 2026, the government’s Local AI team reported feedback from 60 councils: guidance was too abstract for everyday decisions, while skills to procure and govern AI remained a problem.
AI Challenges for the Public Sector
Human oversight needs time and authority
A named reviewer cannot provide meaningful oversight without access to the original information or permission to challenge the result.
Take the council summary. A useful review process would identify facts requiring verification, such as dates or eligibility details. The officer should be able to trace those facts to their source.
For each workflow, agree:
Which outputs need checking before anyone acts on them?
Who can pause the process when something looks wrong?
What happens when that person is unavailable?
How will the service continue if the AI tool is switched off?
Then rehearse those steps with a deliberately flawed output.
A research by the Ada Lovelace Institute in February 2026 found an AI-generated summary that incorrectly suggested a client had expressed suicidal thoughts. A social worker caught the error before it entered the case note. Had it gone unchecked, it could have influenced later decisions about that person’s care.
Use that kind of mistake to test your own safeguards. Give staff a fictional case summary containing a consequential error and ask them to check it against the source material under realistic time pressure.
Can they catch and correct it before anyone acts? If checking takes longer than the workflow allows, build that time into the service before expanding AI use.
AI Can Still Make Critical Mistakes
Supplier AI features need their own review
One concern raised in our DigiGov discussions was AI entering departments through software they already use. An existing supplier relationship can make a new feature feel familiar before anyone has assessed what it changes.
A meeting assistant, for example, could introduce new questions about where recordings go and how long they remain there.
Ask suppliers to disclose new AI features before activation. Establish what information each feature can access and whether the organisation can disable it. Name a service owner responsible for approving changes, with security and procurement support.
For AI agents that can take actions, define the permissions explicitly. Drafting a response and sending it to a resident requires different controls.
AI-generated software still needs security checks
The same responsibility extends to development. Developers we met at DigiGov were using or exploring AI coding assistants, raising a practical question about how their suggestions are checked.
Government guidance updated in August recommends additional vulnerability scanning and checking dependencies introduced by coding assistants against trusted sources.
An AI-generated function may work while relying on a vulnerable open-source package. Review the code and scan its dependencies before release. Keep monitoring afterwards, because a component’s risk can change when a vulnerability is disclosed.
Put checks where people already work
For 2027 planning, start with one live workflow. Assign an owner and test the review process before expanding it. Budget for the checking work.
Meterian supports the software security part of that approach. HEIDI helps developers identify vulnerable dependencies and suggested fixes while coding. Meterian’s wider platform provides continuous dependency monitoring and licence risk checks within development pipelines.
Talk to Meterian about checking the open-source components in your public services, including software built with AI assistance.
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.
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.
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.
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.
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.
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.
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.
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.
Stop Coding in the Dark: Bringing Real-Time Security to Agentic AI Development
The software supply chain has become the backbone of business, but with that reliance comes escalating risk. Attackers are moving faster than defenders, targeting not just production environments but the very tools and processes developers rely on every day.
Recent statistics underline the urgency:
API vulnerabilities rose 168% in 2025, with 91% of organisations reporting API-related security incidents. Misconfigured APIs now expose 10 billion records annually, making them the fastest-growing attack vector.
GitHub repositories remain a high-value target. With 35% of repos public, malicious actors exploit developer missteps to compromise projects upstream.
Self-hosted runners used in CI/CD pipelines are another weak link. Research shows 35% of enterprises leave themselves exposed to attacks that allow lateral movement across repositories and organisations.
For AI adoption and secure coding to scale among thousands of developers of all skill levels, the industry needs both tools and guardrails to work together at machine-speed. Agentic coding (using assistants like Cursor or Windsurf) has increased the risk of “blind trust” in AI-proposed code because LLMs often lack current threat intelligence.
Shifting Attacker Focus
The Q2 2025 vulnerability data reveals a telling pattern. Exploited software included remote access tools and document editing platforms, as well as low-code/no-code development tools and even frameworks for building AI-powered applications.
What’s striking is that the vulnerabilities weren’t found in AI-generated code itself but in the frameworks supporting it. As development technologies evolve, attackers follow — exploiting weaknesses wherever developers least expect them.
The Developer’s Blind Spot
Despite these trends, many organisations still rely on security checks late in the lifecycle — in CI/CD pipelines or after deployment. This leaves developers coding in the dark, unaware that the open-source components and dependencies they’re pulling in could already be vulnerable.
By the time an issue is flagged, code is often deeply integrated, making remediation costly, disruptive, and in some cases, too late.
This is the gap attackers exploit: the developer’s blind spot inside the IDE. ‘Blind Trust’ becomes a liability.
Security Where You Code
Closing that gap means moving security upstream, directly into the developer’s workflow. That’s where HEIDI, Meterian’s new free IDE plugin, comes in.
HEIDI integrates with Visual Studio Code and JetBrains IDEs, providing:
Automatic vulnerability scanning of open-source dependencies (direct and transitive).
One-click fixes, so developers can remediate issues instantly.
Lightweight reports with actionable insights — without leaving the IDE.
Privacy by design: no source code ever leaves the machine, only manifest files are scanned.
Built for operational resilience: now finding a vulnerability at the workbench is a “5-second fix,” preventing downstream disruption or a firm’s existential crisis.
By embedding this capability where code is actually written, HEIDI removes the guesswork and makes secure coding a natural part of the process. It transforms security from a late-stage barrier into an everyday guardrail.
Building Resilience From the Start
The rise of API exploitation, exposed GitHub repos, and vulnerable CI/CD runners clearly shows that attackers no longer wait for production. They strike wherever software is created, stored, or moved.
Organisations that want to stay ahead need to shift left — making vulnerability assessment and remediation part of the developer’s daily environment.
HEIDI makes this shift practical. It empowers developers to ship code that is secure from the start, reducing security debt, lowering patching costs, and protecting the supply chain before vulnerabilities can spread downstream.Stop coding in the dark. Arm your AI companion with the real-time security signals it’s been missing. Download HEIDI for free on the Visual Studio Code or JetBrains Marketplace today
The United Kingdom’s public sector is under increasing cyber pressure.
Government departments, healthcare systems, local councils, and public institutions now rely heavily on interconnected digital infrastructure. Much of that infrastructure was built years ago and still depends on ageing systems that are difficult to update, monitor, or secure properly.
At the same time, public sector software increasingly relies on open-source components. These dependencies help teams develop systems faster and reduce costs, but they also introduce software supply chain risk when vulnerabilities are not tracked or patched consistently.
Together, legacy infrastructure and unmanaged open-source dependencies are creating a difficult security environment. Attacks are becoming more disruptive, more expensive, and harder to contain.
Legacy Systems Remain Widespread Across the Public Sector
Legacy technology remains one of the biggest cyber security weaknesses inside UK public infrastructure.
The National Audit Office warned in 2025 that many government systems remain “high risk” due to age, unsupported software, and outdated architecture.
The UK government’s own Cyber Action Plan similarly acknowledged that some legacy systems cannot be defended effectively using modern security controls.
Many of these systems:
Were built decades ago
Cannot be patched easily
Depend on outdated software stacks
Lack compatibility with modern security tooling
Require specialist maintenance knowledge
Replacing these systems is difficult. Large public sector upgrades are expensive, operationally risky, and often slowed by procurement complexity.
As a result, vulnerable systems frequently remain active long after safer alternatives are available.
Why Legacy Systems Increase Cyber Risk
Older systems are easier targets for attackers because they often lack basic modern protections.
Many do not support strong identity controls, modern encryption standards, or real-time threat monitoring. Some are no longer supported by vendors, meaning newly discovered vulnerabilities may never receive official patches.
Legacy systems also create wider operational risk because they are rarely isolated. Most are connected to newer applications, databases, cloud environments, or third-party services.
That means a vulnerability in one outdated system can become an entry point into a much larger network.
The National Audit Office has warned that ageing systems increase the likelihood of successful attacks and make incident recovery more difficult once breaches occur.
Download Meterian’s 2026 Predictions EBook. Master the New Rules of Software Sovereignty to understand why traditional AppSec models are breaking down and how leadership teams can prepare.
Open-Source Software Adds Another Layer of Risk
Open-source software now powers most modern applications.
Public sector organisations use open-source frameworks, libraries, and packages across internal systems, citizen services, cloud applications, and third-party platforms.
The challenge is visibility.
Modern applications often contain hundreds or thousands of software dependencies, including transitive dependencies that developers may not even realise are present.
If organisations do not know which components exist inside their software, they cannot know which vulnerabilities affect them.
Research consistently shows that the majority of modern software contains open-source code. Many applications also contain known vulnerabilities that remain unresolved long after patches become available.
This is becoming a major concern for governments worldwide because vulnerable open-source components can spread risk across multiple systems at scale.
Want to see how vulnerable open-source dependencies can be identified earlier in development? TryHEIDI by Meterian, a free IDE plugin built to help developers find vulnerable packages and move to safer versions while they code.
The Log4j Problem Showed How Fast Risk Can Spread
The Log4j vulnerability remains one of the clearest examples of software supply chain risk.
Even years after the Log4Shell vulnerability was disclosed and patched, vulnerable versions continued appearing inside production systems worldwide.
Reports in 2025 showed that a significant percentage of Log4j downloads still contained vulnerable versions despite years of public awareness.
The issue was never simply the existence of the vulnerability itself. The larger problem was that many organisations did not know where Log4j existed inside their software stack.
This is the core software supply chain challenge facing public sector organisations today.
A single vulnerable dependency can quietly exist across government systems, suppliers, applications, and service providers without clear visibility.
Cyber Attacks Against Public Services Are Increasing
The cyber threat facing the UK public sector continues to intensify.
The National Cyber Security Centre reported a growing number of nationally significant cyber incidents in its latest annual review. State-backed threat actors, ransomware groups, and financially motivated attackers continue targeting public infrastructure because disruption creates immediate pressure.
Several recent incidents have shown how severe the consequences can become.
Healthcare Systems
The NHS has experienced repeated cyber incidents linked to outdated infrastructure and unpatched vulnerabilities.
These attacks disrupted services, delayed operations, and exposed sensitive patient information. Healthcare systems remain particularly vulnerable because they depend on large interconnected environments that are difficult to modernise quickly.
The British Library Attack
The cyber attack against the British Library became one of the UK’s clearest examples of how legacy technology can worsen the impact of a breach.
The incident caused major operational disruption and lengthy recovery efforts. Later analysis linked the severity of the attack partly to historic underinvestment in cyber resilience and ageing infrastructure.
Local Government Disruption
Local councils across the UK have also faced growing cyber pressure.
Attacks have disrupted housing systems, benefits administration, and citizen services. In some cases, organisations were forced to revert to manual processes while systems recovered.
For public services, cyber incidents quickly become operational problems rather than isolated IT failures.
Why This Is Becoming a National Resilience Issue
The combined effect of legacy systems and open-source vulnerabilities creates broader national risk.
These issues are interconnected.
A vulnerable open-source component inside a legacy environment can affect multiple public services simultaneously. Once attackers gain access, interconnected systems make lateral movement easier and containment harder.
The consequences can include:
Service disruption
Data breaches
High remediation costs
Operational downtime
Delayed digital transformation
Increased exposure to state-sponsored attacks
Public infrastructure now depends heavily on software resilience. When software supply chains become difficult to monitor, national resilience becomes harder to maintain.
What Needs to Change
The UK public sector does not need to stop using open-source software. That would be unrealistic and counterproductive.
The priority is visibility.
Public sector teams need to know which open-source components are inside their software, where vulnerable versions are being used, and which fixes are available. This needs to happen continuously, because new vulnerabilities emerge every day.
Security also needs to move closer to development. If vulnerable dependencies are only discovered late in CI/CD, or after deployment, remediation becomes slower and more expensive.
The strongest approach is to make dependency security part of the normal development workflow. Developers should be able to see vulnerable packages, understand the risk, and move to safer versions before code reaches production.
Conclusion
The UK public sector faces a layered cyber security problem.
Legacy systems create weak points. Unmanaged open-source dependencies add software supply chain risk. Together, they make public services more exposed to attacks that can disrupt operations, expose data, and damage national resilience.
Modernising public infrastructure will take time. But visibility over open-source risk can improve now.
Knowing what is inside public sector software is the first step toward protecting the services people rely on every day.
UK manufacturing is becoming more exposed to cyber disruption as factories rely on connected systems, industrial software, cloud platforms, and third-party suppliers.
Ransomware and denial-of-service attacks are among the most damaging threats. They can stop production, delay shipments, disrupt supply chains, and create direct financial losses.
For manufacturers, cyber risk now reaches far beyond IT systems. It affects uptime, safety, fulfilment, customer commitments, and business continuity.
UK Manufacturers Are Facing a Higher Level of Cyber Disruption
A 2026 ESET survey found that 78% of UK manufacturers experienced a cyber incident in the past year.
Among affected firms, 95% reported direct business impact, 53% suffered financial loss, 44% faced supply chain disruption, and 39% missed customer or supplier commitments. Some incidents caused losses above £250,000.
The wider UK picture is also concerning. The UK government’s Cyber Security Breaches Survey 2025 found that 43% of UK businesses experienced a cyber breach or attack in the previous 12 months. The figure rose to 67% for medium businesses and 74% for large businesses.
Manufacturing is especially exposed because downtime has an immediate cost. A locked system or unavailable application can quickly become a halted line, a missed order, or a broken supplier commitment.
Ransomware Remains the Primary Cyber Threat
Ransomware remains one of the most serious threats to UK organisations. The National Crime Agency describes ransomware deployment as the UK’s greatest cyber serious and organised crime threat, with risks to Critical National Infrastructure and national security.
A ransomware attack usually blocks access to systems or data until a payment is demanded. Modern ransomware campaigns often go further. Attackers may steal data, threaten to publish intellectual property, pressure suppliers, and use public disruption to force negotiations.
This is dangerous for manufacturers because production depends on availability. If planning systems, engineering files, logistics platforms, or connected production environments become unavailable, the impact can move quickly from digital systems into physical operations.
The Jaguar Land Rover cyber incident showed how severe that impact can become.
The Cyber Monitoring Centre categorised the 2025 JLR incident as a Category 3 systemic event, estimating a £1.9 billion UK financial impact and effects across more than 5,000 UK organisations.
Production lines were halted for several weeks, and suppliers faced cancelled or delayed orders. That case underlines the central point: a major cyber incident in manufacturing can become a supply chain event.
DDoS Attacks Can Stop Access to Critical Services
Denial-of-service attacks create disruption by overwhelming websites, applications, or networks. The Information Commissioner’s Office describes a DoS attack as an attempt to stop normal system function by overloading it and creating a virtual “traffic jam.”
In a distributed denial-of-service attack, the attacker uses many connected devices to flood the target from multiple points.
For manufacturers, DDoS risk is not limited to public websites. It can affect customer portals, supplier platforms, remote access systems, cloud dashboards, and connected industrial services.
UK government data shows denial-of-service attacks affected 15% of large businesses that experienced a cyber breach or attack, compared with 5% of businesses overall.
The practical impact is simple. If key systems are unavailable, production planning slows down, orders cannot be processed, suppliers lose visibility, and internal teams are forced into manual workarounds.
Why Manufacturing Is Especially Vulnerable
Manufacturing has a different risk profile from many office-based sectors.
Many firms still run legacy operational technology alongside newer digital systems. Older systems are often difficult to patch, hard to monitor, and expensive to replace. As IT and OT environments become more connected, weaknesses in one area can create exposure in another.
Manufacturers also depend on complex supplier networks. A vulnerability in a third-party system, open-source component, software update, or connected service can create risk across several organisations.
This makes software supply chain security critical. Modern manufacturing companies often use internal applications, vendor platforms, cloud services, containerised workloads, and open-source libraries.
Open source software makes up an estimated 80–90% of software application code, which means dependency risk is now part of operational resilience.
Attackers understand this. They do not always need to attack the factory floor directly. They can exploit exposed software, vulnerable dependencies, weak supplier access, or outdated components that sit inside the wider digital environment.
The Preparedness Gap
Many organisations still lack the right level of preparation.
The UK government’s Cyber Security Breaches Survey 2025 found that only 32% of businesses had a business continuity plan covering cyber security. For micro businesses, the figure was 27%.
That gap matters because prevention alone is not enough. Manufacturers need to know what software they use, which components are vulnerable, which systems are exposed, and how quickly they can recover when something goes wrong.
A strong cyber resilience plan should include:
Tested backup and recovery processes
Network segmentation between IT and OT systems
Regular vulnerability assessment
Software Bill of Materials visibility
Continuous monitoring of open-source components
Incident response planning
Clear supplier security expectations
Developer workflows that catch risks before release
Cyber Essentials, penetration testing, and annual reviews all have value. However, they cannot replace continuous visibility. New vulnerabilities are disclosed every day. A system that was safe last month may be exposed today.
Where Meterian and Cybersecurity Services Fit
Meterian helps organisations reduce software supply chain risk by giving security and engineering teams clearer visibility into open-source dependencies, vulnerable components, and remediation priorities.
Meterian-X provides continuous review of open-source libraries, risk prioritisation, actionable reporting, policy controls, and alerts that help teams fix issues earlier in the software development lifecycle.
For manufacturing businesses, this matters because software now supports production planning, supplier coordination, logistics, customer delivery, connected devices, and internal operations.
Meterian can help teams:
Identify vulnerable open-source components
Monitor dependencies continuously
Prioritise the most urgent risks
Generate clear reports for developers and security teams
Support governance and compliance workflows
Integrate security checks into DevSecOps pipelines
Scan application codebases and container images
Meterian’s HEIDI plugin also brings open-source vulnerability detection directly into the IDE. It helps developers catch and resolve vulnerable dependencies during the coding phase, before issues reach production systems.
That early visibility matters. The later a vulnerability is found, the more expensive and disruptive it becomes to fix.
Want to understand where open-source vulnerabilities may be hiding in your software supply chain? Use Meterian to scan your codebase, monitor dependencies continuously, and give your teams clear remediation paths before risk reaches production.
Building Cyber Resilience in UK Manufacturing
UK manufacturers cannot remove every cyber risk. They can reduce exposure, improve visibility, and make disruption less damaging.
That starts with treating software supply chain security as part of operational resilience. Manufacturers need to know which components they rely on, where vulnerabilities exist, and which fixes should come first.
The most resilient organisations will be those that connect security with engineering, operations, procurement, and risk management. Continuous scanning, dependency visibility, and fast remediation should become standard controls for any software-driven manufacturing environment.
Conclusion
Ransomware and DDoS attacks are now serious operational risks for UK manufacturing.
The sector depends on connected software, complex suppliers, and production systems that cannot afford prolonged downtime. Recent incidents show that a cyberattack can stop production, delay orders, expose sensitive data, and affect thousands of connected organisations.
Manufacturers need more than periodic testing and basic compliance. They need continuous visibility across the software systems that support their operations.
Meterian helps manufacturers strengthen that visibility by scanning codebases, monitoring open-source dependencies, prioritising vulnerabilities, and supporting DevSecOps workflows.
On November 24, 2025, a second wave of the “Shai-Hulud” npm supply-chain attack began spreading through the JavaScript ecosystem. Attackers compromised maintainer accounts, published trojanized versions of legitimate packages, and used them as a worm to steal credentials and propagate into more projects and organizations.
What happened (in plain terms)
Trusted packages were silently replaced with malicious updates. When developers or CI systems installed these versions, the malware ran automatically during install.
The malware steals secrets at scale. The payload hunts for npm/GitHub tokens and cloud credentials, then exfiltrates them to attacker-controlled repos.
This wave is more capable than September’s. Researchers observed improved execution (including the Bun runtime) and broader credential targeting, making infection faster and harder to spot.
High-profile vendors were hit. Packages tied to Zapier, ENS Domains, Postman, PostHog, AsyncAPI and others were compromised, showing the attackers can reach well-run projects—not just obscure libs.
Why this matters to your business
This is not a “developer problem.” It is a direct enterprise risk:
Credential theft = account takeover. If a compromised package was installed in your environment, assume tokens and keys on that machine (or CI runner) may be stolen. That can lead to cloud breaches, source-code theft, or ransomware-style follow-on attacks.
Supply chain blast radius is huge. npm packages are deeply nested in modern apps. One infected dependency can taint many internal services before anyone notices. The campaign has already spread into tens of thousands of GitHub repos.
Regulatory and reputational exposure. If attacker access leads to customer data loss or service disruption, you face incident-response costs, disclosure obligations, and trust damage.
Immediate actions (next 24–72 hours) for your engineering team
If your engineering team uses Node.js / npm anywhere:
Identify exposure.
Compare your dependency lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) to the known malicious package/version list from current advisories
Search CI logs and build images for installs of those versions around Nov 24, 2025 onward.
If you are using Meterian, your teams will be notified tomorrow of any outstanding issue in your projects, while you can also manually trigger a rescan
Treat potentially affected environments as compromised.
Rotate all secrets that could have been accessible to developer machines or CI runners: npm tokens, GitHub tokens, cloud keys, DB creds, SaaS API keys.
Re-issue creds from a clean machine.
Hunt for persistence.
Check for unexpected GitHub Actions / CI workflows, new secrets, or unfamiliar deploy keys. Earlier Shai-Hulud waves used CI backdoors to keep access.
Block known bad versions now.
Add deny-lists in artifact proxies (e.g., npm registry mirrors) and internal policy gates.
Pin safe versions until the incident stabilizes.
Medium-term fixes (next few weeks) for your engineering team
Eliminate long-lived registry tokens. The attack leveraged stolen or weakly protected maintainer/CI tokens; reducing token lifetime and scope cuts worm propagation.
Harden CI/CD. Run builds in isolated runners with minimal secrets; require approvals for workflow changes.
Adopt dependency trust controls.
Prefer verified publishing / signed releases where available.
Add automated checks for sudden owner changes, new install scripts, or unusual publish patterns.
The take-home
Shai-Hulud 2.0 is a credential-stealing worm riding on the npm ecosystem. It spreads through normal installs, targets high-value developer and cloud secrets, and has already hit mainstream packages. The right executive posture is: assume compromise if exposed, rotate secrets fast, and tighten the software supply chain permanently. After last September’s incident, we predicted this would rear its ugly head again. Watch a brief update and warning shared earlier this week at one of our meetings.
Meterian CTO Bruno Bossola shares the growing blast radius and all consumers of NPM must stop it
This is a story under development!
Please keep an eye on this blog page, in the meantime here’s the list of affected packages and versions so far:
Benefits, Risks, and Real-World Attacks Involving Open Source in the Insurance Industry
The insurance sector is undergoing a rapid digital transformation, integrating technologies like artificial intelligence, big data analytics, blockchain, and cloud computing to better serve customers, optimise operations, and reduce fraud. Central to this shift is the growing reliance on open source software (OSS), tools, libraries, and platforms freely available for development, adaptation, and integration. From talking to c-suite members within all of the key sectors, OSS is recognised as beneficial but also seen as the “elephant in the room” as the risks are known but lack of experience in dealing with this layer is allowing threat penetration to be successful
While OSS empowers insurers with flexibility, innovation, and cost efficiency, it also introduces serious cybersecurity risks. This article explores how open source is being used in insurance, outlining the real-world consequences of cyber threats involving OSS, and assesses the risks of future attacks, especially as threats grow more sophisticated.
Why Insurers Use Open Source Software
Open source components are now integrated into nearly every stage of the software development lifecycle in the insurance industry. Key benefits include:
Cost savings: Avoiding high licensing fees of proprietary software.
Faster development: Leveraging pre-built libraries and frameworks. This acceleration is exponentially magnified by AI coding assistants, which rapidly retrieve and integrate open-source snippets directly into developer workflows and push development cycles into overdrive.
Community support: Tapping into vast global expertise and frequent updates.
Flexibility: Extending existing open source code to meet business-specific requirements.
Examples include:
Apache Kafka and Airflow for real-time data processing.
TensorFlow for machine learning in fraud detection.
PostgreSQL and MongoDB for scalable data storage.
OpenJDK as a base for Java-based enterprise applications.
With open source software, legacy systems have been replaced. Insurance software providers have gained ready-to-use features and deliver enterprise-grade and SaaS applications 50-60% faster, while avoiding vendor lock-in. They are seizing the opportunity to be part of a sector-specific open source software community to learn, grow, and contribute, with potential to shape the future direction at a sector level. Some of these ready-to-use features include policy, claim, and property management, as well as time tracking. There are also templates available to offer embedded insurance products seamlessly integrated into customer buying experiences.
The business-led software-driven transformation helps streamline processes, enhance risk assessment, and improve customer service. We can all appreciate the availability of cloud-based solutions that’s increased the ease of purchasing standalone and embedded insurance products in our daily digital experiences. Forgot to buy travel insurance when you booked your ski holiday? Not to worry, because the ski rental agency that’s selling ski lift passes on their mobile web app also lets you buy insurance when you checkout. Open source software is helping to drive innovation and specialized offers across sectors, benefitting sellers and resellers from greater access to customers wherever they are in their journey.
OSS Cybersecurity Risks of Open Source within the Insurance Sector
Open source code, while powerful, is not immune to vulnerabilities. Many packages are maintained by volunteers, and while updates and patches are released very quickly, it’s difficult for a company to keep the pace, because of lack of awareness and processes to handle them. A single unpatched library can serve as a gateway to an entire corporate network, and for insurance companies, this can expose sensitive personal, financial, and medical data.
Key risks include:
Direct cyber attacks Because of the lack of vulnerability scanning, simply by leveraging an existing vulnerability in one opensource component used on an internet facing system, a hacker could get access to all internal databases.
Supply chain attacks A piece of malicious code included in a widely used software library is then automatically incorporated into thousands of downstream applications that use the library, allowing the attackers to compromise a vast number of targets simultaneously.
License mismanagement and IP risksWhen using a non-business friendly licensed component, there’s a significant risk of being forced to publicly release your own intellectual property, leading to loss of competitive advantage and potential legal action.
Shadow IT and undocumented OSS use The unmonitored use of unapproved software, often by developers seeking speed and agility, creates significant security and compliance blind spots, as these tools operate outside of corporate governance and lack security patching or vulnerability tracking
Notable Cyber Attacks Involving Open Source
1.Log4Shell (CVE-2021-44228) – Apache Log4j
In late 2021, a critical remote code execution vulnerability was discovered in Log4j, a widely used Java logging library.
Impact on insurance: Many insurance firms used Java-based enterprise systems that included Log4j, making them vulnerable.
Exploitation: Threat actors could remotely execute arbitrary code on affected systems. APT groups including Charming Kitten (Iran) and APT41 (China) were linked to active exploitation.
2.SolarWinds Supply Chain Attack
Though not directly OSS-related, this 2020 attack brought attention to third-party code risks, including OSS components.
Relevance to insurers: Many insurers use SolarWinds or similar IT management tools, and the incident led to an industry-wide audit of third-party dependencies.
3.MOVEit Transfer Exploits (2023)
Cl0p ransomware gang exploited zero-day vulnerabilities in MOVEit file transfer software, affecting dozens of insurance, healthcare, and finance companies.
Relation to OSS: MOVEit, while proprietary, included OSS components and APIs, showing how OSS can be an indirect vector.
Victims: Included Genworth Financial, a major life and mortgage insurer.
Known Named Threat Actors Targeting the Sector
DarkSide / BlackCat: Ransomware-as-a-Service groups frequently use software vulnerabilities, including in OSS, for initial access.
FIN11 / Cl0p: A ransomware group known for targeting insurance and financial companies.
APT38 (North Korea): Known for financial theft operations, including targeting SWIFT and related financial systems.
Lazarus Group: Has targeted healthcare and insurance sectors, possibly for both espionage and financial gain.
Future Threat Landscape: What’s Ahead?
The future risk to insurers from open source-based attacks is growing due to:
AI-driven vulnerability discovery tools used by threat actors.
Complex OSS supply chains making traceability and patching harder.
Open source CI/CD toolchains being exploited (e.g., Jenkins, GitLab CI).
Emerging Concerns:
Malicious open source packages: Attackers upload poisoned libraries to repositories like npm or PyPI. Example: “ctx” and “phpass” malicious packages.
Dependency confusion attacks: Exploiting package naming inconsistencies in private/public repositories.
Insider threats: Poor OSS governance can lead to accidental introduction of vulnerable or backdoored code.
AI-generated dependencies: As engineering teams increasingly rely on LLMs (Large Language Models) to write software, there is a high risk of ‘code hallucinations’ in which AI introduces outdated, unverified, or entirely fabricated open-source packages that serve as low-hanging fruit for attackers.
Mitigation Strategies for Insurers
Adopt SBOMs (Software Bill of Materials) Maintain a comprehensive inventory of all open source components in use.
Automated Vulnerability Scanning Use tools like Meterian, WhiteSource, or Dependabot to detect issues early.
Continuous Monitoring & Patching Establish DevSecOps pipelines to enforce regular OSS updates. This must also include guardrails around AI coding assistants to ensure that all AI-generated suggestions are scanned and vetted as rigorously as human-written code.
Zero Trust Architectures Prevent lateral movement even if a component is compromised.
Training & Awareness Developers should be trained on secure OSS usage and license compliance.
The AI Arms Race
The introduction of AI into the software development lifecycle has inadvertently triggered an arms race. Just as insurers use AI to accelerate development, threat actors are leveraging the exact same technology to weaponise open-source ecosystems at an unprecedented scale. Cybercriminals now use LLMs to rapidly scan massive open-source repositories for zero-day vulnerabilities, turning the speed of AI against defenders. Furthermore, attackers are automating the creation of highly convincing malicious packages, complete with fake documentation and GitHub histories. These are maliciously designed to trick AI coding assistants into recommending them. When a developer accepts an AI-generated code snippet that includes one of these poisoned dependencies, it creates a highly efficient, automated attack pipeline that brings malicious code directly into the heart of an insurer’s infrastructure.
Conclusion
The open source revolution has undeniably propelled innovation in the insurance industry. But this double-edged sword demands a proactive cybersecurity posture. From high-profile exploits like Log4Shell to the growing sophistication of supply chain attacks, it’s clear that OSS security is no longer optional, it’s critical.
Insurers must recognise open source as both an opportunity and a threat. Only through comprehensive risk management, visibility, and cultural change can they unlock its benefits while shielding themselves from cyber catastrophe.
If you’re in insurance, now’s the time to put OSS security on the boardroom agenda.
The automotive giant’s recent cyber breach shows why continuous vulnerability assessment and open-source security are no longer optional.
Earlier this month, Jaguar Land Rover (JLR), the UK’s largest carmaker, was forced to shut down global IT systems after a cyberattack disrupted production across its factories. Plants in Solihull, Halewood, Wolverhampton, and Slovakia were halted. Operations in China, India, and Brazil also felt the ripple effect.
Thousands of employees and suppliers were sent home. Dealers and garages had to switch to manual operations during one of the busiest sales periods of the year: the September license plate registration window.
While no customer data breach has been confirmed, the attack reflects how deeply cybersecurity failures in the supply chain can damage both business operations and national economies. JLR contributes nearly 4% of the UK’s exports.
How the Jaguar Land Rover Attack Happened
The hacking coalition calling itself “Scattered Lapsus$ Hunters” claimed responsibility, posting internal screenshots as proof. Analysts link the group to earlier social engineering campaigns carried out by collectives like Scattered Spider, Lapsus$, and ShinyHunters.
This was not a sophisticated zero-day exploit. It was an attack on trust and resilience. By exploiting weaknesses in IT systems and operational processes, attackers triggered a shutdown that cascaded across JLR’s entire global network.
For an industry where every production hour counts, this was a direct hit to the supply chain.
Why Supply Chain Vulnerabilities Are a Critical Business Risk
The JLR case illustrates the stark reality:
Operational Technology (OT) systems are connected to IT systems. A breach in one disrupts the other.
Third-party risk is first-party risk. If suppliers or partners are compromised, your own resilience is at stake.
Downtime is as damaging as data loss. Even without stolen records, JLR faces millions in lost productivity and missed sales.
Open-source software is everywhere. Modern automotive systems depend on open-source libraries and components. Without continuous monitoring, hidden risks can remain undetected until it’s too late.
Where Vulnerability Assessment Makes the Difference
SBOM (Software Bill of Materials) to ensure visibility into every open-source component used in critical systems
Continuous monitoring for newly disclosed CVEs that could disrupt supply chains
DevSecOps integration to ensure remediation is part of the development and deployment pipeline
Incident readiness through real-time alerts and automated remediation guidance
How Meterian Helps Build Resilience
Meterian’s platform is built to detect, monitor, and remediate open-source vulnerabilities before they cause widespread damage.
BOSS (Business Open Source Sentinel): Provides real-time alerts for newly disclosed vulnerabilities across your software supply chain.
Sentinel: Automates vulnerability assessment and integrates into your CI/CD workflows to block unsafe code before it reaches production.
SBOM generation and ingestion: Gives you complete visibility into the components your business depends on, simplifying compliance and response.
AI-powered continuous monitoring: Ensures you are always ahead of emerging threats—whether in PHP, Java, .NET, or any other stack critical to your business.
Had such systems been in place across JLR and its suppliers, the blast radius of this attack could have been contained, with faster detection and remediation.
Why Open-Source Security Matters
The JLR breach demonstrates a truth we see across industries: open-source security is business security.
When 80–90% of modern applications depend on open-source components, every unpatched library becomes a potential entry point. The cost of ignoring these risks isn’t theoretical. It’s operational paralysis, financial loss, and reputational damage.
Don’t Wait for the Next Breach
The JLR cyber attack is not an isolated incident. It is part of a wider trend of supply chain attacks targeting global industries. The question is not whether open-source vulnerabilities exist in your systems—they do.
The question is: are you continuously monitoring and remediating them?
Now is the time to take control of your software supply chain.
👉 Learn how to strengthen resilience in our upcoming webinar: “What’s Open Source Security Got to Do with Resilience of the Supply Chain?” 📅 September 18, 2025 • 14:00 BST • 15:00 CET • 09:00 ET • 18:30 IST
