This is sponsored content. The CyberTech Edition newsroom did not produce this article.
Trellix, the security platform formed from the 2021 merger of McAfee Enterprise and FireEye and now serving more than 50,000 business and government customers, disclosed earlier this month that an unauthorized party accessed a portion of its source code repository. The company retained outside forensic experts, notified law enforcement, and posted the disclosure directly to its corporate homepage. Trellix said there is no evidence the code was released or that the company’s distribution process was compromised.
The disclosure is a useful case study, not because the incident itself is unique, but because the response is closer to the right shape than many comparable disclosures have been. Three observations worth carrying into customer conversations with security vendors generally.
The first is that source-code access changes the risk model regardless of whether code is exfiltrated. Gartner analyst Deepak Mishra, commenting on the incident, noted that source code access gives an attacker “valuable insight into detection logic, product architecture, and engineering assumptions.” That insight is durable. It is also difficult for the vendor to fully mitigate after the fact. The customer-side response is not to assume the vendor’s product is now broken. It is to assume that the threat actor with the access has a marginally better roadmap for evading the product’s detections, and to layer detection accordingly.
The second is that the absence of observed exploitation is not the same as the absence of risk. Trellix’s disclosure language (“no evidence of code release”) is technically accurate and operationally honest. It is also, by definition, the kind of statement that is only as good as the visibility behind it. The customer-side question to ask is what visibility the vendor has into post-incident exploitation attempts and how that visibility is being shared with customers operating in different sectors.
The third is that the disclosure cadence and the customer-engagement model after the disclosure are where customer-vendor trust is rebuilt. Trellix’s posture, by most reports from customers we have spoken with, has been to over-engage rather than under-engage. Multiple customer security teams have received direct briefings, not just notifications. The CSO’s office has been available for follow-up questions on a same-day basis. The IOCs that the vendor identified post-incident were shared promptly with major MSSPs and customer security operations centers. That is the model.
For Trellix’s competitors, the temptation to capitalize on the disclosure is real and is the wrong instinct. The honest reality is that the major vendors in endpoint and email security have all, at various points in the last five years, dealt with comparable incidents. The vendor that has not had a source code or supply chain incident yet is the vendor that has not been transparent about one. Customers serious about evaluating security vendors should ask not whether the vendor has had an incident but how the vendor responded when they did.
To learn more about Trellix’s response and ongoing customer communications, visit trellix.com.