EnerOS v0.42.0 Release Notes

• Release Date: 2026-06-25
• Codename: Audit
• Support Status: Stable
• Total Crates: 50
• Test Cases: 6350+
• Contributors: 26

Version Overview

EnerOS v0.42.0 is the second release of the “Mature Optimization” phase, focusing on the comprehensive establishment of security audit capabilities. After v0.41.0 solved the “measurable performance” problem, this release addresses the “auditable security” problem, building a complete security closed loop from vulnerability scanning, dependency auditing, security reporting to remediation recommendations.

As power systems are national critical information infrastructure, their security requirements far exceed those of ordinary software. Compliance frameworks such as NERC CIP, IEC 62443, and MLPS 2.0 (Multi-Level Protection Scheme) all require operational systems to have continuous vulnerability monitoring capabilities and traceable security audit records. v0.42.0 builds these requirements as native capabilities of EnerOS, rather than relying on external security tools.

This release adds the eneros-audit crate, providing four functional modules: CVE vulnerability scanning, dependency auditing, configuration baseline checking, and secret leak detection. It can automatically block code merges with high-severity vulnerabilities in the CI pipeline. Security reports support SBOM (Software Bill of Materials) export, meeting supply chain security compliance requirements.

Key Metrics

New Features

1. CVE Vulnerability Scanning

Added the eneros-audit crate with a built-in CVE vulnerability scanning engine, periodically syncing with NVD (National Vulnerability Database) and RustSec Advisory Database. The scanner parses the dependency tree in zero-copy mode, performs CVE matching for each crate version, and provides severity rating and remediation recommendations.

Scanning Engine Architecture

eneros-audit/
├── src/
│   ├── scanner/          # Scanning engine
│   │   ├── cve.rs        # CVE matcher
│   │   ├── dependency.rs # Dependency tree parsing
│   │   └── config.rs     # Configuration baseline check
│   ├── advisory/         # Vulnerability advisory database
│   │   ├── nvd.rs        # NVD sync
│   │   └── rustsec.rs    # RustSec sync
│   ├── report/           # Report generation
│   │   ├── sbom.rs       # SBOM export
│   │   └── remediation.rs# Remediation recommendations
│   └── policy/           # Security policy
│       ├── severity.rs   # Severity rating
│       └── gate.rs       # CI gate
└── rules/                # Custom rules

Usage Example

use eneros_audit::{AuditScanner, AuditConfig, Severity};
use std::time::Duration;

let scanner = AuditScanner::new(AuditConfig {
    cve_database: "audit-db/nvd".into(),
    rustsec_database: "audit-db/rustsec".into(),
    auto_update: true,
    update_interval: Duration::from_secs(6 * 3600),
    ignore_file: Some(".audit-ignore".into()),
});

// Scan current project
let report = scanner.scan_project("./Cargo.toml").await?;

// Output vulnerability summary
for vuln in &report.vulnerabilities {
    println!(
        "[{}] {} in {} {} - {}",
        vuln.severity, vuln.cve_id, vuln.package, vuln.version, vuln.title
    );
    println!("  Remediation: upgrade to {}", vuln.fixed_version);
}

println!("Scan complete: {} vulnerabilities, {} warnings",
    report.vulnerabilities.len(),
    report.warnings.len());

Vulnerability Severity Rating

2. Dependency Auditing

The dependency audit module performs deep analysis on the entire dependency tree (including indirect dependencies), identifying outdated versions, unmaintained crates, license conflicts, and duplicate dependencies. Audit results are displayed in a tree structure for easy location of the introduction path of problematic dependencies.

use eneros_audit::dependency::{DependencyAuditor, AuditLevel};

let auditor = DependencyAuditor::new()
    .level(AuditLevel::Full)        // Audit all indirect dependencies
    .check_license(true)            // License compliance check
    .check_maintenance(true)        // Maintenance status check
    .check_duplicates(true);        // Duplicate dependency detection

let tree = auditor.analyze("./Cargo.lock").await?;

// Output problematic items in the dependency tree
for issue in &tree.issues {
    println!(
        "[{}] {} {} - Introduction path: {}",
        issue.kind, issue.package, issue.version, issue.path
    );
}

Dependency Audit Dimensions

License Compliance Matrix

3. Security Report Generation

The security report module supports SBOM (Software Bill of Materials) export, meeting supply chain security compliance requirements. Supports three international standard formats: SPDX, CycloneDX, and SWID, with three output forms: PDF, HTML, and JSON.

use eneros_audit::report::{SbomExporter, SbomFormat, SecurityReport};

