Defend UK Infrastructure: Outsmarting the Ripple Effect of European Cyber Attacks

November 11, 2026 rodcobaincyber hacks, Cyber Resilience, cyber-security, Malware, NCSC, risk, SBOM, vulnerability, vulnerability managementLeave a comment

6–10 minutes

Strategic Alignment of Meterian Services and Technologies

Defend UK infrastructure Image, showing European attacks hitting the UK

Executive Summary

Following a wave of unprecedented cyberattacks on supermarket refrigeration systems across ten European nations, the UK National Cyber Security Centre (NCSC) has issued stark warnings regarding British critical national infrastructure (CNI). Adversaries have transitioned from virtual data theft to physical infrastructure sabotage; the UK utility, financial, supply chain, and food retail sectors must urgently recalibrate their defensive postures. Still the threat of Malware needs to stay high on the radar, Meterian offers an advanced Early Malicious Package & Threat Detection warning tool to combat covert attacks.

The mainland European attacks marked a paradigm shift in hostile cyber operations. Rather than deploying traditional data-encrypting ransomware, attackers bypassed advanced digital security controls to manipulate physical processes directly, specifically forcing continuous defrost cycles that raised commercial freezer temperatures to 50°C. The result was instantaneous food waste, massive inventory losses, and immediate supply chain paralysation. The NCSC has officially confirmed that these identical architectural vulnerabilities threaten organisations within the United Kingdom. Driven by sophisticated nation-state actors and highly weaponised cybercriminal syndicates, the cross-sector threat expectations for the UK, and the technological mechanisms required to defend against them, are detailed below.

Below we can see an example of 3 key sectors, the outcome of a successful attack on any of these will not just be the loss of name and reputation of the entity but massive accountability. The results will affect every walk of life from the food you can put on the table, the energy required to warm homes during the coldest part of the year and finance systems that drive the economy.

1. Food Retailers & Supply Chains: Physical Sabotage

Sector Threat Landscape

The disruptive and catastrophic attacks in Europe are being replicated and expose the vulnerability of the UK food retail sector, following this stark warning from France this week. This sector relies heavily on interconnected Operational Technology (OT) and legacy Internet of Things (IoT) systems. Expectations for this sector include:

Exploitation of Legacy Firmware:

• Weaponisation of Perishables: Adversaries are shifting focus away from financial data toward critical dependencies, including commercial HVAC networks, automated transport logistics, and raw manufacturing lines.

• State-Sponsored Hybrid Warfare: Because many European incidents completely lacked dark-web ransomware demands, security experts assess these campaigns as non-monetary, state-sponsored vectors designed to erode public confidence and create artificial scarcity. By embedding dormant, obfuscated malware into the open-source dependencies powering operational technology (OT), adversaries establish silent footholds to trigger grid disruptions on command, rendering standard perimeter defences obsolete.

The Meterian Defensive Alignment

To counteract the exploitation of legacy systems and automated logistics, organisations can leverage automated Software Composition Analysis via the Meterian Application Security Platform.

• Eradicating Legacy Vulnerabilities: Automated temperature frameworks and logistics frequently rely on third-party dependencies and open-source libraries. Meterian maps entire dependency trees, comparing code against its extensive Meterian Components Encyclopedia to flag outdated software components before threat actors exploit them.

• Hardening the Physical Supply Chain: By generating a comprehensive Software Bill of Materials (SBOM), organisations gain full visibility into the lower-tier software driving their HVAC and automated transport logistics. This closes the visibility gap that typically leaves connected IoT platforms unmonitored.

2. Utilities: Cascading Critical Infrastructure Risks

Sector Threat Landscape

The NCSC has explicitly warned that automated municipal systems remain a primary target for grey-zone geopolitical posturing, where cyber disruptions are engineered to stay just below the threshold of kinetic conflict.

• Physical Process Disruption: Hostile actors are actively targeting the automated mechanisms underpinning UK electricity switching stations, water treatment sluice gates, dam operations, and regional heating grids. These systems could and probably do have components that face the internet and are accessible to attack, such as the water company in South Staffordshire that hosted code from hackers for 2 years

• Geopolitical Blueprinting: A failed December 2025 cyberattack on Poland’s energy grid, which narrowly avoided plunging 500,000 citizens into freezing conditions, serves as the operational blueprint for campaigns currently being defended against in the UK.

The Meterian Defensive Alignment

When automated municipal infrastructure is targeted, the codebase governing switching stations and regional grids must be treated with absolute scrutiny. The use of AI has accelerated the speed attackers can infiltrate your systems, Meterian.io provides you with the tools to automate your defences and fight back. With HeidiSense Early Malicious Package & Threat Detection reduces detection time from days to minutes, rapidly decreasing attack risk. The addition of HeidiFX, introduces automated remediation, rapidly reducing the time from detection to remediation.

