Connect with us

Business & Technology

Chainguard launches scanner to block npm malware greyware

Published

on


Chainguard has launched a source code scanner that blocks open source packages it classifies as malware and “greyware”. It says the tool is already screening more than 100,000 packages a day.

The scanner is available for npm packages requested through Chainguard Libraries for JavaScript and has already blocked more than 52,000 packages identified as malware or greyware.

Chainguard uses the term greyware for open source packages that disclose their intended behaviour but still pose security risks many organisations would reject in a formal review. These can include tools for credential harvesting, command interception, persistent remote access and account fraud automation.

The launch reflects broader concern in software security over the growth of risky dependencies in public registries. Security teams have long focused on malware hidden inside code packages, but Chainguard argues that another category is slipping through because the software openly states what it does and can avoid conventional malware detection.

In its current setup, the scanner reviews packages before they are added to the Chainguard Libraries catalogue rather than waiting until a customer requests them. It examines maintainer behaviour, package contents, publishing signals and the behaviour of installation scripts in a sandboxed environment.

That includes unusual account activity, changes in release history, obfuscated code, suspicious domains, differences between source code and published packages, and scripts that try to contact external servers or access local files. Packages are then marked as malicious, escalated for review by a security engineer, or cleared for use.

Chainguard says the volume of software being generated and adopted through AI-assisted development is making manual dependency checks less realistic. It argues that developers often rely on indicators such as download numbers, repository activity or autocomplete suggestions rather than reading package documentation or reviewing source code in detail.

The company also pointed to a wider industry backdrop in which supply chain attacks remain a significant issue, citing figures showing that 65% of organisations said they experienced a supply chain attack in the past year.

Examples found

Among the examples identified on npm was leobot-cli, which Chainguard described as an account fraud automation tool. The package advertises itself as a command-line bot for registering Canva and Leonardo accounts and includes a command to generate fake accounts and inject a Chrome extension for session injection and token monitoring.

Another package, @robinpath/cloud-cli, was described as software that creates a permanent backdoor from a machine to a third-party server and waits for commands to run. It is presented as a command-line tool for an AI assistant that reads code, creates files, executes commands and builds scripts.

Chainguard also highlighted noesis-miner, which it said reads Solana keypairs from disk and runs persistent mining loops. The package is presented as an AI-agent-mined token protocol for Solana.

It identified drogonclaw as a hacking toolkit that includes open source intelligence functions, network scanning, exploit execution and remote mobile control. The package advertises itself as an autonomous AI pentest framework.

A fifth example, chrome-tool, was described as a Chrome credential-harvesting extension. According to Chainguard, the package exports modules designed to extract passwords, cookies, credit card information and autofill data.

Several of these packages remain available for download on npm and have each recorded thousands of downloads, Chainguard said. Some had also passed what it described as a typical seven-day cooldown period, a delay often used by software security products before treating a package as established.

Scanner design

The scanner sits inside Chainguard Repository and is intended to add another layer of review on top of existing checks such as building from source and cooldown periods. The aim is to reduce the risk of malicious or risky software being cached inside internal systems before it is flagged.

Ross Gordon, Staff Product Marketing Manager, and Evan Gibler, Staff Security Engineer at Chainguard, described the rationale for the product in a joint comment: “Malware has become a serious industry problem: 65% of organizations said they experienced a supply chain attack last year, let alone in 2026. However, there hasn’t been much emphasis on packages that do exactly what their README says, pass malware scans, but act in ways no CISO would ever approve. We call those packages greyware.”

Protection is currently in place for npm packages requested through Chainguard’s JavaScript library service, with additional language ecosystems due to be added later. Chainguard says the scanner is already protecting all packages served through its upstream fallback to npm and has blocked more than 52,000 malware and greyware packages.



Source link

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Business & Technology

Company not liable for death of worker during Storm Eunice

Published

on


Jack Bristow, 23, from Sutton Courtenay, died after a tree fell on his truck while he was working in Hampshire.

He suffered a catastrophic head injury and was pronounced dead at the scene. He left behind his son, Harvey, who was one at the time.

Mr Bristow and driver Callum Smith had left Hooke Highways Limited’s Watlington depot at about 7.55am to remove traffic management equipment across the South East that could have been blown away in severe winds.

Jack Bristow , 23, died working in Storm Eunice in 2022 (Image: Unknown)

They were travelling back to Oxfordshire on Old Odiham Road when the accident happened at about 11.43am.

