Contact PSIRT for Trellix and Skyhigh Security
Submit security vulnerability reports through
HackerOne.
For other queries, you can reach the team over email at
trellixpsirt@trellix.com.
PSIRT Policy Statements
- Actionable
We won't announce product or software vulnerabilities publicly without an actionable workaround, update, hotfix, or version update. Otherwise, we would be informing the hacker community that our products are a target, which would put our customers at greater risk. For vulnerabilities with major media attention, such as Log4j, we'll post a registered Security Bulletin stating our awareness and actions. This Security Bulletin is restricted to our customers.
- No Favorites
We disclose product vulnerabilities to all customers, at the same time.
- Discoverers
We give credit to vulnerability discoverers only if the following are satisfied:
- They want to be identified as a discoverer.
- They didn't make their research public, or share with other parties, before the Security Bulletin or Knowledge Base (KB) article addressing the issue, was published.
- They didn’t use their research to attack our impacted products or services, or any customers using them.
- Allow our customers a reasonable time after the fix is released before releasing further details which would aid an attacker (for example, releasing a PoC or a detailed analysis of the issue)
NOTE: Organizations, individuals, or both can be identified as discoverers.
Common Vulnerability Scoring System (CVSS) Scoring
We use the most current CVSS version CVSS v3.1.
All Security Bulletins must include the CVSS scores for each vulnerability and the associated CVSS vectors. The base score is needed. Both temporal and environmental scores are optional. Ideally, base scores should match the scores that the National Institute of Standards and Technology (NIST) assigns to CVEs.
Support Notification Service (SNS) Emails
An SNS email is needed for all Security Bulletins. To subscribe to SNS emails, go to the
SNS Subscription Preferences site.
Response Policy
Our fix and alert response depends on the highest CVSS base score:
| Priority (Security) |
CVSS Score |
Typical Fix Response* |
SNS |
| P1-Critical |
9.0–10 Critical |
Hotfix |
Alert |
| P2-High |
7.0–8.9 High |
Update |
Notice |
| P3-Medium |
4.0–6.9 Medium |
Update |
Notice |
| P4-Low |
0.0–3.9 Low |
Version update |
Optional |
| P5-Info |
0.0 |
Won't fix; informational |
N/A |
| * |
The fix response is based on the severity of the vulnerability, product lifecycle, and feasibility of a fix. The typical fix response described above isn't a commitment to produce a hotfix, update, or version update for all supported product versions. |
External Communication Mechanisms
Our external communication mechanism depends on the CVSS base score, number of customer inquiries, and amount of media attention:
- Security Bulletin (4–10)
- KB Article (2–4)
- Sustaining Statement (0–4)
- Not Needed (0)
| |
CVSS 0
Low |
CVSS 0–3.9
Low |
CVSS 4.0–6.9
Medium |
CVSS 7.0–10
High |
| External Disclosure (CVE)* |
KB article if multiple inquiries; otherwise not needed |
KB article |
Security Bulletin and
SNS |
Security Bulletin and
SNS |
| Customer Disclosure |
Sustaining statement |
Sustaining statement |
Security Bulletin and
SNS |
Security Bulletin and
SNS |
| Internal Disclosure |
Not needed |
Document in Release Notes |
Security Bulletin (post-release) and document in Release Notes |
Security Bulletin (post-release) and document in Release Notes |
*By default, we don't issue CVEs for issues that score below 4.0.
Crisis Scenarios
For publicly known high-severity vulnerabilities that affect multiple products, we might publish a Security Bulletin with an update for one product, and then update the Security Bulletin as updates and descriptions for other products become available.
Security Bulletins with multiple vulnerable products list all products with the following categories:
- Vulnerable and updated
- Vulnerable and not yet updated
- Vulnerable but low risk (given standard deployment best practices)
- Not vulnerable
- Being investigated (optional)
We don't usually publish Security Bulletins on Friday afternoons, unless it's a crisis scenario.
Vulnerability vs. Risk Scores
We participate in the industry-standard CVSS vulnerability scoring system. CVSS scores should be considered as a starting point to determine what risk a particular vulnerability might pose to our customers. The CVSS score shouldn't be confused with a risk rating of the seriousness of vulnerabilities that might occur in our products or the associated runtime environments on which our products execute.
The CVSS base score determines our initial response to a given incident.
Security Bulletins with multiple vulnerable products list all products by category. The list below describes what each of the categories means in terms of potential customer impact:
- Vulnerable—A product contains a verified vulnerability. The vulnerability poses some level of risk to customers. The associated CVSS score can be taken as an indication of the seriousness of impact from exploitation of the vulnerability in typical deployment scenarios.
- Not Vulnerable—A product doesn't contain the vulnerability or the presence of a vulnerable component can't be exploited in any manner. Use of the product presents no additional risk for customers.
- Vulnerable, but Low Risk—A product contains the vulnerability, perhaps as an included library or executable in the software image. But, the impact from exploitation is negligible and the product provides sufficient security controls so that the vulnerability isn't exposed to threat agents. Use of the product likely presents little extra risk for customers who use the product in recommended and typical deployment scenarios.
Security Bulletins
Security Bulletins are available on our Knowledge Center.
View Security Bulletins.
Report a Vulnerability
For information about how to report a vulnerability, see
KB95563 - Report a vulnerability.