Defence: Utility operators deploying grid configurations via digital pipelines can utilise Meterian ISAAC (Infrastructure-as-Code scanner) to identify misconfigurations and structural flaws before they are provisioned into live environments.

• Containerised Security for OT Hubs: Many modern regional grids process telemetry data use containerized microservices. BOSS-C ensures container images running municipal infrastructure are continuously checked for underlying security or compliance risks.

3. Finance: Systemic Interdependency and AI-Scale Threats

Sector Threat Landscape

While less exposed to temperature-controlled OT, the financial sector faces severe compounding threats driven by automated vulnerability discovery.

• Systemic Interdependency: Data from the Bank of England indicates that 82% of UK financial institutions now rank cyber threats as a top-five systemic risk to macroeconomic stability.

• AI-Enhanced Scale: The immediate tactical threat stems from adversaries using artificial intelligence to scrape, identify, and exploit long-standing software vulnerabilities at an unprecedented speed and scale.

• Severe Liability and Financial Losses: Direct and cascading liabilities from successful ransomware variations are projected to reach up to £230M for mid-sized firms and up to £466M for tier-one financial corporations.

The Meterian Defensive Alignment

To fight AI-driven offensive speeds, defensive architectures must deploy equal automation and rapid vulnerability ingestion.

• Matching AI Scale with Live Intelligence: The Meterian Vulnerability Data Feed updates automatically at least every four hours, pulling from the National Vulnerability Database, GitHub, OSV, and proprietary GenAI monitoring engines. By combining this rapid intelligence feed with HeidiSense Malicious Package & Threat Detection, organisations compress the exposure window from months to minutes, neutralising newly disclosed flaws before adversaries can exploit them.

• Matching AI Scale with Live Intelligence: Financial DevSecOps pipelines embed the HEIDI IDE plugin, enabling software engineers to identify and remediate known open-source library flaws directly within their development environments before code is promoted to production. This helps reduce the systemic risk profile of core banking applications. When paired with HeidiFX, many common vulnerabilities and code-quality issues can be automatically remediated or flagged with suggested fixes, subject to developer review and existing governance controls.

“Move seamlessly from detection to correction so that upstream vulnerabilities are resolved before risk ever reaches production.”

4. The Strategic UK Response

To counter these multi-sector threats, the UK Government has committed substantial national resources to reinforce resilience across critical infrastructure. This includes an initial £60 million allocation for the immediate deployment of a national ‘Cyber Shield’ framework, alongside £70 million dedicated to establishing a specialist centre focused entirely on identifying and eradicating systemic software flaws within CNI pipelines.

Defensive Capabilities Cross-Reference

Threat Vector	Cross-Sectors Impacted	Meterian Defensive Capability	Operational Resilience Benefit
Legacy Firmware Exploitation	Food Retail, CNI, IoT Management	Codebase Scanner BOSS & HeidiFX	Rapid discovery and auto-remediation of vulnerable third-party components.
AI-Enhanced Vulnerability Scraping	Finance, Macroeconomic Frameworks	Vulnerability Feed KIWI, HeidiSense & GenAI Tracking	Enable code confidence with the latest threat intelligence. “Know Your Code Contents (KYCC) before adversaries do.” Prevent developers and coding agents from adding vulnerable code components that bad actors exploit.
Operational & Supply Chain Blind Spots	Utilities, Transport Logistics	Instant Software Bill of Materials (SBOM)	Total visibility into hidden transitive dependencies across multi-tiered suppliers to manage software risks, incident response events and recovery.
Unpatched Pipeline Deployments	Municipal Systems, Energy Grids	IaC Scanner ISAAC & Container Scanner BOSS-C	Block insecure container images and infrastructure code from entering critical environments.
AI Generated Code Risks	Finance, Utilities, Critical Infrastructure & Cross-Sector Dev Organisations	Static Analysis SASHA, HeidiSense & HeidiFX	Pro-actively detect and fix in real time the software weaknesses generated by AI Agents while coding.
Malicious Package / Supply Chain Malware	Finance, Utilities, Food, Retail Supply Chains	HeidiSense & HeidiFX	Early Detection before ingestion, with automated remediation

Strategic Recommendations for Enterprise Risk Management

Organisations operating within these sectors must move beyond traditional IT perimeter defense. Security frameworks must aggressively incorporate continuous OT vulnerability discovery, rigorous third-party supply chain audits, and strict adherence to the NCSC Cyber Essentials guidelines to mitigate cross-border cascading failures. By adopting continuous monitoring networks like Meterian-X, UK enterprises can directly align with the Government’s national ‘Cyber Shield’ initiative, securing the underlying open-source ecosystem before physical infrastructure vulnerabilities can be weaponised.

