A marketplace security reporting page should say where to report, what to include, how fast you will respond, what happens after a report, and how reporters are protected. Put the link on every listing, not only in a footer. One public benchmark: the VS Code Marketplace documents an initial response within one business day.
Put the entry point on the listing
The VS Code documentation places its "Report a concern" link at the bottom of an extension's More Info section. The idea is sound: the reporter is looking at the listing when they notice a problem. Use the same pattern, and make the link visible without scrolling through unrelated text. A separate page for vulnerability reports about the marketplace itself should also exist.
The checklist
| Element | What to write |
|---|---|
| Where to report | Listing level link plus a general security contact |
| What counts | Malware, credential theft, impersonation, undeclared data transfer, vulnerabilities in a listing |
| What to include | Listing ID, version, observed behaviour, date and time, evidence |
| Response target | A stated first response time, such as one business day |
| What happens next | Triage, verification, then removal or block, then notice |
| Users already installed | Whether installed copies are blocked or uninstalled |
| Developer contact | When the publisher is told and how they can respond |
| Reporter protection | Statement that good faith reports will not be penalised |
| Updates | Whether the reporter hears the outcome |
Say what the process does to installed copies
The most useful sentence on the page is about installed copies. VS Code's documentation says a verified malicious extension is removed and blocklisted, and VS Code automatically uninstalls it where installed. Chrome describes users being unable to re-enable extensions removed for malware. If your platform can reach installed copies, say so, and say how long it takes.
Set expectations honestly
Promise what you can keep. An initial response is not the same as a removal. Spell out the stages: acknowledgement, investigation, decision. If you cannot disclose details of a decision, say that too, as Chrome's review documentation does for malware removals.
Keep the process internal too
A public page is only as good as the process behind it.
- A named owner for the queue, with cover for holidays.
- A severity rubric, so impersonation and credential theft are handled first.
- A way to freeze a listing while you investigate.
- A record of each decision with evidence, for later appeals.
- A route to notify other users who installed the same version.
- A review after each incident: how did it pass review, and what check would have caught it?
Test it
Once a quarter, file a harmless test report through the public route and time the response. A reporting page nobody monitors is worse than none, because reporters assume something is happening.
Where this connects to your own supply chain
If you consume other marketplaces, look for these elements before relying on them. If a store has no stated route or timing, your own inventory and block list matter more. Safeguard's asset discovery and policy gates help the consuming side, and its compliance and evidence automation keeps the record of what was approved.
Quick check
Where should the report link go?
On each listing, near the details a user is reading, plus a general security contact page.
Should the page promise removal times?
Promise a first response time. Removal depends on verification, so describe the stages instead.
Do reporters need protection?
A short good faith statement encourages reports and costs nothing.
Sources
Last reviewed: 19 October 2026.
