Thanks for helping keep Valenx and its users safe.

Valenx is pre-alpha — no shipping release yet. Until 1.0 ships, master is the only supported branch; apply fixes by pulling the latest commit.

Once we cut 1.0, the full backport matrix (current stable, previous stable, LTS) lives in POLICIES.md → Supported versions. That section is the source of truth; this document covers the reporting and response mechanics below.

Do not open a public GitHub issue for security reports. Use one of:

1. GitHub Security Advisories — preferred. From the repo home, click Security → Report a vulnerability. This creates a private advisory visible only to the maintainers.
2. Email — security@valenx.org (set up Year 1). Maintainers hold the key; PGP key fingerprint and instructions will be published at /.well-known/security.txt once the domain is live.
3. Pre-domain fallback — until valenx.org is registered, email the BDFL directly; address is listed in MAINTAINERS.md.

• A clear description of the issue
• Affected version(s) — commit hash is ideal
• Steps to reproduce (proof of concept helpful but not required)
• Impact: what an attacker could do
• Your suggested fix (if you have one)

You do not need to provide a patch — a good report is enough.

We'll keep you in the loop through the advisory thread. If you prefer to stay anonymous in public credits, say so in the report.

We follow responsible-disclosure practice:

1. Reporter files privately
2. Maintainers confirm + develop fix on a private branch
3. Security release cut, advisory published with CVE if warranted
4. Reporter credited (unless they asked otherwise)
5. Embargo lifts; technical write-up may follow

If the issue is already being exploited in the wild or has been disclosed elsewhere, we'll shorten the timeline.

In scope — vulnerabilities in any code in this repository:

• valenx-app and all workspace crates
• Installer and packaging artifacts (MSI, .app, AppImage, deb, rpm)
• Update mechanism and signing infrastructure
• Documentation examples, if they demonstrate insecure patterns
• Our CI/CD workflows (supply-chain exposure)
• Our websites (valenx.org and subdomains) when they exist

Out of scope — please report these upstream instead:

• Bugs in bundled third-party solvers (OpenFOAM, Code_Aster, gmsh, etc.) — report to those projects directly. We'll coordinate on patches if they affect our adapters.
• Bugs in Rust, crates.io crates we depend on, or the standard library — report to the respective project; we'll bump the pin once fixed.
• Denial-of-service caused by solver inputs crafted by the user themselves (e.g., a mesh that blows up an OpenFOAM case the user wrote). This is a usability issue, not a security issue.
• Anything requiring physical access to the user's machine with administrator privileges already granted.

The parts of the codebase we pay extra attention to:

• Plugin sandbox (valenx-plugins / wasmtime integration) — a plugin escaping the sandbox is a critical bug
• Subprocess adapters — command injection via project file contents is a critical bug
• Project file loader — path traversal, arbitrary-file-read via a crafted .valenx file
• Update mechanism — signature bypass, downgrade attacks
• Python/Lua scripting bridges — scripts should run with the same trust level as the project, but not be able to call arbitrary FFI
• Auto-discovery of tools on PATH — spoofing a binary on the user's PATH should not give automatic trust

We maintain a Software Bill of Materials (SBOM) for every release, generated by cargo-auditable. The SBOM ships with the release artifacts and is signed.

Locally, run bash scripts/qa.sh (or pwsh scripts/qa.ps1 on Windows) which includes cargo deny check — the scoped QA harness catches license drift, banned-version pins, and the curated deny.toml advisory-ignore set on every developer's machine. cargo-audit was dropped from the workspace in favour of cargo-deny's advisories check, which already reads the RustSec advisory database and integrates with the same deny.toml allow-list. CI is currently manual-trigger-only since 2026-05-24 — see docs/CI.md for the rationale and the planned re-enablement path.

Bundled third-party solvers are pinned by version and checksum in tools.lock. Downloads are verified against the checksum before being executed.

None yet. When we ship, advisories will be published at:

• GitHub Security Advisories (on the repo)
• SECURITY_ADVISORIES.md in the repository
• The valenx.org security page
• Announcement on the valenx-announce mailing list

Questions about this policy? Open a discussion or email the maintainers.