The warning signs are clear and the targets touched home last year with M&S and Jaguar Land Rover. Neighbouring supply chains have already been disrupted, and we should not be surprised as more attacks target the UK. Could your supply chain or critical systems become a test harness for adversaries, or will they be targeted directly to disrupt your business?

Learn how Meterian can help your organisation put automated defences in place without exorbitant AI costs. The best time to do this is on a clear day, i.e. before an incident disrupts your operations and turns your company into headline news. Book a 30-minute call with Rod, see first-hand how you can code resilience into an automatic reflex.

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.

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.

Why Developers Need Security in Their IDE: Lessons from Today’s Vulnerability Mess

May 21, 2026 viviandufourBeatOpenSourceVulns, cybersecurity, meterian, opensource, risk, security, vulnerabilityLeave a comment

2–4 minutes

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

Major supply chain attack on the NPM ecosystem

September 9, 2025November 28, 2025 viviandufoursupply chain, supply chain attackLeave a comment

by Bruno Bossola, initially published on LinkedIn on September 9, 2025. Republished here following second larger attack on November 24, 2025.

3–5 minutes

An illustration depicting various JavaScript code packages on a conveyor belt, with some showing green coding structures and others displaying red, corrupted code. Visible elements include digital threats such as skull icons and serpentine shapes representing malware, symbolizing a cybersecurity attack on software supply chains.

A number popular JavaScript code packages were compromised to spread malware, posing a significant threat to software supply chains. The malicious code, often obfuscated, was hidden within seemingly legitimate packages on the Node Package Manager (NPM) registry and executed during the installation process. This type of supply chain attack can lead to the theft of credentials, sensitive data, and even cryptocurrency.

How was the attack performed?

The attack on the debug and chalk packages was a sophisticated supply chain compromise that began with a phishing attack targeting the maintainer’s account. Attackers used a deceptive email, impersonating NPM support, to compromise the maintainer’s credentials. With access to the account, they published new versions of a number of popular JavaScript packages, including debug and chalk, with malicious, obfuscated code. This malware was a cryptocurrency stealer designed to run on a compromised machine, intercepting browser activity and targeting Web3 wallets. The malicious code would hook into network requests and use a fuzzy-matching algorithm to replace a user’s wallet address with an attacker-controlled one during a transaction, silently redirecting funds without the user’s knowledge.

What are the packages affected?

This is the current list at ~0830GMT on 09 September 2025:

ansi-regex 6.2.1
ansi-styles 6.2.2
backslash 0.2.1
chalk 5.6.1
chalk-template 1.1.1
color-convert 3.1.1
color-name 2.0.1
color-string 2.1.1
debug 4.4.2
error-ex 1.3.3
has-ansi 6.0.1
is-arrayish 0.3.3
proto-tinker-wc 1.87
simple-swizzle 0.2.3
slice-ansi 7.1.1
strip-ansi 7.1.1
supports-color 10.2.1
supports-hyperlinks 4.1.1
wrap-ansi 9.0.1

How do I know if I am affected?

If you are using Meterian and have Sentinel enabled, you’ve been notified. Please make sure to remove the offending package or move to a non-affected version, and then quarantine the affected systems.

If you are using Meterian, you will also notice that your builds are failing. This is normal, as now Meterian detects a vulnerable package and brings down the security score: the moment such score goes below your threshold, then the Meterian analysis will report a failure

In general, developers should audit their codebases for affected packages, monitor network logs for suspicious activity, and stay vigilant against compromised open-source libraries. This incident underscores the critical need for robust security practices in the software development lifecycle.

If you are a developer and you want to check if you’re affected, you can use a simple grep command in your project folder, where the packages are installed:

grep -r "_0x112fa8"

A Phishing campaign is actively ongoing targeting NPM maintainers!

This is an example of an email received by maintainers from the fake npmjs.help domain, which was created for the sole purpose of performing this attack. If you are an NPM maintainer, please be aware and disregard these emails!

Also, the website is now marked as malicious everywhere and is being taken down as we speak. Well done OSS community!

But I checked and I did not see any malicious code on GitHub!

The difference you’re seeing is due to how npm packages are published.

When a developer publishes a package, they’re not necessarily publishing the exact code from their GitHub repository. Instead, they run a command, npm publish, which creates a compressed file (a tarball) of the project’s files and sends that to the npm registry.

