MobSF Security Flags on Intune-Wrapped React Native App: Exported Components (Activity/Service/BroadcastReceiver) - False Positives?

Question

Context:

We’ve integrated Microsoft Intune SDK into our React Native app (v0.72.6, minSDK 29) for app protection policies and authentication (using Microsoft OAuth2.0). After generating a release build and testing with MobSF, we received security warnings about exported components not being protected. We suspect these are false positives due to Intune’s internal security mechanisms but need confirmation.

1. Activity: net.openid.appauth.RedirectUriReceiverActivity
   • Issue: Exported (android:exported="true") without explicit permission.
   • Purpose: Handles OAuth redirects via AppAuth library.
2. Service: com.microsoft.intune.mam.client.notification.MAMNotificationReceiverService
   • Issue: Exported (android:exported="true") without explicit permission.
   • Purpose: Part of Intune SDK for policy notifications.
3. Broadcast Receiver: com.microsoft.intune.mam.client.service.MAMBackgroundReceiver
   • Issue: Exported (android:exported="true") without explicit permission.
   • Purpose: Part of Intune SDK for background tasks.

Steps Taken to Mitigate:

AppAuth Activity:

• Confirmed RedirectUriReceiverActivity follows AppAuth best practices.
• Added intent-filter specificity to limit exposure.

Intune Components:

• Added the ManageAppPermission signature-level permission to the Intune service/receiver (as per Microsoft documentation).
• Result: MobSF still flags the service as unprotected.

Questions for Microsoft:

1. Is there official guidance on suppressing these warnings for Intune SDK components?
2. For RedirectUriReceiverActivity, does the AppAuth + Intune integration inherently mitigate the risk of exported=true (e.g., via URI specificity or Intune policy enforcement)?

Additional Details:

• Intune SDK Version: 1.0.4549.6
• react-native-app-auth Version: 8.0.0
• MobSF Report Screenshots: (Attached images)

Why This Matters:

We need to ensure compliance with enterprise security standards while avoiding unnecessary workarounds for false positives. Official confirmation from Microsoft would help resolve this cleanly.

Are there any additional details, logs, or configurations you need from our side to investigate these issues? Please let us know.