Changelog

Until now, MDL Shield reviewed code after the fact: a release on the Marketplace, or a branch you pointed us at. Pull request reviews move the review to the moment the code is actually decided. Install the MDL Shield GitHub App on a repository and every pull request gets a security review before it merges, with the results posted straight to the PR and to your dashboard.

The reviewer is the same one behind every MDL Shield review: an AI Moodle security specialist that reads your change the way a human reviewer would, understanding what the code does and how it fits into Moodle, not just pattern-matching lines. It is not a linter and it does not replace moodle-plugin-ci.

On the pull request

Three things land on the PR:

• A check called MDL Shield review that passes or fails according to the severity you choose to block on.
• One summary comment that always shows the current state: every finding, its severity, and its status.
• An inline comment on the exact line for each finding, with the description up front and the depth (context, risk assessment, suggested fix) folded away until you want it.

Findings in pre-existing code that your change interacts with are reported too. On public repositories those never appear on the PR, only in your dashboard, so a review can't hand a bystander a map of unfixed code.

Findings follow the code

Every push is reviewed, and findings are never re-reported push after push: a finding stays open until a commit actually fixes it, and when one does, the review resolves it and names the commit. If a later commit turns a latent risk into a real one, the finding escalates, with the evidence.

Triage from the PR

Every finding's inline thread takes commands from the repository owner and the users you trust. Reply on the finding to triage it, with a reason if you have one:

!mdlshield accept Only course managers can reach the export page

dismiss, accept, confirm and resolve are the verbs. The bot acknowledges with a thumbs up, appends the decision to the finding (who, and why), and the check recomputes. !mdlshield review on the PR forces a re-review, and so does the Re-run button on the check.

Settings in the repository, or on the site

A .mdlshield/config.yml on your default branch controls which pull requests are reviewed and how: branch, label, author and path filters, the severity that fails the check, what the check does when a review errors, who may issue commands, and the Moodle version to review against.

fail_on:
  severity: high        # the check fails on high and critical
on-error: open          # an errored review never blocks a merge

moodle:
  versions: ["5.0"]

trusted_users: ["alexc"]

include:
  branches: ["main", "MOODLE_*_STABLE"]
exclude:
  paths: ["lang/**", "vendor/**"]
  authors: ["dependabot[bot]"]

The same settings exist on the site, as account defaults and per-repository settings, so you don't need a file at all. When there is one, it wins, key by key. You can also give the reviewer private context about your plugin (what it is for, who can reach it, known trust boundaries) that guides every review and is never committed to your repository.

Your dashboard

The new Pull Requests tab lists every PR across your repositories with its open findings and check state at a glance.

Every pull request gets a page in your dashboard with the full history of review passes, every finding in full depth, and triage buttons that twin the commands. This is the only place a finding's proof of concept ever appears: it is never posted to GitHub. You can also authorise other people to view and triage without giving them settings or billing.

Moodle has launched the Moodle Marketplace, the new home for every plugin that used to live in the moodle.org plugins directory. It's a big step for the ecosystem: one place to find, buy, and install plugins, with proper support for commercial vendors for the first time.

We think that's worth celebrating. A healthier plugin economy means more plugins, more maintainers who can afford to keep maintaining, and more code running inside your Moodle sites. Which is exactly why we exist: a marketplace tells you what a plugin does. An independent security review tells you what its code actually does. MDL Shield tracks every plugin on the Marketplace, reviews the code line by line, and puts the result on a public grade badge, so "is it safe?" has an answer that doesn't depend on taking anyone's word for it.

Here's what the transition changes for you.

Free community reviews: unchanged

Non-commercial plugins listed on the Marketplace keep their free monthly reviews. Verify you're the maintainer, run reviews, publish them, embed the badge. Nothing about that flow changes.

Paid plugins: release reviews make way for Repository reviews

The Marketplace doesn't let us download paid plugins' released packages, so release reviews of paid plugins are no longer possible. We detect this automatically and tell you up front instead of failing halfway.

If you maintain a paid plugin, your path is a Repository review: connect your Git repository (public or private, read-only deploy key) and we review the code directly. In many ways it's the stronger option, since you can review before you release, not after.

New: paid plugins can publish Repository reviews

Until now, publisher publication was reserved for plugins outside the directory. That rule made no sense once paid Marketplace plugins lost their release-review path, so we've changed it: if the Marketplace won't give us your released package, you can become a verified publisher and take your Repository reviews public, grade badge included. The published page states plainly that the review covers your source repository rather than the Marketplace package, so buyers know exactly what was reviewed.

You choose the disclosure level per review, which matters when your plugin is closed source:

