mt5-ai-xauusd-trader/SECURITY.md

Security Policy

CRITICAL NOTICE This repository contains autonomous trading software that interfaces with live financial markets, broker credentials, and real capital. Security vulnerabilities in this codebase carry direct financial risk. All security reports MUST use the private channels defined below. Never disclose vulnerabilities publicly before a fix is released.

---

Table of Contents

• Supported Versions
• Reporting a Vulnerability
• What to Include in Your Report
• What NOT to Do
• Coordinated Disclosure Process
• Vulnerability Scope
• Severity Classification
• Response SLOs
• Safe Harbor
• Security Contacts
• Acknowledgements

---

Supported Versions

Only the versions listed below receive active security maintenance. Running an unsupported version in a live trading environment is done entirely at your own risk.

Version	Support Status	Security Patches	End of Support
v1.2.x	✅ Actively maintained	✅ All severities	TBD
v1.1.x	⚠️ Critical fixes only	Critical only	2026-08-01
≤ v1.0.x	❌ End of life	None	Ended

Recommendation: Always deploy the latest patch release. Enable Security Advisory notifications to receive alerts when new advisories are published.

---

Reporting a Vulnerability

Method 1 — GitHub Private Vulnerability Reporting (Preferred)

This is the fastest and most secure channel. Reports are fully encrypted and visible only to repository maintainers.

1. Go to the Security tab of this repository
2. Click "Report a vulnerability"
3. Fill in the structured form with as much detail as possible
4. Submit — you will receive a confirmation and tracking reference

Your report will never be publicly visible until a coordinated fix has been released and both parties agree on the timeline.

Method 2 — Encrypted Email

If GitHub private reporting is unavailable, email:

security@triqbit.com

Use the subject line format: [SECURITY] —

Example: [SECURITY] High — MT5 credentials exposed in structlog output

PGP encryption is strongly encouraged for Critical and High severity reports. Request our public key before sending sensitive content.

---

What to Include in Your Report

A complete report enables faster triage and remediation. Please provide as many of the following fields as possible: ┌─────────────────────────────────────────────────────────────┐ │ STAGE 1 — REPORT │ │ Reporter submits via GitHub private advisory or email │ └────────────────────────────┬────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ STAGE 2 — ACKNOWLEDGEMENT [≤48h] │ │ Maintainer confirms receipt and assigns tracking ID │ └────────────────────────────┬────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ STAGE 3 — ASSESSMENT [≤7d] │ │ Severity scored via CVSS 3.1, internal ticket created, │ │ reporter notified of classification and patch timeline │ └────────────────────────────┬────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ STAGE 4 — REMEDIATION [varies] │ │ Patch developed on private branch, peer-reviewed, │ │ validated against original reproduction steps │ └────────────────────────────┬────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ STAGE 5 — RELEASE [varies] │ │ Patch shipped, reporter notified, patch release tagged │ └────────────────────────────┬────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ STAGE 6 — PUBLIC DISCLOSURE [≤90d] │ │ GitHub Security Advisory published, CVE requested if │ │ warranted, reporter credited unless anonymity requested │ └─────────────────────────────────────────────────────────────┘

If we require more time than the SLO for any stage, we will proactively notify the reporter with a revised timeline and written justification before the deadline passes.

---

Vulnerability Scope

In Scope

Category	Specific Examples
Credential Exposure	MT5 password/token in logs, .env leakage, SecretStr bypass, dynamic discovery gaps, URL credential leaks
Trade Execution	RiskManager approval bypass, signal injection, order tampering
Database Layer	SQL injection in TradeLogger, Alembic migration tampering, constraint bypass
Model Integrity	Unsafe deserialization of PPO/LSTM/Dreamer weights, model poisoning
CI/CD Pipeline	GitHub Actions workflow injection, secrets in step outputs or artifacts
Dependency Chain	Exploitable CVEs in requirements.txt, requirements-ci.txt, Dockerfile
File Permissions	Privilege escalation via DB file (0o600) or config file permissions
API Endpoints	Unauthenticated FastAPI health endpoint abuse, information disclosure
Audit Trail	AuditLogger tampering, log deletion, decision chain bypass
Macro Intelligence	EventIntelligence manipulation to force trades during blocked windows

Out of Scope

• MetaTrader 5 terminal application and broker server infrastructure
• Third-party model weight files not distributed in this repository
• Vulnerabilities requiring physical access to the deployment host
• Automated scanner output with no demonstrated exploitability
• Denial-of-service via resource exhaustion (network/CPU flooding)
• Social engineering attacks targeting project maintainers
• Dependencies with no viable upgrade path and no realistic exploitation vector in the context of this application

---

Severity Classification

All vulnerabilities are scored using CVSS v3.1. Scores are assigned by maintainers during Stage 3 triage.

Severity	CVSS v3.1 Score	Project-Specific Examples
🔴 Critical	9.0 – 10.0	Full credential exfiltration, live trade manipulation, complete RiskManager bypass
🟠 High	7.0 – 8.9	Secrets leaked to logs, DB SQL injection, auth token exposure, position size manipulation
🟡 Medium	4.0 – 6.9	Partial information disclosure, insecure defaults with limited blast radius
🔵 Low	0.1 – 3.9	Minor hardening gaps, non-sensitive data exposure, defence-in-depth weaknesses
⚪ Informational	N/A	Best practice recommendations, configuration hardening suggestions

---

Response SLOs

Severity	Acknowledgement	Classification	Patch Target	Disclosure
🔴 Critical	24 hours	48 hours	7 days	30 days post-patch
🟠 High	48 hours	5 days	30 days	60 days post-patch
🟡 Medium	5 days	14 days	60 days	90 days post-patch
🔵 Low	7 days	30 days	90 days	90 days post-patch
⚪ Info	14 days	60 days	Best effort	N/A

SLO clocks start from confirmed receipt of a valid, reproducible report. Incomplete reports pause the SLO until sufficient information is provided.

---

Safe Harbor

We consider good-faith security research conducted in accordance with this policy to be authorised activity. We will not initiate or support legal action against researchers who:

1. Report through the private channels defined in this document
2. Avoid accessing, modifying, or destroying real user or trade data
3. Refrain from testing against live, production, or broker systems
4. Do not exploit the vulnerability beyond what is necessary to demonstrate the issue to maintainers
5. Provide us reasonable time to remediate before any disclosure

This safe harbor covers:

• Claims under the Computer Fraud and Abuse Act (CFAA)
• DMCA Section 1201 anti-circumvention provisions
• Equivalent legislation in your jurisdiction

If a third party initiates legal action against a researcher for activity conducted in good faith under this policy, we will make our position in support of the researcher publicly known.

---

Security Contacts

For Critical severity issues, contact both maintainers simultaneously.

Role	GitHub Handle	Responsibility
Repo Owner	@triqbit	Final escalation, release authority
Lead Reviewer	@andonly1348	Primary triage, patch coordination
CI/Security	@xnessom	Dependency audits, CI pipeline

---

Acknowledgements

We publicly thank all researchers who responsibly disclose vulnerabilities under this policy. Contributors will be credited in the published GitHub Security Advisory and in SECURITY_HALL_OF_FAME.md unless anonymity is explicitly requested at time of report.

---

Policy Metadata

Field	Value
Policy version	1.0.0
Effective date	2026-05-01
Review cadence	Quarterly
Next review	2026-08-01
Standard references	ISO/IEC 29147, CVSS v3.1, FIRST CVD Guidelines
Inspired by	GitHub Security Policy · Google VRP

To propose changes to this policy, open a PR targeting main with the label security-policy and request review from @andonly1348.