A maintainer can manually modify the files within this tarball before publishing, or their build process could include a step that modifies or adds code, such as minifying or obfuscating it. Because this process happens locally and the resulting tarball is sent directly to npm, these changes might never be committed to the public GitHub repository. This is why the code you see on the npmjs.com website can be different from the code in the associated GitHub

I am running a backend service: am I affected?

The code first confirms it’s running in a web browser by checking for the window object. Once it verifies the environment, it hijacks common methods for network requests and cryptocurrency transactions, specifically window.fetch, XMLHttpRequest, and window.ethereum.request. It also targets other wallet provider APIs.

This means the malware is designed to steal from end users who have a crypto wallet connected to their browser. While developers aren’t the primary target, they can also become victims if they visit an infected site and have an active wallet.

While the malicious code is designed to be activated in a browser, it is still a significant security risk to your backend service. Even though the malicious payload itself may not execute on the server, the compromised packages introduce a backdoor into your dependency chain. The best practice is to immediately update or remove the vulnerable packages to eliminate the risk of a future, more targeted attack on your server.

What’s next?

We will keep updating this article following the evolution of this incident. If you did not do it yet, please consider adding some defence in your pipeline: Meterian users using Sentinel were alerted overnight of the issue.

Best of luck, stay safe!

Update: Read the follow on attack in our blog post from Nov 24, 2025 about Shai-Hulud 2.0 worm.

SQL Injection is Back: A Critical ADOdb Vulnerability You Need to Patch Now

August 5, 2025August 29, 2025 viviandufourLeave a comment

Following our recent alert about the PHP AVideo exploit (CVE-2025-48732), another high-risk vulnerability has emerged: ADOdb SQL Injection – CVE-2025-54419. This newly discovered open-source vulnerability in the ADOdb database abstraction library affects a wide array of PHP applications. And yes—it puts your customer database at serious risk.

Therefore, businesses must patch now, or risk customer data loss and brand damage.

Why This Vulnerability Matters

SQL Injection remains one of the most exploited classes of software flaws in today’s threat landscape. The ADOdb vulnerability (pre-5.22.9 versions) allows attackers to manipulate query inputs in PHP applications using SQLite3, enabling them to execute arbitrary SQL commands and:

Access sensitive customer data
Delete or modify database records
Compromise connected systems

This flaw exposes an all-too-common weakness in open-source software components. When dependency management fails, it’s your customer data and digital brand trust on the line.

What is ADOdb and Who Uses It?

ADOdb is a widely used open-source database abstraction library that enables PHP developers to write flexible applications that work across:

MySQL
PostgreSQL
Oracle
Microsoft SQL Server
SQLite
DB2
Sybase
Firebird
Access ODBC
Informix
And more…

It acts as the middleware connecting your PHP app to its data. In modern e-commerce, SaaS, and media delivery platforms, ADOdb often underpins customer records, inventory systems, and transaction logs.

Understanding the Vulnerability (Technical Breakdown)

This SQL injection vulnerability exploits three ADOdb methods:

metaColumns()
metaForeignKeys()
metaIndexes()

If these methods receive a malicious table name, SQLite3 fails to properly escape the input—leading to arbitrary SQL execution.

❗ A single malformed input can compromise your entire database.

This isn’t hypothetical. It’s a known weakness. And it’s now indexed across vulnerability databases. Attackers are already probing for this entry point.

Real-World Impact

Think of it this way: a customer attempts to view their order history. But due to a code-level vulnerability, the attacker uses that same request to exfiltrate entire user tables or drop your product catalog. This can result in:

Permanent data loss
Corrupted analytics and reports
System downtime
Compliance fines (e.g. GDPR, PCI-DSS)
Severe brand reputation damage

A recent IBM report noted that data breaches tied to open-source component vulnerabilities cost businesses an average of $4.45 million per incident in 2024.

What You Should Do Now

Here’s your quick vulnerability assessment checklist for ADOdb:

✔️ Does your application use ADOdb prior to version 5.22.9?
✔️ Are you using the metaColumns(), metaForeignKeys(), or metaIndexes() methods?
✔️ Are your PHP apps connecting to a SQLite3 database?
✔️ Have you scanned third-party dependencies for known CVEs?

If you answered “yes” or “not sure” to any of these, your platform is at risk.

Mitigate risk now with a software composition analysis (SCA) tool that identifies vulnerable open-source components and provides auto-remediation.

Meterian’s Take

At Meterian, our daily scans using BOSS and Sentinel detected and flagged this vulnerability as of August 5, 2025. Teams relying on Meterian’s continuous monitoring and automated vulnerability assessment tools received instant alerts and recommendations to patch or isolate affected components.

Learn How to Protect Your Software Supply Chain

Want to explore how continuous vulnerability assessment can protect your platform?

