Crowdstrike Falcon vs Xcode performance
Our IT department is using CrowdStrike Falcon, an ML-security tool, on all the Mac hardware. It will flag processes as malicious, and it sounds like it may sandbox such processes that are deemed malicious and / or scan anything the process touches.
TLDR
Does anybody know how to make CrowdStrike Falcon behave nicely with Xcode and its tools and prevent it from consuming high CPU and interfering with the build and debugging processes? Xcode, SwiftUI previews and building should be as performant as possible.
Details
Perplexity describes CrowdStrike Falcon as follows:
CrowdStrike Falcon is a cloud-based endpoint security platform that provides real-time protection against malware, ransomware, and other cyber threats. It uses artificial intelligence and machine learning to detect and prevent known and unknown threats across endpoints (laptops, desktops, servers, etc.), cloud workloads, and cloud environments. The Falcon platform includes next-generation antivirus, endpoint detection and response (EDR), managed threat hunting, vulnerability management, and other security capabilities delivered through a lightweight sensor that streams data to the CrowdStrike cloud for analysis and response.
The problem is that apparently Falcon's ML signatures will flag Xcode as malicious. So when building in Xcode, Falcon will use a huge amount of CPU (I have seen it go up to 456%), affecting build performance. I am getting the impression it is sandboxing and / or scanning every single file Xcode touches. The same goes for the iOS Simulator which will also cause Falcon to consume lots of CPU. It's clear this is affecting our build performance a lot.
Falcon supports a number of exclusions:
Machine learning (ML) exclusion: For trusted file paths, stop all ML-based detections and preventions, or stop files from being uploaded to the CrowdStrike cloud.
Indicator of attack (IOA) exclusion: Stop all behavioral detections and preventions for an IOA that’s based on a CrowdStrike-generated detection.
Sensor visibility exclusion: For trusted file paths that you want to exclude from sensor monitoring, minimize sensor event collection, and stop all associated detections and preventions. Use sensor visibility exclusions with extreme caution. Potential attacks and malware associated with excluded files will not be recorded, detected, or prevented.
Using Sensor Visibility Exclusions it is possible to exclude applications on file pattern basis and preventing Falcon's ML signatures for flagging any such process as malicious. Which means that it is possible to exclude /Applications/Xcode.app/** and prevent it, or the processes it spawns, as malicious.
However, Xcode and the toolchain are much more complicated than just excluding a single binary. Switching toolchains via sudo xcode-select -s will also update a lot of files in /usr (see Xcode.app/Contents/Developer/usr) such as /usr/bin/swift*, /usr/bin/ibtool*, /usr/bin/lldb and /usr/bin/xcrun (there are many more).
For testing Xcode performance we excluded /Applications/Xcode.app/** and /usr/bin from Falcon, but just launching the simulator and a simulator build of the app will still cause Falcon to go up to about 300%. I assume this will affect SwiftUI live previews as well. Probably /Users/*/Library/Developer/** should be excluded as well then?
Obviously, Falcon's AI/ML should just identify all of this as legitimate software development tools and no exclusions should be necessary...
IMHO a file-pattern based exclusion seems to contradict what this tool is supposed to do. I would think it should evaluate signing (codesign / spctl) or validate checksums, rather than file pattern based exclusions. But as long as Xcode becomes more performant I am not complaining. The less an IT tool is flagging legitimate software as malicious and interfering with our daily work, the better.
So my question is if anybody knows how to make CrowdStrike Falcon behave nicely with Xcode and its tools and prevent it from consuming high CPU and interfering with the build and debugging processes? Xcode, SwiftUI previews and building should be as performant as possible.