Trellix Confirms Source Code Breach: Assessing the Supply Chain Risk
Just caught the breaking news regarding Trellix confirming unauthorized access to a portion of their source code repositories. While they are currently engaging forensic experts, the lack of specific details on what code was accessed is unsettling. Given Trellix's massive footprint in EDR and XDR (the merger of McAfee Enterprise and FireEye), this is a potential supply chain nightmare.
The immediate fear is always hardcoded secrets or crypto keys. If the threat actors had time to sit in the repo, they weren't just copying files for fun; they were grepping for secrets.
I'm advising my teams to start by auditing our EDR agents for unexpected behavior or memory dumps. If you want to sanity-check your own internal repos for similar "leak" vectors (like exposed API keys), I highly recommend scanning with TruffleHog:
docker run --rm -v "$(pwd):/work" trufflesecurity/trufflehog:latest git https://github.com/your-org/your-repo --
Until Trellix releases a specific CSA or CVE list, we are treating all their modules as suspicious and monitoring for unsigned binaries.
How are you all handling this? Are you standing up isolated honeypots with Trellix agents to detect if a weaponized update drops, or just waiting for IOCs?
Good call on the secrets scanning. Source code access is rarely about the IP itself; it's almost always about finding that one admin_api_key buried in a config file that wasn't rotated. If they found a signing key, this moves from a data breach to a supply chain catastrophe instantly. I'd also recommend checking your SIEM for any unusual process execution attempts signed by Trellix certificates over the last few weeks.
We're holding off on panic-patching until we see the IOCs, but we've bumped the alerting rules for any unsigned binaries attempting to load into the Trellix process space.
DeviceProcessEvents
| where InitiatingProcessFileName has "Trellix"
| where IsSigned == false
| project Timestamp, DeviceName, FileName, InitiatingProcessFileName
So far, it's been quiet, but trust levels have dropped significantly. The lack of transparency on *which* repository is the most frustrating part.
This feels like the SolarWinds anxiety all over again. I'm mostly concerned about the email security gateway components. If they have the source for the spam filtering logic, bypassing it becomes trivial. I'm currently verifying all our transport rules and isolating the gateway servers until we get more clarity.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access