Salesforce managed package security review

Question

We had submitted our managed package for security review and it had failed multiple times. In the latest failure report , below vulnerability is reported which does not have any public documentation. (I'am not able to find it)

Access Control Violation Vulnerability : Events sent across namespace boundaries that include sensitive data not intended for consumption by another namespace. Unintentional leak of data across namespace boundary via improper configuration of events. Use properly scoped LWC custom events.

Below is the snippet for the same :

<?xml version="1.0" encoding="UTF-8"?>
<LightningMessageChannel xmlns="http://soap.sforce.com/2006/04/metadata">
    <description>Sample description</description>
    <isExposed>true</isExposed>
    <lightningMessageFields>
        <description>Sample Description</description>
        <fieldName>toastType</fieldName>
    </lightningMessageFields>

Basically , they are asking to configure 'isExposed' flag in lightning Message Channel to false so that the components only from this namespace can publish or subscribe to this channel.

Has anyone else observed this issue?

Also , even after fixing some vulnerabilities, Salesforce still keeps on reporting them so that we have to submit the package again.

After raising a support case , Salesforce says that public documentation will be available soon and when confronted with the wrong report, they completely dodge the question asked.

What I'am trying to understand is if tools cannot catch such vulnerabilities(Salesforce support said this) and public documentation is not easily accessible, How is it expected to be fixed beforehand?

Anyone having similar experiences, can please help here.

Answer 1

For the Access Control Violation Vulnerability in Lightning messaging channel, we had to remove its usage and add it in false positive document.

Since we cannot remove Lightning messaging channel from managed package , we need to replace it with a new one with isExposed set to false.

I was not able to find documentation for above scenario but this was shared with us via support case.