Display SA coverage icon based on a release/branch of the module going to be installed

Things that make this hard:

(1) the security coverage IS itself a project-level flag on Drupal.org - whether or not that project is opted in. The fact that you are getting an uncovered 3x is more about the governance rules of what gets actual reviews (green releases only)

(2) whether or not. you get the "green" or "yellow" can actually depend on your composer config - whether you allow beta releases, for example.

I'm not sure if we can just educate users around this or if there's something more drastic that might need to happen. I'm not really convinced it's a true security issue, it feels like a UX issue.

Agree, which version of the module you get will be based on the composer.json configuration. Right now the opt-in is a project-wide setting, so I'm not sure we can do something about this. Perhaps Package Manager can detect the composer.json configuration that would allow for non-stable packages and throw a warning in the page?

From the security point of view, there is a policy, that anything non-stable is not covered. If project browser know what is going to be installed (which I suppose it should know), then I think this can be solved.

Other than that, I think that because of the fact that Drupal CMS includes also alpha versions, the composer.json "minimum-stability": "alpha" is hardcoded, so no, sites may not be aware what will happen, which is not good. For sites using project browser outside of Drupal CMS, it could be/is different.

Or am I missing something?

From the Slack discussion:

The projects on d.o. have this text: "Stable releases for this project are covered..."
The projects in PB have this text: "Module is covered..."

So one possible way how to at least lower the impact here is to change the text to match the Drupal Security Team policy.

IMO this is a critical bug, so adjusting priority.

Opened 🐛 Alpha stability flag in composer.json allows project_browser to download any alpha stabiility module Active based on @poker10's points in #6.

None of this should be hard-coded into the client. While there are no changes to the security advisory policy coming up, change is inevitable long-term.

https://packages.drupal.org/files/packages/8/p2/drupal/token.json has the data and text for each version: "security-coverage":{"status":"covered","message":"Covered by Drupal\u0027s security advisory policy"}

Agreed with #10 that the policy could change so it would be better to hardcode it. However I also think doing a quick fix to match the current policy might be worth doing anyway, because the final fix seems non-trivial to me.