Security Policy en

中文 | English

Security Policy

Maintained version: v0.51.2 ｜ Last updated: 2026-07-06

This page describes EnerOS's vulnerability reporting process, supported versions, and three-layer defense mechanism. For the full compliance docs see the main repo docs/compliance/.

Vulnerability Reporting

Reporting Channels

Do not report security vulnerabilities in public issues.

Channel	Purpose
GitHub Security Advisory	Private vulnerability disclosure (recommended)
Email: security@eneros.dev	Backup channel

Report Contents

Please include:

1. Vulnerability description and impact scope
2. Reproduction steps (minimal reproducible example)
3. Affected versions
4. Assessed severity (CVSS v3.1)
5. Suggested fix (if any)

Response Time

Stage	SLA
Acknowledgment	Within 24 hours
Initial assessment	Within 72 hours
Fix feedback	Within 7 days (24 hours for critical)
Fix release	Within 30 days (7 days for critical)
Public disclosure	90 days after fix release (or as agreed with reporter)

Reporter Rewards

• Each vulnerability reporter will be listed in the SECURITY.md acknowledgments
• Critical vulnerability reporters may receive EnerOS project memorabilia

Supported Versions

Version	Support status	Security fixes
v0.51.x	✅ Current	All
v0.50.x	⚠️ Maintenance	Critical only
v0.49.x and earlier	❌ Not supported	None

Production deployments should always use the latest stable version.

Three-Layer Defense

1. Static Analysis (SAST)

Tool	Frequency	Trigger
CodeQL	Every PR	Critical vulnerabilities block merge
Semgrep	Every PR	Custom rule set
clippy	Every PR	-D warnings enforced

2. Dependency Audit

Tool	Frequency	Trigger
cargo audit	Every PR + daily cron	RUSTSEC vulnerabilities
cargo deny check	Every PR	GPL/AGPL rejection + duplicate dependency check
Dependabot	Weekly	Dependency update PRs

New dependencies must satisfy:

• MIT-compatible license
• Pass cargo audit and cargo deny
• Necessary and minimal
• Not GPL/AGPL
• Not unmaintained with unpatched RUSTSEC vulnerabilities

3. Runtime Defense

Capability	Implementation	See
Zero-trust	eneros-trust (CA / mTLS / rotation)	Zero-Trust Security
Intrusion detection	eneros-ids (baseline / IOC / lockout)	Zero-Trust Security
WORM audit	eneros-audit (HMAC chain + chattr +a)	SafetyGateway
Safety gateway	SafetyGateway (7-stage pipeline + type-level)	SafetyGateway
Multi-tenant isolation	eneros-tenant (namespace + quota)	Multi-Tenancy

Security Compliance

Standard	Scope	Documentation
NERC CIP	North American power systems	docs/compliance/
IEC 62443-4-1	SDLC	docs/compliance/iec-62443-4-1-sdlc.md
IEC 62443-4-2	SL matrix	docs/compliance/iec-62443-4-2-sl-matrix.md
GDPR	EU data protection	v0.47.0
PIPL	China personal information protection	v0.47.0
CCPA	California consumer privacy	v0.47.0

Security Configuration Baseline

Recommended security config for production deployments:

[zero_trust]
mtls_required = true
rotation_days_before_expiry = 30

[threat_detection]
enable_baseline = true
enable_ids = true
lockout_threshold = 5
lockout_duration_secs = 900

[audit]
max_size_mb = 512
retention_days = 365
# hmac_secret must be a strong random 32 bytes

[security]
# jwt_secret must be a strong random ≥ 32 bytes

Known Security-Related Limitations (v0.51.2)

• IOC threat intelligence loads from JSON files only; no threat intelligence platform integration
• Behavior baseline covers API layer only, not event bus traffic
• WORM uses Linux chattr +a only; no object storage WORM support
• 67 unwrap/expect remaining (may cause panics) — 88 removed in v0.51.0, full removal planned for v0.52.0

Related Documentation

• Main repo SECURITY.md — Security policy (if present)
• Main repo docs/compliance/ — Compliance docs directory
• Wiki Zero-Trust Security — Four security subsystems
• Wiki SafetyGateway — Type-level unbypassable
• Wiki Multi-Tenancy — Namespace isolation
• GitHub Security Advisories: https://github.com/Gawg-AI/EnerOS/security/advisories/new