In situations where the application is under constant development and presents similar behavior and/or operations as what triggered the initial conviction, it's possible the new versions of the executable may trigger blocks or it might be terminated depending on the policy the endpoint has been assigned to. If the file has been categorized as malware, suspicious malware or otherwise malicious while the business is certain the file is not malicious (false positive) please engage support to have the reputation of the file reassessed and cleared if deemed clean after analysis. Of course, every time code is compiled, a new SHA256 value will be generated.
When submitting false positives, please refer to this KB, and kindly provide the following information:
In the interim, please add the new SHA256 to the approved list by hash. Adding multiple hashes can be accomplished through the csv upload functionality, as explained here.
Alternatively, for developer environments, the IDE/compiler should be added as an IT Tool allow list. Once added, any subsequent file compiled by the tool will be given a local_white reputation. Please note this only affects the local machine's reputation.
If adding the newly updated executable's SHA256 to the approved list is not feasible, as a temporary workaround a permission rule to bypass the path where the application resides can be added to the policy.
Application at Path: <file path for application> Operation: Runs or is running Action: Allow & Log
We recommend creating a temporary policy and limiting the number of endpoints added to it, as these types of bypass rules can represent a risk and can affect the organization security posture. Adding a permission by hash value while the investigation is ongoing is the preferred method, when certain the file is in fact clean.