• Full report: the complete review, findings and all.
• Grade summary: just the grade and a plain verdict. No findings, no code snippets, and for private repositories no repository location, branch, or commit either. Your code and your repo stay yours; only the grade goes public.

The small print

• Your plugin page now shows whether the Marketplace lets us download your releases, with a one-click re-check if you think we've got it wrong.
• Every link, page, and email now says Moodle Marketplace, and plugin links point at your plugin's Marketplace page. The directory served the community well for a long time; its name is retired with honours.

If you run into anything the migration broke that we haven't caught, tell us and we'll chase it.

Repository reviews have always been private to you, and by default they still are. But if your plugin lives outside the moodle.org directory (internal, closed source, or simply unlisted), there was no way to show anyone what your review found. Now there is: become a verified publisher and publish those reviews on a public page, under a publisher name you choose, whether that is you, your team, or your company.

Verified identity, per-plugin approval

Publication is a trust feature, so it is gated twice. First we verify who you are: request publication from any repository review, we check your details by hand, and you receive a public publisher handle. Then each repository and plugin combination needs a one-time publication approval; once granted, you can publish any review of that plugin, current and future, without asking again. Both gates exist to protect plugin authors: nobody can stand up public reviews of code they don't control, and everything that goes public is backed by an identity we have verified.

Full report, or just the grade

Every publication picks a disclosure level. Full report publishes the whole review, findings and fix guidance included, just like a community review. Summary publishes only the grade and whether any security issues were found, and nothing else: all findings stay private to you. That is the option for closed-source plugins that want credible proof of a security review without exposing any internals.

For public repositories, a summary still pins down exactly which code the review covered: branch or tag, commit, the commit's date, and the scope in files and lines, so a grade can never quietly refer to different code. Private repositories disclose even less: the reviewed-code details are left off the summary entirely, revealing nothing about your repository, branches, or commits.

A page and a badge for every plugin

Every verified publisher gets a public page listing their published plugins, and every published plugin gets its own page with the full history of published reviews. The security badge always shows the grade of your latest published review, ready to embed in your README, your website, or your sales page.

Publishing stays a deliberate act: nothing goes public without you clicking Publish, each new review is published on its own, and you can unpublish at any time.

One more nicety shipping alongside: repository and pre-release reviews now show your plugin's real display name, read from its language strings at review time, instead of only the frankenstyle.

Every completed review in your dashboard now has an Export menu. Copy the full report as clean Markdown or download it as a .md file, ready for your issue tracker, wiki, or release notes.

Each finding card carries the same menu scoped to just that finding, so every action below works for a single issue too, handy for lifting one finding into a ticket or a chat.

For AI help there are two routes. Copy AI prompt wraps the report in instructions to work through each issue, ready to paste into any AI assistant you like. And if you use Claude or Cursor, Open in skips the paste entirely and hands the report over in one click (those two can fetch it directly by link).

A batch of improvements for anyone buying reviews on a company card:

• Your saved business details (company name and tax ID) now show on the purchase page, with a link to update them. Once entered, the checkout itself never displays these again, so the purchase page is now the place to confirm they're right before you buy.
• Want your billing address on the invoice? Tick Add my billing address to the invoice and the checkout will prompt for it. We remember whether you want that prompt; the address itself can't be pre-filled by the checkout yet, so it does need re-entering each time.
• Purchase history now offers a proper invoice PDF download alongside the receipt.

You can now connect your plugin's Git repository and run reviews directly against it, no moodle.org release required. That unlocks two different things, depending on where your plugin lives:

Pre-release reviews

For plugins listed on the moodle.org plugins directory. Point us at a branch or tag and review the code before you publish the release, so what lands in the directory has already been audited. Free reviews apply to non-commercial community plugins, same as always.

Repository reviews

For plugins that are not in the directory: unlisted, internal, or closed source. Connect the repository and review any branch or tag on demand. These use a paid review credit.

Both work with private repositories (via read-only deploy keys) and monorepos (point the connection at the directory that holds your plugin), and every repository card shows its latest review grade at a glance.

Review results from repositories stay private to you.

Just uploaded a new version to moodle.org? Hit Refresh releases on your plugin's page in the dashboard and we pull its latest versions immediately, no waiting for the background sync. Freshly pulled versions are marked with a NEW badge so they are easy to spot.

Reviewing a commercial plugin? You can now buy review credits directly on the site.

• Secure embedded checkout with cards, Apple Pay, and Google Pay
• VAT handled automatically at checkout
• Credits work across all your plugins

Non-commercial plugins listed in the Moodle plugins directory keep their free monthly reviews.

MDL Shield now has a public changelog. New features, improvements, and fixes are announced as they ship. Bookmark the changelog or subscribe to the RSS feed.