Join our webinar on September 18, 2025:
🛡️ What’s Open Source Security Got to Do with Resilience of the Supply Chain?

📍 Learn practical steps to secure your software supply chain
📍 Get insights from industry experts on real-world open-source risks
📍 Explore tools for automated remediation and SBOM management

👉 Register Now

Final Thoughts

SQL injection may seem like an old-school threat, but vulnerabilities like this one in ADOdb show that even trusted, mature packages are not immune.

Don’t assume your code is safe just because it compiles.🔍 Start your vulnerability assessment today. Use tools that continuously scan and remediate open-source security risks—before attackers breach your systems.

Does Your Video Platform Have This Vulnerability? A Case for Proactive Vulnerability Assessment

August 1, 2025August 29, 2025 viviandufour1 Comment

In today’s digital-first economy, your brand story lives and breathes through video—from e-commerce product reels to customer testimonials and user-generated content. But what happens when the infrastructure behind that video platform becomes your weakest link?

A newly disclosed vulnerability in a popular open-source PHP platform is a clear reminder: routine vulnerability assessment is not optional. It’s the foundation for protecting both your customers and your brand’s digital identity.

PHP: The Web’s Silent Workhorse and a Key Target

According to BuiltWith, PHP powers over 74% of the internet’s websites, including leading e-commerce platforms like Magento, WooCommerce, and Prestashop. These platforms handle millions in transactions and user data. Their popularity makes them prime targets for open-source security threats, particularly when dependencies and third-party components are not continuously monitored.

A 2024 report from IBM shows the average cost of a data breach now exceeds $4.35 million. But the real damage goes beyond financial loss—customer trust and brand reputation take the biggest hit.

The Exploit: CVE-2025-48732 in AVideo

The latest threat in this category comes from the wwbn/AVideo platform, which serves thousands of streaming and video hosting applications built in PHP.

CVE-2025-48732 is a critical-severity vulnerability (CVSS pending) caused by an incomplete blacklist validation for .phar files.
The flaw allows attackers to bypass upload restrictions and execute arbitrary code on the server.
The root cause? Improper handling of PHP archive files, which aren’t adequately blocked or validated.

This is a classic example of supply chain exposure through unpatched third-party libraries. Without proactive open-source vulnerability scanning, affected organisations remain blind to threats lurking in their dependencies.

We regularly analyse open source projects to identify security risks. The image below shows a short summary of the open source software library WWBN/AVideo, which has been found to have critical vulnerabilities.

Why Continuous Vulnerability Assessment Matters

This isn’t just about one vulnerability. It’s a wake-up call for all businesses using open-source frameworks to:

✅ Implement automated vulnerability assessment tools that scan your software supply chain in real-time
✅ Track emerging CVEs across your entire application stack
✅ Flag unsafe libraries and automatically suggest fixes
✅ Maintain a software bill of materials (SBOM) to understand your exposure footprint
✅ Integrate patching into your CI/CD pipeline for faster remediation

If your video platform or customer-facing application relies on AVideo, or any PHP component, you need a continuous security strategy to detect and resolve vulnerabilities before attackers strike.

Secure Your Platform Before It’s Compromised

At Meterian, we help teams detect and remediate vulnerabilities across their software supply chain through real-time open-source monitoring, automated remediation, and SBOM-driven visibility.

Want to know if your app is exposed to CVE-2025-48732?

Get a full breakdown of the AVideo vulnerability, exploit risks, and how to patch it now.
👉 Download our Security Report

Don’t wait to become the next headline. Stay ahead with intelligent, AI-powered vulnerability assessment.

Ivanti’s RCE Nightmare Started with a Library You Might Be Using Too

July 23, 2025July 23, 2025 viviandufourcybersecurity, java, opensource, vulnerabilityLeave a comment

2–3 minutes

In May 2025, cybersecurity headlines were dominated by Ivanti Endpoint Manager Mobile (EPMM) facing active exploitation through chained remote code execution (RCE) vulnerabilities—CVE‑2025‑4427 and CVE‑2025‑4428.

These flaws enabled unauthenticated attackers to execute malicious code on affected systems, affecting enterprises globally. Ivanti’s vulnerabilities were notably tied to outdated open-source Java components, highlighting the critical importance of managing open-source security dependencies.

In this blog, we explore the Ivanti incidents, understand the role vulnerable Java libraries played, and demonstrate how proactive software composition analysis (SCA), continuous monitoring, and automated remediation through Meterian-X could have prevented or swiftly mitigated these attacks.

Ivanti’s Open Source Vulnerability: Java Libraries at Fault