His parents, Teresa White and Gary Bristow, brought a claim against the company, arguing it had breached its duty of care by sending him to work during a Met Office Red Warning for extremely strong winds.

However, Judge Irena Sabic KC dismissed the claim, saying the risk of death while travelling as part of the assignment “was not reasonably foreseeable”.

She warned against “setting a novel standard of care” by which negligence could be established against an employer.

In her judgment, she said: “My view is that the precautions that the Claimants say should reasonably have been taken are not practicable or realistic. The risk of this horrific accident occurring was simply not foreseeable.”

Expressing sympathy for Mr Bristow’s relatives, the judge said he had been described as “hard working, caring, witty and completely devoted to his son”.

The family’s separate claim against landowner Davis Meisels, from whose land the tree fell, will be determined in due course.





Source link

Continue Reading

Business & Technology

The NHS Copilot rollout exposes the governance gap behind enterprise AI ambition

Published

on


AI adoption continues to accelerate across both public and private organisations. In healthcare, three-quarters of surveyed public-sector organisations are already exploring or implementing generative AI initiatives.

One of the most significant tests of AI at scale is now approaching, with NHS England announcing plans to provide Microsoft 365 Copilot to roughly half a million clinicians and support staff. This isn’t happening in a vacuum. More than a quarter of surveyed GPs are already using AI tools in their clinical practice, making broader adoption a logical next step. The goal across healthcare is to reduce administrative burdens, improve efficiency, and give staff more time to focus on patient care.

The real test is no longer whether organisations can deploy AI. It is whether their governance can keep pace once they do.

The readiness gap

The more difficult question, however, is whether the surrounding environment is ready. Sixty-eight per cent of surveyed physicians said the NHS lacks the digital infrastructure needed to introduce AI effectively. The concerns are not limited to the technology itself. Training gaps, interoperability issues, patient safety and data privacy are all important parts of the readiness picture.

At the scale at which public-sector organisations operate, AI adoption requires governance that can keep pace with both the technology and the environment around it. This must include clear policies for data access, retention, accountability and human oversight.

That gap is not unique to healthcare. Private-sector organisations face many of the same readiness questions, even when the regulatory context, systems and consequences differ. 

Why existing governance models need to evolve

Many governance practices still rely on periodic reviews, where changes to systems and data access are assessed at defined intervals. That made it easier to track risk, document decisions and respond as regulation evolved. Human decision-makers were also more visibly positioned at the centre of many workflows, making informed judgment calls. 

AI changes those operating conditions. AI systems can retrieve, combine and summarise information at a scale that makes interaction-by-interaction human review impractical. At the same time, many organisations are adopting multiple tools across operational and governance functions. Similar information may be accessed through several systems, making it harder to maintain consistent visibility into what was used, by which tool and for what purpose.

The nature of the modern workforce compounds the challenge. Today, staff join, leave and move between teams, while organisations are regularly reshaped through restructuring, mergers and acquisitions. The problem of access no longer matching someone’s role or legitimate business need is not new.  Introduce AI into that environment, and existing data sprawl and oversharing become easier to discover and more consequential.

The recurring mistakes

A few patterns repeatedly undermine otherwise well-intentioned governance efforts. Organisations often lack a clear inventory of what sensitive data exists, where it lives, who owns it and who can access it. In large, long-established organisations, where information may have accumulated across decades of systems and restructures, this picture is rarely as tidy as teams assume.  Deploying AI into an environment that has not been properly assessed can amplify operational and reputational risk. 

Governance is also frequently treated as a pre-launch checklist rather than a continuous operational function.  Teams may invest heavily in preparation, but real-world use can surface behaviours, use cases and risks that pre-launch testing could not fully anticipate.

Many organisations are also layering multiple specialised tools that do not communicate effectively with one another. An organisation might use one platform for administrative automation, another for back-office processes and a third for access governance. Each tool may perform its individual function adequately, but together they can create fragmented oversight, duplicated effort and additional sprawl that is difficult to contain. 

The confidence-reality gap

There is a striking gap between how ready organisations believe they are and what their operating environments are revealing. ShareGate’s 2026 Microsoft 365 AI Readiness Survey of IT and security leaders found that 93% of surveyed IT and security leaders were confident their Microsoft 365 governance framework could support AI responsibly. Yet 29% reported that AI tools had already surfaced sensitive internal information that they believed should not have been accessible. A further 8% were unsure whether this had occurred.

The types of data being surfaced are not abstract.  They include contracts, employee records, strategic plans and customer lists. In a healthcare setting, that could mean an employee receiving an answer grounded in sensitive information they were technically permitted to access but no longer had a legitimate reason to see. 

