Let's get something straight right out of the gate: if you're relying on an endpoint protection suite like Intercept X to the point where you're writing custom scripts to clean up what its "cutting-edge" Deep Learning finds, you've already lost half the battle. You're treating a symptom, not the cause, and you're baking in a massive operational dependency on a single vendor's detection logic. What happens when Sophos decides that particular threat family gets a different name or their engine tweaks its output format? Your script breaks, and you're left manually cleaning up the mess you thought you automated.
This entire concept of writing post-detection cleanup scripts is a tacit admission that the product doesn't fully do the job it sold you on. You bought an integrated, next-gen platform. Now you're playing systems integrator, stitching together the gaps with brittle scripts that you alone will have to maintain. Have you fully accounted for the total cost of ownership here? It's not just the license fee. It's the hours spent developing, testing, and maintaining these scripts across different OS versions and threat scenarios. It's the audit trail complexity when your script does something unexpected. It's the liability when a script fails and an incident responder can't tell what was a product action versus your custom code.
Consider the migration pitfall you're constructing for yourself. Every one of these scripts is another knot in the rope tying you to Sophos. Want to evaluate CrowdStrike or Microsoft Defender in a year? You'll not only have to compare detection rates, you'll have to rebuild this entire auxiliary cleanup automation framework, assuming the new vendor's API and detection taxonomy even allow for it. You've moved from buying a security product to building a Sophos-specific security operations wrapper.
Before you write a single line of code, ask the hard questions. Why isn't the product's remediation engine handling this natively? Have you pushed your account team for this as a feature? Have you looked at whether the threat truly requires a custom script, or if you're over-engineering because the console's workflow seems clunky? Sometimes the most efficient "custom script" is a well-documented, manual procedure run by a trained human, especially for low-frequency, high-complexity threats. Automating everything sounds great until you automate a mistake.
If you're still determined to go down this path, at least build your scripts to be paranoid. They should log exhaustively, validate every single input, assume the Sophos alert could be a false positive, and include a dry-run mode. Don't just blindly delete or quarantine based on a detection name. Your script needs more context than the alert typically provides, which means more API calls, more error handling, and more complexity. You're essentially building a miniature, unsupported EDR within your EDR.
Just my two cents
Skeptic by default