The Ivanti vulnerabilities were rooted in the software’s reliance on outdated versions of Java libraries, specifically including “hibernate-validator.” These libraries were susceptible to chained exploits:

CVE‑2025‑4427: Allowed authentication bypass.
CVE‑2025‑4428: Enabled subsequent remote code execution (RCE).

These vulnerabilities underscore a significant risk: even trusted enterprise products can expose businesses if they incorporate insecure or outdated open-source components.

Understanding the Attack Surface

Ivanti’s attack scenario reveals common industry oversights:

Outdated dependency versions not promptly updated.
Inadequate visibility into the software bill of materials (SBOM).
Insufficient integration of security checks in the continuous integration and continuous delivery (CI/CD) pipeline.

Given the rise in nation-state actors targeting supply chains, companies must ensure software dependencies are continuously scrutinized.

Continuous Monitoring & Detection with Meterian Sentinel

Meterian Sentinel actively monitors dependencies, aggregating real-time vulnerability intelligence from authoritative sources, such as the National Vulnerability Database and GitHub Security Advisories.

Sentinel would have identified Ivanti’s outdated “hibernate-validator” dependency, alerting development and security teams of the urgent update required.

BOSS: Immediate Alerting & Automated Remediation

Meterian’s BOSS system provides:

Real-time notifications of critical vulnerabilities.
Actionable, prioritized remediation steps directly within development workflows.

In Ivanti’s case, BOSS would have immediately alerted to the risky dependency version, detailing the vulnerability and auto-generating a recommended fix within the CI/CD process.

Proactive Prevention: CI/CD Integration Workflow with Meterian-X

Integrating Meterian-X into CI/CD pipelines ensures software vulnerabilities are detected and addressed at the earliest stage, automatically:

Scanning: Meterian-X conducts real-time vulnerability scanning, flagging outdated dependencies like “hibernate-validator.”
Alerting: Via BOSS, teams receive instant alerts embedded within their existing development tools.
Remediation: Meterian-X auto-suggests safe library versions, ensuring secure deployment without manual intervention.
Verification: Automatically generates comprehensive SBOM reports (in CycloneDX format), streamlining compliance and software traceability.

This integration transforms vulnerability management from reactive firefighting into proactive security.

The Critical Role of SBOM

The Ivanti incident emphasizes why SBOMs are critical:

Manufacturers and enterprises gain transparent, real-time views into their software components.
Teams rapidly identify vulnerabilities within third-party dependencies.
Regulatory compliance becomes streamlined (e.g., SOC 2, EU CRA, EU DORA).

Meterian-X’s CycloneDX-based SBOM generation and ingestion is integral to maintaining visibility, security, and compliance.

Strengthening Your Software Supply Chain

Ivanti’s vulnerability illustrates a fundamental truth: security must extend beyond internal code to encompass all open-source dependencies. Meterian empowers security leaders, developers, and compliance teams to proactively detect and auto-remediate risks like those affecting Ivanti.

Adopting Meterian’s comprehensive security integration ensures continuous monitoring. It provides a rapid response and reliable protection of your software supply chain. This safeguards your business from the increasing threat of supply-chain-based cyber attacks.

URGENT AND CRITICAL: REMOTE CODE EXECUTION IN VARIOUS SPRING COMPONENTS NEEDS IMMEDIATE ATTENTION

March 31, 2022April 3, 2022 bbossolajava, opensource, vulnerabilityLeave a comment

Red alert! All enterprise software maintainers of software using Java libraries need to check if their systems are affected by the newly discovered vulnerabilities “Spring4Shell” since its announcement, between 29th and 30th March, 2022, affecting various Spring components.

CVE-2022-22 963

Vulnerability Score: 9.5 (CVSS: 3.0 / AV:N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H)
Platform: Java
Components: org.springframework.cloud:spring-cloud-function-core, org.springframework.cloud:spring-cloud-function-context
Affected versions: 3.1.6, 3.2.2 and older unsupported versions
Fixed in version: 3.1.7, 3.2.3

CVE-2022-22965

Vulnerability Score: 9.5 (CVSS:3.0 / AV: N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H)
Platform: Java
Components: org.springframework:spring-beans
Affected versions: all versions before 5.2.20, all versions before 5.3.18
Fixed in version: 5.2.20, 5.3.18

Please note that this affects also the spring-framework package and the spring-boot package, that both use the offending libraries. New versions of such packages have been made available. You can upgrade spring-framework to version 5.2.20 or 5.3.18, and you can upgrade spring-boot to version 2.5.12 or 2.6.6 (note that spring-boot itself includes spring-framework, no other upgrades necessary).

Which systems does these affect?