let report = scanner.scan_project("./Cargo.toml").await?;

// Export SBOM (CycloneDX format)
let sbom = SbomExporter::new()
    .format(SbomFormat::CycloneDX)
    .version("1.5")
    .include_hashes(true)
    .include_licenses(true);

sbom.export(&report, "reports/sbom.cdx.json")?;

// Export security report (PDF)
let security_report = SecurityReport::from(&report)
    .include_vulnerabilities(true)
    .include_remediation(true)
    .include_compliance(true);

security_report.save_pdf("reports/security-audit.pdf")?;

Report Types Overview

4. Configuration Baseline Check

The configuration baseline check module scans runtime configurations against security baseline policies for insecure items, such as weak passwords, plaintext secrets, overly broad permissions, and disabled encryption.

use eneros_audit::config::{ConfigScanner, Baseline, Finding};

let baseline = Baseline::load("policy/security-baseline.yaml")?;
let scanner = ConfigScanner::new(baseline);

let findings = scanner.scan_config("./eneros.toml").await?;

for finding in &findings {
    println!(
        "[{}] {}: current={}, expected={}",
        finding.severity, finding.rule, finding.current, finding.expected
    );
}

Baseline Check Rule Examples

5. Remediation Recommendation Engine

The remediation recommendation engine automatically generates optimal upgrade paths based on the vulnerability database and dependency graph. The engine considers version compatibility constraints to avoid introducing new breaking changes through upgrades.

use eneros_audit::remediation::{RemediationEngine, UpgradePlan};

let engine = RemediationEngine::new(&report);
let plan: UpgradePlan = engine.suggest().await?;

println!("Recommended upgrades for {} dependencies:", plan.upgrades.len());
for step in &plan.upgrades {
    println!(
        "  {} {} -> {} (fixes {} vulnerabilities)",
        step.package, step.from, step.to, step.fixes
    );
}

// Validate that the upgrade plan does not introduce new issues
let validation = engine.validate(&plan).await?;
if validation.has_conflicts() {
    for conflict in &validation.conflicts {
        eprintln!("Conflict: {}", conflict);
    }
}

Improvements

Audit Chain Tamper Protection Enhancement

The audit chain in eneros-trust introduces a Merkle tree structure, generating a Merkle root every 1000 log entries and signing it with HSM. Any tampering with historical logs will cause Merkle verification to fail.

Automated Key Rotation

The rotation period for certificates and keys changed from manual configuration to dynamic rotation based on risk scores. High-risk keys (such as root CA) are rotated every 90 days by default, while low-risk keys (such as internal service certificates) are rotated every 24 hours by default.

Security Sandbox Hardening

The WASM sandbox for Agent tool calls adds a capabilities model. Each tool call must explicitly declare required capabilities (network access, file read/write, system calls). Undeclared capabilities are denied at runtime.

Bug Fixes

• BG-301: CVE database sync failed in proxy network environments, added SOCKS5 proxy support
• BG-305: Dependency audit infinite loop on circular dependencies, introduced visit marking mechanism
• BG-309: SBOM export memory overflow when dependency count > 2000, changed to streaming export
• BG-313: Configuration baseline check false positive on TOML comment lines, fixed parser
• BG-317: Remediation recommendation engine gave upgrade paths conflicting with MSRV, added Rust version constraint

Breaking Changes

BC-211: eneros-trust Audit Log Format Change

Audit logs changed from line-based JSON to Merkle chain structure. Old logs need to be converted through the migration tool.

eneros-cli audit migrate --from v0.41 --to v0.42

BC-212: AuditScanner::scan_project Changed to Async

The scan method changed from synchronous to asynchronous to support remote database queries.

// v0.41.0 (old)
let report = scanner.scan_project("./Cargo.toml")?;

// v0.42.0 (new)
let report = scanner.scan_project("./Cargo.toml").await?;

Dependency Upgrades

Upgrade Guide

Upgrade from v0.41.0

cargo update
cargo test --workspace

Add audit dependency in Cargo.toml:

[dependencies]
eneros-audit = "0.42"

Run the first security audit:

eneros-cli audit scan --full
eneros-cli audit sbom export --format cyclonedx

Migrate audit log format:

eneros-cli audit migrate --from v0.41 --to v0.42 --dry-run
eneros-cli audit migrate --from v0.41 --to v0.42 --apply

Related Documentation

• Security Audit Guide - Vulnerability scanning and dependency auditing
• SBOM Export - Software Bill of Materials
• Configuration Baseline - Security baseline policy
• Compliance Framework - IEC 62443 compliance