PHP2Shell: What to Check, Patch, and Verify

October 26, 2026 Mohammad Shahidcyber-security, cybersecurity, PHP, vulnerabilityLeave a comment

PHP2Shell can put a website at risk even when its application code is fully updated. The vulnerabilities sit in PHP itself: the software that runs many websites, online shops and business applications.

For organisations responding, installing a patch is essential. Getting that patch to every affected system requires knowing which applications use PHP, where they run and who maintains them.

Software visibility and vulnerability monitoring need to be part of everyday security and development work. When a critical vulnerability emerges, teams need an inventory they can act on.

What is PHP2Shell?

PHP2Shell is the name given to two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated critical at 9.2 out of 10. PHP released security updates on 21 October 2026.

The flaws involve how PHP handles memory and clears information between web requests. Under certain conditions, an attacker can exploit them to execute malicious code without logging in. Sensitive information held in memory may also be exposed.

The consequences can include stolen credentials, altered website content, unauthorised access to application data and interrupted services. The attacker initially gains the permissions of the PHP process; further damage depends on what that process can access.

Where the PHP2Shell Vulnerability Sits in Your System

Exploitation depends on the deployment and configuration. PHP identifies Apache mod_php as the highest-risk setup, but PHP-FPM and other configurations serving web requests also require attention.

Which organisations are affected by PHP2Shell?

Organisations running vulnerable PHP installations are in scope, including:

Website operators using PHP-based platforms such as WordPress, Drupal and Joomla.
Retailers and e-commerce businesses running Magento, WooCommerce or custom PHP storefronts.
Hosting providers and managed service providers responsible for multiple customers’ websites.
Public-sector bodies, healthcare providers and educational institutions maintaining PHP applications, including legacy services.
Software companies and other enterprises using PHP in customer applications, internal tools, containers or bundled third-party products.

These categories describe potential exposure, not confirmed breaches. An organisation’s actual position depends on its deployed software and patch status.

Smaller teams may struggle with limited security resources. Larger organisations face a different challenge: finding installations spread across departments, suppliers and older systems. ENISA specifically warns that products can contain PHP without their users realising it.

Check: Establish where you are exposed

Start by identifying the PHP installations that support your live services. Include production, staging and externally accessible development environments.

Your review should cover:

Servers and applications: identify the PHP version actually handling web requests.
Containers: check both the images being built and those currently deployed.
Hosting platforms and appliances: look for separately bundled PHP runtimes.
Managed services: ask providers whether affected PHP versions are present and what remediation they have completed.

Record the service, runtime or package version, deployment location, internet exposure and responsible owner. Prioritise publicly accessible systems while assessing the remaining installations.

An SBOM can support this work when it includes the relevant components and corresponds to the deployed release. An application dependency list alone may not capture the PHP runtime underneath it.

Meterian’s software composition analysis and container scanning help teams understand components in their codebases and images and identify known vulnerabilities within their scanning coverage. Teams must connect those findings to deployed services and confirm coverage of the relevant runtime.

Patch: Update the runtime and confirm vendor fixes

PHP published the following fixed releases:

PHP branch	First fixed release
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

Install the appropriate fixed release, a later supported release, or your vendor’s corresponding security package. PHP 8.1 and older no longer receive normal upstream releases. Some vendors provide backported fixes; otherwise, plan migration to a supported branch.

A backported fix may retain an older PHP version number. Confirm remediation through the vendor’s advisory and package details, rather than relying solely on the displayed upstream version.

For containers, rebuild and redeploy affected images. For managed hosting, obtain confirmation covering both websites and any separately maintained control-panel runtime.

If immediate patching is impossible, restrict exposure and consider taking affected public services offline. Firewall rules and configuration changes can reduce particular attack paths, but they do not replace the update.

Verify: Prove the change reached production

After updating, restart affected PHP workers or redeploy containers, then verify the build serving actual web requests. A command-line version check can report a different installation.

Before closing the remediation task:

Confirm deployment: check every affected instance and replica.
Test essential workflows: verify logins, checkout, uploads and other critical functions.
Review suspicious activity: examine unexpected processes, modified application files, outbound connections and unusual errors.
Retain evidence: record the fixed build, deployment time, checks performed and accountable owner.

Amazon observed an exploitation attempt on 17 October, so investigations should cover at least that date onward. Patching prevents further exploitation through the fixed flaws; it does not remove an existing backdoor or recover stolen credentials.

Keep Monitoring after the incident

PHP2Shell illustrates how AI-assisted research can make longstanding weaknesses practically exploitable. Organisations need a response process that keeps pace with new findings.

Integrate scanning into CI/CD, maintain release-linked inventories and monitor known vulnerabilities after deployment.

Where enabled, Meterian Sentinel performs daily checks against previously scanned components and can alert teams to newly identified vulnerabilities affecting their projects.

Knowing about a vulnerability is the beginning. Security improves when the right people can find affected systems, make the change and verify that it reached production.

The Post-Release SBOM Trap: Why 57% of Teams Generate Files That Don’t Protect Them

October 21, 2026October 21, 2026 roseagbawCyber Resilience, cybersecurity, devsecops, SBOM, vulnerabilityLeave a comment

3–5 minutes

MYTH: “We generate an SBOM on every build, so our software is secure.”
REALITY: Your build was clean yesterday. A new vulnerability dropped this morning.