CVE-2022-22963 affects any project built using a vulnerable version of Spring Cloud, a framework that provides tools for developers to quickly build some of the common patterns in distributed systems. The “functions” part is a subsystem used to implement serverless functions like AWS lambda or Google Cloud Functions: if you are using such subsystem you are potentially affected.

CVE-2022-22965 affects any project built using a vulnerable version of Spring Framework, Spring Boot or the library spring-beans. A successful attack, however, can only be conducted undere these conditions:

JDK 9 or higher is used as the runtime environment
Apache Tomcat is used as the Servlet container
The application is packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
There is a dependency with spring-webmvc or spring-webflux, or an endpoint is used with DataBinder enabled

Please note however that analysis are undergoing and the nature of the vulnerability is quite general: we suggest you keep monitoring this page for further updates.

Why do these threats demand an urgent patch?

Both vulnerabilities allows the attacker to remotely execute code on your system, with the ability to gain complete control of the underlying servers. It’s a simple exploit, as it requires only to send a crafted HTTP header in a request in order to execute code on the remote host. These vulnerabilities are actively exploited in the wild.

How can I check if my system is affected?

If you maintain any software using Java libraries, check if you are using any Spring Cloud Function library. The Meterian BOSS scanner can be used to scan your codebase to identify all dependent software libraries. If it is using the offending package, it will find the affected vulnerable versions and provide more information on how to mitigate this risk.

If you are a developer and you have access to the code, you can simply execute this command from your terminal:

CVE-2022-22963:

$ mvn dependency:tree | grep spring-cloud-function | grep compile
[INFO] +- org.springframework.cloud:spring-cloud-function-core:jar:3.1.2:compile

If you see any response lines, check the version: if it’s below 3.1.7 (as in the above example) or, if using 3.2.x, below 3.2.3, you may be affected.

CVE-2022-22965:

$ mvn dependency:tree | grep spring-beans | grep compile
[INFO] +- org.springframework:spring-beans:jar:5.3.11:compile

If you see any response lines, check the version: if it’s below 5.3.18 (as in the above example) or, if using 5.2.x, below 5.2.20, you may be affected.

My system has the vulnerable spring cloud function library — how can I mitigate the risk?

There are now patched versions of the affected components that resolve the issues, they are available via the standard Maven repositories. Upgrade the offending packages using the patched versions, as described in this article.

If the library is coming from a transitive dependency (it’s not one of your direct dependencies, but a dependency of them) you can just include an override in your root pom.xml (or where applicable) and retest that it’s not there anymore with the command shown before.

CVE-2022-22963:

    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-function-core</artifactId>
        <version>3.1.7</version>
    </dependency>

Please be aware that there are multiple packages rooted in "spring-cloud-function": you will need to upgrade all of them, in particular "spring-cloud-function-context" which is also directly affected.

CVE-2022-22965:

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>5.3.18</version>
    </dependency>

Please be aware that you may need / may be better to upgrade the parent pom of the project using an unaffected version of spring boot / spring framework (see at the start of the article).

What can I do to proactively protect from such vulnerabilities?

We always suggest you regularly scan your software code bases.

To do a scan from the command line using the Meterian CLI scanner
To include this as part of your continuous improvement efforts to build resilience into your software development lifecycle, see our documentation on the various integrations we support with GitHub Actions, Azure DevOps Pipelines, and others.

Are Meterian applications affected by the spring vulnerability?

We have verified our applications and none are using the offending packages in a vulnerable configuration. We maintain a continuous monitoring system to ensure our development operations are up to date with the latest known vulnerabilities in software components. Given the nature of this vulnerability we will be running a specific monitoring for the following days, while more details are unfolded in regards to those vulnerabilities.

Related references

CVE-2022-22963

https://tanzu.vmware.com/security/cve-2022-22963 (official announcement)
https://github.com/dinosn/CVE-2022-22963 (sample exploit code)
https://github.com/darryk10/CVE-2022-22963 (sample POC)

CVE-2022-22965

https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement (announcement)
https://github.com/craig/SpringCore0day (sample POC and exploit code)

An introduction to the world of SBOMs

January 25, 2022January 24, 2023 viviandufourcybersecurity, risk, SBOM, software bill of materialsLeave a comment

3 minute read

We are sure many of you have been hearing about SBOMs. Nowadays, software include some components with code written by your own developers, but 80-90% of the code is typically from third-party developers. How can you know who produced what and when it absolutely needs to be replaced? Since Meterian has been managing SBOMs for awhile, we’re happy to share our know-how so you can consider a comprehensive strategy to manage your open source software supply chain.

What is an SBOM?

