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

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

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

Production deployment

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

Development

Clone only from the official repository
Install the pre-commit hooks
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:

REUSE compliance — SPDX license header verification for every file
Prohibited-dependency scan — fails if a forbidden package resolves in uv.lock
API reference sync — fails if the generated docs/reference/ pages are stale, or if a public symbol is undocumented
Code quality — black, isort and ruff; ty runs non-blocking
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.

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
Python 3.13+ — requires a current Python release for upstream security patches

Contact

Vulnerability reports: thomas.bartz-beielstein@th-koeln.de, or a confidential issue in the project repository
General inquiries: https://gitlab.git.nrw/thk-f10/spotsevenlab/spotforecast2-safe