Security, Safety, and Release Integrity

Reporting a Vulnerability

Albumentations takes security reports seriously. Please report suspected vulnerabilities privately so users have time to update before details are disclosed publicly.

Use GitHub private vulnerability reporting for the repository whenever possible:

Open the AlbumentationsX Security tab.
Use Report a vulnerability.
Include a minimal reproduction, affected version, impact, and any proposed fix or mitigation.

If GitHub private reporting is unavailable, email [email protected] with the subject line AlbumentationsX security report.

Do not open public GitHub issues for suspected unpatched vulnerabilities.

What Is In Scope

This policy covers vulnerabilities in code, packaging, release automation, or project-controlled infrastructure for the AlbumentationsX distribution, including:

Python package contents published from the official repository
GitHub Actions release and packaging workflows
project-maintained metadata, manifests, and release artifacts

The following are generally out of scope unless they create a project-controlled exploit path:

vulnerabilities in third-party dependencies with no Albumentations-specific exposure
security issues in downstream applications that only use Albumentations as a dependency
misconfiguration of user environments outside project-controlled releases

Supported Versions For Security Fixes

Albumentations uses the following support policy for security fixes:

Version line	Security support
Latest stable minor release line	Supported
Previous stable minor release line	Best effort for high-severity issues
Older releases	Not supported

If a fix is not backported, the remediation path is to upgrade to the latest supported release.

How Official Releases Are Produced

A pull request that increases the library version builds and verifies the final release bundle in GitHub Actions. When the matching GitHub Release is published, the delivery workflow verifies the bundle against the released source tree and publishes the same wheel and source distribution to GitHub and PyPI through trusted publishing.

The release process describes the checks and delivery steps. The release preflight includes:

package metadata and license-notice validation
clean-environment wheel installation and import outside the repository checkout
lockfile consistency and runtime dependency auditing
regression, property, and performance checks
GitHub Actions workflow auditing
SBOM, compatibility report, checksum, and release-manifest generation

Each release publishes these assets:

source distribution (sdist) and wheel
SHA256SUMS.txt
CycloneDX SBOM in JSON format
Correctness & Compatibility Report in Markdown format

PyPI also provides trusted-publishing provenance for the uploaded distributions. The release manifest connects the verified files to the reviewed source tree; the publishing workflow delivers those files without rebuilding them.

How To Verify A Release

Release verification connects the reviewed source, release assets, and publishing identity:

The version-bump pull request builds and verifies the release bundle.
The bundle manifest binds its files to the reviewed source tree.
GitHub Release assets and PyPI receive the same verified wheel and sdist.
PyPI provenance binds the uploaded distributions to the trusted delivery workflow.

To verify a release as a downstream user:

Download the release assets from GitHub.
Run:

sha256sum -c SHA256SUMS.txt

Confirm the wheel and sdist checksums match the manifest.
Confirm the same version exists on PyPI.
Open the PyPI file details page for the wheel or sdist and confirm that:
- the file was published with trusted publishing
- attestation/provenance metadata is present
- the source repository and workflow identity match albumentations-team/AlbumentationsX

See the release verification guide for notice verification, provenance checks, and the Correctness & Compatibility Report.

The CycloneDX SBOM attached to each GitHub Release is a transparency artifact. It helps consumers inspect the locked runtime dependency set used for the release. The checksum manifest and PyPI provenance are the primary authenticity artifacts.

Operational Continuity

Albumentations keeps a minimal operational continuity baseline for release and security operations:

Primary maintainer and release owner: Vladimir Iglovikov
Backup release owner for continuity: Mikhail Druzhinin
Preferred security reporting path: GitHub private vulnerability reporting
Fallback contact: [email protected]

Escalation happens when any of the following are true:

a suspected vulnerability affects supported versions
release verification fails for a tagged release
release preflight fails during a version-bump pull request
release delivery fails after a public GitHub Release is published
a maintainer is unavailable during an active incident or scheduled release

In those cases, the project pauses promotion of the affected release and prefers the smallest safe fix and a patch release over an unreviewed broad change. The operational continuity document describes release ownership and escalation.

Coordinated Disclosure

Please keep reports private until a fix, mitigation, or advisory is ready.

Albumentations aims to:

acknowledge receipt within 5 business days
complete initial triage within 10 business days
provide a status update after triage, including severity and planned remediation path
publish a GitHub Security Advisory and/or release note after a fix or mitigation ships

Fix timelines depend on severity, exploitability, and maintainer availability. High-severity issues in supported releases take priority over feature work.

Safe Harbor

Good-faith security research intended to improve the project is welcome. Please avoid privacy violations, destructive testing, social engineering, and service disruption.