Why I’m Building an Extension Security Record

An extension approval goes stale as soon as the code changes. A team may have reviewed the first install carefully and still have no record of what arrived in yesterday's update.

I’m building RiskyPlugins to make that record easier to inspect. The useful questions are specific: which version did we scan, what changed, and which files support the finding?

Review the installed artifact

A store listing explains what a publisher wants users to know. The downloaded package shows what will run. Those can diverge after an account compromise or an ownership transfer, even while the extension keeps its name and reviews.

Browser and editor extensions also have different access. A browser extension operates within its granted permissions. An editor plugin can run processes with the developer's access. A review needs to account for the host application instead of treating every permission as equivalent.

RiskyPlugins collects marketplace metadata and extension artifacts, then scans the contents. The findings cover exposed secrets and malware patterns, along with signals such as obfuscation or risky dependencies. Version history helps explain when a finding appeared.

The Nx Console investigation shows why the changed files matter. Its loader was small enough to disappear among thousands of legitimate operations in a bundled JavaScript file. The Dark Mode Google Docs investigation shows another case: a new advertising component after an ownership change, with a narrower observed effect than credential theft.

A score needs an explanation

A network request can be necessary for an extension's advertised feature. A secret detector can match an example token. Automated review has to retain that uncertainty.

The score is a way to prioritise investigation. I want the reader to be able to follow it back to the code and decide whether the evidence supports the assessment. The scoring methodology describes the model. A low score cannot prove safety, especially when analysis is missing or the installed version differs from the scanned one.

The website gives people a way to search those records. The API and hosted MCP service make the same information available inside automated workflows.

Where enforcement belongs

An organisation still needs to decide what it permits. A finding may justify blocking an extension, holding an update for review, or asking the publisher for an explanation. Each choice needs an owner and a record of the evidence used.

That is the purpose of the separate PrivateStores work: apply an organisation's decisions to the software it distributes. I describe that division in the two-product plan. The proposed controls should be judged against what has shipped; a roadmap is not an enforcement guarantee.

MCP servers and agent skills make this work more urgent for me. They can put third-party instructions or code close to files and credentials used by an assistant. I want the review to follow the actual access being granted, including remote services whose behaviour cannot be established from a local package scan.

The result I want is straightforward: when someone asks why an extension was approved, the answer should include the version and evidence they reviewed.