Security Policy & Vulnerability Reporting

This page documents the security measures and the vulnerability reporting process for spotforecast2-safe.

Reporting a Vulnerability

If you discover a security vulnerability, do not open a public issue. This puts all users at risk.

Email your findings to:

thomas.bartz-beielstein@th-koeln.de

Subject line: [SECURITY] spotforecast2-safe Vulnerability Report

Alternatively, open a confidential issue in the project repository at https://gitlab.git.nrw/thk-f10/spotsevenlab/spotforecast2-safe (tick “This issue is confidential” when creating it).

What to Include

Provide as much detail as possible:

  • Description of the vulnerability
  • Affected version(s)
  • Steps to reproduce (if applicable)
  • Potential impact and severity
  • Suggested fix (if available)

Response Timeline

We aim to respond to all vulnerability reports promptly:

  • Acknowledgment: within 24 hours
  • Initial assessment: within 3 business days
  • Fix and patch: varies based on severity (critical issues prioritized)
  • Public disclosure: coordinated after a patch is available

Supported Versions

Only the latest release receives security updates. This project follows semantic versioning and releases frequently; there is no long-term-support branch and no backporting to earlier major versions. Check PyPI for the current release.

Two releases are pinned by an external reproduction archive and will never be removed from PyPI, but that is an availability guarantee, not a support commitment: spotforecast2-safe==18.1.0 receives no patches.

Security Features & Design Goals

spotforecast2-safe is designed with security in mind.

Zero dead code

  • No GUI components, plotting libraries, or AutoML frameworks
  • Minimal external dependencies
  • Reduced attack surface for supply chain security

Deterministic operations

  • All transformations are bit-level reproducible
  • Predictable behaviour enables auditing
  • No hidden randomness or stochastic operations

Fail-safe processing

  • All transformations validate input data
  • Invalid data raises explicit errors
  • No silent failures or data imputation
  • NaN and Inf values are rejected immediately

Audit-log integrity

  • Every audit-log record after the first carries prev_hash, the SHA-256 of the previous record’s exact bytes; the first record of a file carries the genesis value of 64 zeros
  • The chain is per file and unkeyed: it proves a retained file was not edited, deleted, reordered, or torn after the fact, not who wrote it
  • Verify a file offline with spotforecast2_safe.manager.verify_audit_log, which recomputes the chain and reports the first broken line, and, when given an externally witnessed AuditAnchor, whether the file’s current chain still extends that witnessed state
  • A verification result never prints an unqualified pass: AuditChainReport names what it could not establish (unestablished) alongside what it could, and a run presented with no anchor explicitly says so rather than defaulting to success
  • Anchoring is tooled but still operator-executed: make anchor / make anchor-verify (see the Anchoring Runbook) automate the RFC 3161 handshake around an independently controlled witness for the resulting head hash — so that even a wholesale rewrite of the file is detectable — but the package performs no network I/O itself and the decision to run them, on which logs, how often, remains the operator’s

Minimal dependencies

Runtime dependencies are deliberately few, to keep the CVE surface small. The authoritative list is the dependencies array in pyproject.toml; at the time of writing it comprises astral, feature-engine, holidays, lightgbm, numba, pandas, pyarrow, requests, scikit-learn, scipy, statsmodels, and tqdm. A test in the suite fails the build if any of plotly, matplotlib, spotoptim, optuna, torch, or tensorflow enters the resolved dependency closure.

Security Best Practices for Users

Using the current version

  1. Always use the latest available version from PyPI
  2. Review CHANGELOG.md for security patches
  3. Watch the project repository for new releases

Production deployment

  1. Pin exact versions in requirements.txt or pyproject.toml
  2. Use virtual environments
  3. Keep dependencies updated
  4. Review the Model/Method Card for safety-critical considerations

Development

  1. Clone only from the official repository
  2. Install the pre-commit hooks
  3. Run make verify before every push

Dependency Management

To check for known vulnerabilities in your own environment:

uv run safety check
uv run bandit -r src/spotforecast2_safe/

Dependencies use compatible release specifiers, allowing patch updates while preventing breaking changes:

dependency>=1.2.3,<2.0

Software bill of materials

make sbom exports a CycloneDX 1.5 SBOM of the resolved production dependency graph from uv.lock and injects the project’s own CPE 2.3 identifier onto the root component, so NVD-backed scanners can resolve it. The result is written to artifacts/sbom.cdx.json. The SBOM is generated on demand rather than attached to each release.

Quality Assurance

Quality assurance runs locally. There is no hosted continuous-integration service: the Makefile at the repository root is the whole pipeline, and make verify is the gate that runs before every push. It performs:

  1. REUSE compliance — SPDX license header verification for every file
  2. Prohibited-dependency scan — fails if a forbidden package resolves in uv.lock
  3. API reference sync — fails if the generated docs/reference/ pages are stale, or if a public symbol is undocumented
  4. Code quality — black, isort and ruff; ty runs non-blocking
  5. Test coverage — pytest against the floor configured in [tool.coverage.report]

RELEASING.md documents the release process in full.

What is not provided

This project was previously built by GitHub Actions. That automation ended when the repository moved to GitLab, and the guarantees it produced ended with it. They are listed here so that no reader infers them:

  • No Sigstore signatures. Releases before the migration carry keyless Sigstore bundles and Rekor transparency-log entries; releases after it do not. Keyless signing requires a CI OIDC identity that does not exist on a workstation.
  • No CodeQL or OpenSSF Scorecard scanning, and no badges reporting either.
  • No hosted coverage reporting. Coverage is still enforced, locally, by the fail_under setting in [tool.coverage.report].
  • No independent clean-room build. Tests execute only on the maintainer’s machine. See “Verification environment” in the Model/Method Card.
  • No enforced pre-merge gates. make verify is a convention that a maintainer can skip, not a branch protection rule.
  • No keyed MAC on the audit-log hash chain, still. It detects edits, deletions, and reordering within a file, but an adversary who can rewrite the whole file can recompute it; the chain is, and remains, unkeyed evidence of file integrity, not of authorship.
  • Timestamping and external witnessing exist now, but as an operator-run make target, not a library feature. make anchor / make anchor-verify (see the Anchoring Runbook) drive an RFC 3161 handshake to bind head_hash to an independently controlled record — analogous to the Article 18 retention duty — but nothing in spotforecast2_safe performs network I/O on its own, and whether, on which logs, and how often to anchor remains entirely the operator’s decision.

Users with stricter assurance requirements should run the verification steps in Section 12 of the Model/Method Card in their own environment.

Compliance Standards

spotforecast2-safe supports the following:

  • REUSE compliant — all files carry SPDX license identifiers, verified by uv run reuse lint
  • SPDX — standards-based license tracking
  • EU AI Act ready — support for compliance via the Model/Method Card
  • CycloneDX 1.5 SBOM — on demand via make sbom, with CPE 2.3 identifiers
  • Tamper-evident, anchoring-aware audit logs — a per-file SHA-256 hash chain, verifiable offline with verify_audit_log, which reports anchoring status explicitly against an optional, operator-obtained AuditAnchor (RFC 3161 timestamp or otherwise); see the Anchoring Runbook
  • Python 3.13+ — requires a current Python release for upstream security patches

Contact

See Also

  • Model/Method Card — system design and compliance documentation
  • CHANGELOG.md — release notes and security patches
  • RELEASING.md — how releases are built and published