SBOM is an acronym that means Software Bill Of Materials. The concept originates from the manufacturing industry, where a bill of materials lists dependent components in machinery. A SBOM lists all third-party components present in your application. A good SBOM also lists the licences used by each component and, when possible, the specific copyright attribution. An excellent SBOM can also provide further information, such as possible relationships between those components to better understand any supply chain risk. You may have encountered SBOMs in the past, known as “third party notice” documents created to manage legal requirements, such as the one in the image below.

Altova Third Party Software License Notice

However, modern SBOMs are “machine-readable”. They follow a strict specification that can be understood by a computer.

What machine-readable formats are used to publish SBOMs?

The most commonly used formats to define a SBOM are:

CycloneDX, a lightweight open-source standard designed for use in application security context and supply chain component analysis. This originated from within the OWASP community.
SPDX, an open source format with origins in the Linux Foundation, slightly more complex, and recently approved as ISO/IEC standard in version 2.2.1 as ISO IEC 5962:2021.
SWID, another ISO/IEC industry standard used by various commercial software publishers.

All these formats support a variety of use cases, but the first two (CycloneDX and SPDX) are the most versatile. Due to SPDX’s complexity, we think CycloneDX has an edge at this time, but only time can tell which of these formats will be the winner. To learn more about these formats you can also read the official NTIA publication, which drills down into the matter.

Why are SBOMs important? And how are they useful?

As a consumer of software, the main reason why you want to have access to the SBOMs of the systems you are using is to manage risks. When a very commonly used software component becomes vulnerable: how do you know what you need to patch and which subsystems are at risk? This is exactly what happened with the recent Log4Shell debacle. The logging library called Log4j, was suddenly exploitable with a very simple and repeatable attack. How do you know where it is? Which one of the systems you are using is suddenly at risk? With a correctly managed archive of SBOMs, getting this information reduces to a very simple lookup task. Without it, it can be a real nuisance —a time consuming information hunt that disrupts everyone’s work flow.

As a producer of software, instead, you want to preserve and maintain an archive of all the SBOMs of the system you produce so that you can create and distribute timely patches to your customers. Having a systematic and comprehensive analysis of your most commonly used software packages would be useful indeed. Some companies were very fast in releasing patches to their customers, while others were extremely slow, mostly because they did not have the information. You probably want to be in the first group of companies 🙂

Governments are also mandating the need for use of SBOMs, realising that software security needs to be regulated. The U.S. Executive Order 14028 that mandates all federal agencies to require SBOMs from their suppliers. This not only impacts the companies that have direct sales to the US government but also their own software suppliers. As so many systems and devices have been connecting to the Internet to send and receive information, consequently our digital world relies on a software supply chain. This “ripple effect” will be significant for many industries.

It’s important to consider how software products you produce can meet basic security requirements and how the associated software security information is produced and managed in your organisation. Similar legislation has already been proposed in Europe since the publication of “Guidelines for securing the IoT” by ENISA (hint: SBOMs are required) and the ETSI EN 303 645 global standard for consumer IoT security, which is based on the UK government’s Code of Practice. See also the recently published Product Security and Telecommunications Infrastructure (PSTI) Bill and more to come from the UK government to improve the UK’s cyber resilience.

How should SBOMs be handled?

Very carefully :), because an SBOM contains the full list of the “ingredients” of your system or application. While open-source projects happily share this information to the world, the same does not apply to private companies. In fact, a malicious actor that gets hold of the SBOM of your system can then check if you are using any vulnerable components. There are public vulnerability databases, such as the NVD, which are very popular. Someone can simply browse in there and compose a list of possible attacks, try them, and maybe get lucky. Probably 9 out of 10 vulnerabilities affecting components in your system won’t be exploitable, but having the ability to go through the whole list, certainly makes the task of finding an exploit much easier.

There’s no need to keep SBOMs a complete secret, however, as long as a few simple principles are kept in check:

SBOMs need to be shared securely,
they need to be accessed only by the authorised parties, across organisational boundaries, and
they should not be tampered with.

In summary, it is essential to produce a precise SBOM, and it is just as vital to share it and maintain it securely with the correct (trusted) third parties.

Why bother with SBOMs now?

In summary, it is essential to produce a precise SBOM, and it is just as vital to share it and maintain it securely with the correct (trusted) third parties. In our hyper connected world, comprehensive coverage of components is important for preventative strategies and threat detection in supply chain attacks. Therefore, implementing SBOM management proactively now will be worth something to your organisation when the next critical vulnerability appears and stand your organisation in good stead. All good collections are worth organising. How valuable is your collection of software?

Get started with SBOMs

The need for SBOMs is already high. Level up your open source software security and implement this requirement. Check out the SBOM capabilities in Meterian-X platform’s approach to DevSecOps.