# Security Policy

## Supported versions

Wickra is pre-1.0. Security fixes are applied to the latest released `0.5.x`
version only; please upgrade to the newest release before reporting an issue.

| Version | Supported |
| --- | --- |
| 0.5.x (latest) | :white_check_mark: |
| older 0.5.x | :x: |

## Reporting a vulnerability

**Do not open a public issue for a security vulnerability.**

Report it privately through one of:

- GitHub's [private vulnerability reporting](https://github.com/wickra-lib/wickra/security/advisories/new)
  ("Report a vulnerability" under the repository's *Security* tab), or
- email to **support@wickra.org** with a subject line starting with
  `[wickra security]`.

Please include:

- the affected version(s) and platform / language binding,
- a description of the issue and its impact,
- steps to reproduce, ideally a minimal proof of concept.

## What to expect

- An acknowledgement within **5 working days**.
- An assessment and, if confirmed, a planned fix with a target release.
- Coordinated disclosure: we will agree on a disclosure date with you and
  credit you in the release notes unless you prefer to stay anonymous.

## Scope

In scope: the published crates (`wickra-core`, `wickra-data`, `wickra`), the
PyPI/npm packages, and the build/release workflows in `.github/workflows/`.

Out of scope: vulnerabilities in third-party dependencies (report those
upstream; we track them via Dependabot and `cargo-deny`).

## Security assurance case

This is a short, evidence-backed argument for why Wickra can be used safely.

**Security requirements.** Wickra is a computational library: it ingests
numeric market data and produces indicator values. It stores no user
credentials, authenticates no external users, and implements no cryptography of
its own. The requirements are therefore: (1) memory safety and freedom from
undefined behaviour, (2) robust handling of untrusted/degenerate numeric input
without panics or unbounded resource use, (3) integrity of the published
artifacts, and (4) a healthy dependency supply chain.

**How the requirements are met.**

- *Memory safety* — the core and all bindings are written in Rust. The crates
  forbid or minimise `unsafe`, so the compiler guarantees memory and thread
  safety for the indicator logic.
- *Input robustness* — every indicator validates its parameters and rejects
  non-finite inputs at construction; behaviour on edge cases (flat markets,
  warmup, reset) is pinned by unit tests, and the public update paths are
  exercised by coverage-guided fuzzing (`cargo-fuzz` / libFuzzer) in CI.
- *Static and dynamic analysis* — every push and pull request runs Clippy
  (`clippy::pedantic`, warnings-as-errors), CodeQL, fuzzing, and the full test
  suite, with 100% line coverage on the core crate tracked by Codecov.
- *Artifact integrity* — releases are built in CI, commits and tags are signed,
  the `main` branch requires signed commits, and release artifacts carry build
  provenance attestations.
- *Supply chain* — dependencies are pinned and monitored with Dependabot and
  audited with `cargo-deny` (license + advisory checks) on every change.

**Residual risk.** The optional `live-binance` feature opens a TLS WebSocket to
an exchange using the platform TLS library; transport security therefore
depends on that library, not on Wickra. Wickra is not a trading system and is
provided "as is" — see the disclaimers in `README.md` and the licenses.