Okay, so what is the process to gain access? We have the controller
being analyzed and the number of utterly false positives is not funny
and I have no way to close them down.

To gain access, you'll need to log into Sonarcloud.io using a Github account. If your Github account is already a member of the github.com/opendaylight org, you'll immediately have access to the Sonarcloud org. If not, you can open an issue at support.linuxfoundation.org, providing your Github username for us to provide access. 

Two examples:

https://sonarcloud.io/project/issues?id=opendaylight_controller-sonarcloud&issues=AW6UsvtubRr7khNgdg70&open=AW6UsvtubRr7khNgdg70
is so utterly and completely wrong it's hard to describe -- target
object type is a simple enum, having no state, hence it all the points
about safe publication are utter BS in this context.

https://sonarcloud.io/project/issues?id=opendaylight_controller-sonarcloud&issues=AW6Usvo9bRr7khNgdg5r&open=AW6Usvo9bRr7khNgdg5r
is also utterly wrong -- there is even a
@SuppressFBWarnings(VO_VOLATILE_REFERENCE_TO_ARRAY) to mark that yes, we
really know what we are doing (it is a cache of the serialized form, and
no, we do not really care about double-checked loading).

Furthermore, what is the process to evolve the rule sets?

We can make changes to the Quality Profiles to meet the needs of the projects, if there are rules that should never be applied. Otherwise, like SonarQube, individual issues can be marked as false positives, and/or have their priority lowered.