Background:
This is logged on the back of the discussion with the ZAP team about the current behaviour of XML External Entity Attack scanner. There were two concerns raised in this discussion. I am creating seperate tickets for them as they can be addressed independent of each other. F

What's the issue?
Overwritten test scenario, can be summarized and link to payload lists from other repos

How do we solve it?
Chop down the content to the required and needed information, link to payload lists instead of enumerating all possible usernames and passwords, provide further guidance on how to test.

If no one is up to handle it, I can take care of it

Authentication via Azure/aad-pod-identity for keyvault access could be a good feature to avoid use of clientId/ clientSecret in chart values. Don't you think ?

The current swagger definition is autogenerated. The automatically generated definitions rely on reflection and annotations to create the documentation. The reflection capabilities are poor at best and lead to missing API parameters. Annotations can help in some cases, but the only fix for Swagger is to create individual POJOs for every possible request. This will lead to unnecessary large number

https://github.com/OWASP/www-community/blob/master/pages/CRV2_AppThreatModeling.md

Contains a bunch of HTML based tables that need attention. They did not auto-migrate well and at a certain point break the rendering of the majority of the page.

If HTTP sites (is not HTTPS ones) use the Access-Control-Allow-Origin header then the site will typically not work.
ZAP should automatically fix this header.
https://stackoverflow.com/questions/61940616/how-do-i-work-with-http-sites-using-the-hud-in-owasps-zap-proxy

It will be a fun exercise to make scan work for mono repos such as https://github.com/swapnil-linux/spring-boot-examples

In theory, this can be achieved using a bit of bash with the new scan AppImage.