When a new critical vulnerability hits the headlines, the first question leadership asks is simple: Are we affected?

In theory, if your Software Bill of Materials (SBOM) is ingested into a centralised platform, it should give you that answer in seconds. In practice, having an ingredient list does not stop food poisoning. Having visibility is only the starting line, managing risk continuously is the actual job.

The Poll: 57% Generate, but Who Actually Monitors?

In a recent poll across three LinkedIn security communities, we asked teams how frequently they generate an SBOM for the software they build:

Survey results from Meterian's poll on how often teams generate an SBOM. Highlighting four response categories with corresponding vote counts: 'Every build' (21 votes), 'We don’t generate SBOMs' (8 votes), 'Periodically or on request' (7 votes), and 'Every release only' (1 vote).

For teams still establishing their tooling, generating a comprehensive SBOM can be a heavy lift. For the many organisations that already automate this step, however, a deeper industry paradox emerges: generating the inventory was never the hard part.

The next challenge shifts from “Can you generate an inventory of your assets’ software?” to “What do you do with the inventory the day after you release software?”

The October Release Trap: When Unchanged Code Becomes Vulnerable

Consider a scenario every engineering team faces:

October: You ship version 1.2 of an application. The build passes with zero vulnerabilities, and the clean SBOM is filed away.
December: A zero-day advisory drops for a transitive logging library buried inside version 1.2.
The Reality: Not a single line of your code changed between October and December. Yet version 1.2 is now actively exploitable in production.

Infographic explaining the impact of new advisories on previously released software, highlighting steps for assessment of affected releases based on the SBOM.

This is the post-release blind spot. If your SBOM lives in a shared folder or static compliance portal, it is useless. Re-running a scan on your current main branch only tells you about current code, it tells you nothing about the 6-month-old release still running in customer environments or secondary cloud clusters.

An unchanged release can become vulnerable at any moment. To stay secure, your vulnerability monitoring must be continuous, even when your builds are not.

Moving from Static Visibility to Verified Remediation

Closing the gap between having an SBOM and fixing vulnerabilities requires three operational shifts:

1. Look Beyond the Surface

Checking only your main software packages gives a false sense of security. Most security flaws hide inside the background libraries those packages pull in. Whether a defect is buried 3 or 13 layers deep, your tools still need to catch it. This is an important part of securing your software supply chain.

2. Focus on Real Risk, Not Generic Ratings

A theoretical warning in a tool you only use for internal testing is rarely as urgent as a moderate issue sitting on a live, public-facing website. Default risk scores don’t know how your software is actually being used. Prioritisation means figuring out if a flaw can truly be exploited in your system.

3. Define Clear Responsibility for Fixes

In many organisations, a developer updates code, closes the tracking task, and moves on. Meanwhile, the older, vulnerable version of the software is still running for active users. Someone needs to be explicitly responsible for confirming that the verified fix actually reaches live systems before calling the job done.

4. Cover Your External Supply Chain

Managing software risk is not only a function of the software that your organisation creates but also a consideration of any third-party applications and vendor software operating in your environment. In today’s world of SBOM management, this means that external SBOMs from vendors must be ingested and monitored as well as your own internal software.

A flowchart illustrating the process of resolving a software bill of materials (SBOM) finding, including steps: find affected releases, assess the finding, make and test changes, and verify deployment.

A complete workflow requires four distinct checkpoints:

Application Owner: Identifies which live deployments run the affected component version.
Security: Assesses true reachability and exploit conditions.
Engineering: Builds, tests, and validates the safe upgrade path.
Fix Owner: Verifies that the patch actually deployed to all live environments before closing the ticket.

Continuous Defense with Meterian Sentinel

Visibility without automation turns your security team into full-time ticket managers. Meterian Sentinel bridges this exact gap. When enabled, Sentinel continuously and automatically checks your previously scanned releases against newly disclosed vulnerabilities daily, without requiring new builds, manual rescans, or developer intervention.

What is more important is that Sentinel is not limited to the software that your development teams write. Meterian can also consume external SBOMs whether they come from third party vendors, partners or existing pipelines.

When an advisory drops, you know immediately which deployments are exposed and what fix to prioritise.

A Quick Test for Your Team

Pick one application your organization shipped 3 to 6 months ago that hasn’t been rebuilt recently:

The Diagnostic Question: Can you identify within 5 minutes which open-source libraries it runs, whether any newly disclosed CVEs affect it, and who is responsible for verifying the patch in production?

The Reality Check: If that answer requires manual searches or cross-departmental meetings, your SBOM is an archive, not an active defense.

Explore how Meterian Sentinel automates continuous post-release risk management.

The Challenges of AI in the UK Public Sector Heading into 2027

September 30, 2026October 1, 2026 Mohammad Shahidcybersecurity, public sector, risk, vulnerabilityLeave a comment

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.

Infographic titled 'Public Sector AI: Five Challenges for 2027', outlining key challenges including staff confidence, security of AI-generated code, AI in existing software, time to check outputs, and clear accountability. — 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.

An illustration showing a hand pulling back a paper revealing an AI-generated care summary, highlighting the phrase 'The client expressed suicidal thoughts.' with a warning that the statement was invented by AI. The image emphasizes the importance of verifying AI summaries before they are officially recorded. — 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.

How Quickly Can You Trace Vulnerable Code Across Public Services?

September 14, 2026September 15, 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 security1 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.