The confused deputy is when you are operating on behalf of another program, but you do not appropriately check permissions. The normal example of this is a grocery store cashier, scanning items using a barcode. If a malicious customer changes the barcode, for instance putting a carrot barcode on filet mignon, and the cashier simply scans and charges carrot prices, he/she is being a confused deputy. (On the other hand, if he/she notices, she's applying appropriate checking and is not a confused deputy, but a competent one)
In this case, what Fortify is saying is that you are being willing to substitute your own permissions for the caller's permissions (that's what checkCallingOrSelfPermissions does) - you are saying it doesn't matter what the caller can do, go with what you can do.
It is possible this is what you want - if your program is intended to perform privileged commands on behalf of unprivileged programs, this may be what you want. If that is that case, however, you are responsible for ensuring that the caller IS the real caller and that it isn't doing anything malicious. Fortify can't help you there - that is where you'd do a real, intense code inspection and some serious testing to make sure that that trust-boundary cannot be exploited by anything malicious. If your code passes, you'd normally then annotate so Fortify ignores it. These are called trust-boundaries and they are where you want to spend a lot of analysis time to make sure that you are performing appropriate controls.
You probably want to just listen to Fortify here and make the change, unless you've done the work to verify your inputs and are positive that this call cannot be used to do something malicious AND it is the only way to do something useful.