With Microsoft 365 Copilot, one common issue is not a broken security boundary but an existing permission model that no longer reflects legitimate business need. The real issue is that those permissions are often broader, older, or less deliberate than leadership assumes. Permissions designed for human search and manual discovery were not created with prompt-based retrieval in mind. Information that once required someone to know where to look can now be surfaced through a single prompt.

When governance tools are fragmented and oversight is inconsistent, oversharing becomes a recurring pattern rather than an isolated incident. Remediation becomes slow and costly. The distinction that matters here lies in whether governance is reactive or proactive.  Organisations that establish and continuously review the right controls before and after deployment can reduce the likelihood and impact of data exposure, while avoiding the cost of remediating problems after trust has already been affected.

Getting the foundations right

The NHS Copilot rollout will be a major test for workplace AI at scale in the UK. Its success will depend as much on the governance surrounding it as on the technology itself.

That means organisations need to move beyond surface-level readiness checks. Effective governance starts with a thorough understanding of the existing environment: what data exists, where it lives, who owns it, and who can access it.  It requires collaboration across IT, security, legal, compliance, data and operational teams, with clear accountability for the decisions each group owns. It also requires scrutiny of the broader toolset: whether platforms work together, support consistent oversight and reduce more complexity than they introduce.   

Good governance isn’t a brake on AI adoption; it’s what makes fast adoption sustainable. By identifying risk earlier rather than responding after an incident, organisations give AI deployments a better chance to deliver. Teams can focus on efficiency, service improvement and better employee experiences rather than spending their time correcting governance problems that AI has made easier to see.

The goal is not more governance for its own sake. It is the confidence to use AI responsibly at scale.



Source link

Continue Reading

Business & Technology

HMRC Advisory Fuel Rates to change from September 2026

Published

on



HMRC is due to publish its latest Advisory Fuel Rates from September, with the quarterly review potentially changing how much employers reimburse staff for business travel in company cars.

The rates are also used to calculate how much employees should repay if they use company-paid fuel for private journeys.

While the changes are usually linked to fluctuations in fuel prices, experts warn that using outdated rates could lead to incorrect mileage claims and, in some cases, unexpected tax consequences.

What are HMRC’s Advisory Fuel Rates?

HMRC reviews the rates every three months to reflect average fuel costs for company cars.

They are designed to help employers reimburse staff for business journeys without creating additional tax liabilities and to calculate repayments where company fuel has been used for personal travel.

Joe Lytwyn, personal finance expert at thimbl.com, said: “HMRC’s Advisory Fuel Rates are designed to reflect the average fuel cost of running a company car for business journeys.”

He added: “They’re reviewed every three months because fuel prices don’t stand still, so it’s important that businesses keep up with the latest figures.”

One mistake many drivers make

Lytwyn said many employees wrongly believe the rates apply to everyone who drives for work.

He explained: “One of the biggest misconceptions is that the rates apply to everyone who drives for work. They don’t.”

Instead, the Advisory Fuel Rates only apply to company cars.

Employees using their own vehicles for work are covered by separate HMRC mileage rules.

Could you end up paying more tax?

Using the wrong reimbursement rate can have tax implications for both employers and employees.

Lytwyn said: “If an employer reimburses above HMRC’s Advisory Fuel Rate without being able to justify the higher cost, the excess could become taxable.”

He added that employees who receive less than the advisory rate “may be able to claim tax relief on the difference in some circumstances.”

Keep good mileage records

Experts also say poor record-keeping is one of the biggest reasons mileage claims go wrong.

Lytwyn said: “Poor record-keeping is probably the most common issue. People often forget to log journeys properly, or they mix business and personal mileage together.”

Keeping a record of where you travelled, why the journey was for business and the miles covered can help avoid problems if HMRC or your employer ever questions a claim.


Recommended reading:


What drivers should do before September

With fresh Advisory Fuel Rates expected from September, drivers are being encouraged to check that any future claims use the updated figures.

Lytwyn said: “Don’t assume the current rates will remain the same.”

He added: “Once HMRC publishes the updated figures, check whether your employer has updated its mileage policy and make sure any new claims use the correct rates.”

He also recommended keeping mileage records up to date throughout the year, making it easier to challenge incorrect reimbursements or claim any tax relief that may be due.

It’s worth noting that the September rates have not yet been published, so drivers should continue using the current HMRC Advisory Fuel Rates until the updated figures are officially released.





Source link

Continue Reading

Trending