AeThex-OS/SECURITY.md
MrPiglr 19a9f93788 Revise SECURITY.md to enhance security policy details
Expanded the security policy to include detailed sections on purpose, organizational boundaries, reporting vulnerabilities, severity assessment, response timelines, disclosure policy, bug bounty, security best practices, and safe harbor.
2025-12-28 10:08:21 -07:00

4.3 KiB
Raw Blame History

Security Policy

1. Purpose and Scope

The AeThex ecosystem takes security seriously across all repositories, including operating systems, tooling, libraries, documentation, and standards.

This policy defines how security vulnerabilities should be reported, assessed, disclosed, and remediated across AeThex-managed projects.

Do not disclose security vulnerabilities publicly. Public GitHub issues, pull requests, or discussions are not appropriate channels for reporting security issues.


2. Organizational Boundaries

AeThex operates through distinct but coordinated entities. Security handling respects these boundaries:

AeThex Foundation

  • Owns standards, specifications, and certification criteria
  • Handles vulnerabilities in published standards, reference specs, and audits
  • Does not deploy production systems

AeThex Labs

  • Owns experimental software, research prototypes, and educational tooling
  • Handles vulnerabilities in non-production and experimental code
  • May deprecate or archive vulnerable experiments rather than patch them

AeThex Corporation

  • Owns production software, infrastructure, and commercial distributions
  • Handles vulnerabilities with operational, customer, or commercial impact
  • Responsible for patch releases, advisories, and mitigations

The appropriate entity will triage the report internally if scope is unclear.


3. Supported Versions

Security updates are provided only for supported versions listed below.

Version Supported
5.1.x Yes
5.0.x No
4.0.x Yes
< 4.0 No

If you are using an unsupported version, upgrade before reporting unless the issue demonstrates systemic risk.


4. Reporting a Vulnerability

Primary Reporting Channel

Email: security@aethex.foundation
Subject: Security Vulnerability Report <repository name>

If email is not feasible, GitHub Private Vulnerability Reporting may be used where enabled.

Encryption

PGP-encrypted submissions are encouraged when practical. (See PGP section below.)


5. What to Include

Please provide as much of the following as possible:

  • Clear description of the vulnerability
  • Affected repository, component, and versions
  • Steps to reproduce (proof-of-concept preferred)
  • Impact assessment (confidentiality, integrity, availability)
  • Environment details (OS, architecture, configuration)
  • Any relevant logs, traces, or artifacts

Incomplete reports may delay triage.


6. Severity Assessment (CVSS)

AeThex uses CVSS v3.1 as a baseline for severity classification:

  • Critical (9.010.0): Immediate action, coordinated fix
  • High (7.08.9): Expedited remediation
  • Medium (4.06.9): Scheduled fix
  • Low (0.13.9): May be deferred or documented only

Final severity is determined internally and may differ from reporter estimates.


7. Response Timeline

You can expect the following process:

  • Acknowledgement: within 72 hours
  • Initial triage: within 5 business days
  • Status updates: at least every 7 days while open

Complex issues or multi-repository impact may extend timelines.


8. Disclosure Policy

AeThex follows a coordinated disclosure model:

  • Accepted vulnerabilities are patched or mitigated before public disclosure
  • Reporters will be notified prior to public advisories when feasible
  • Declined reports will receive a brief explanation
  • Public disclosure without coordination may affect future participation

9. Bug Bounty (Discretionary)

AeThex may, at its discretion:

  • Acknowledge reporters in advisories or release notes
  • Provide monetary or non-monetary rewards for high-impact findings

There is no guaranteed bounty, and participation does not create any legal or contractual obligation.


10. Security Best Practices

Contributors and users are expected to:

  • Avoid committing secrets or credentials
  • Use least-privilege principles
  • Keep dependencies updated
  • Treat security-sensitive changes with heightened review

Repositories may enforce additional controls.


11. Safe Harbor

Security research conducted in good faith, without data exfiltration, service disruption, or privacy violation, will not be considered a violation of AeThex policy.


12. PGP Key

For encrypted communication, use the following PGP key: