Security, Safety, and Release Integrity

On this page

• Reporting a Vulnerability
• What Is In Scope
• Supported Versions For Security Fixes
• How Official Releases Are Produced
• How To Verify A Release
• Operational Continuity
• Coordinated Disclosure
• Safe Harbor

This page covers software security, vulnerability handling, and release trust for Albumentations itself. It does not cover model-level safety, dataset policy, or augmentation choices for safety-critical ML deployments.

For licensing, see the License Guide. For a broader technical comparison against the legacy albumentations package, see AlbumentationsX vs Legacy Albumentations: Practical Benefits.

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 repository 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 vladimir@albumentations.ai 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 open-source Albumentations 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:

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

How Official Releases Are Produced

Official releases are produced from the AlbumentationsX repository, built in GitHub Actions from tagged source, and published to PyPI through trusted publishing. The release workflow validates that the GitHub release tag matches project.version in pyproject.toml, builds artifacts in CI, and publishes them without relying on long-lived maintainer-managed PyPI API tokens.

Albucore, the low-level image operation library that Albumentations depends on, uses the same release process in its own repository.

Each official release publishes:

• source distribution (sdist)
• wheel
• SHA256SUMS.txt
• CycloneDX SBOM in JSON format
• PyPI provenance/attestation generated by trusted publishing

Before publication, the release workflow performs checks that include:

• twine check on built distributions
• clean-environment wheel installation
• import albumentations from outside the repository checkout
• lockfile consistency validation with uv lock --check against the committed uv.lock
• export of locked runtime dependencies from uv.lock

This gives downstream users concrete artifacts to inspect instead of asking them to trust an opaque local upload process.

How To Verify A Release

Release verification is based on three things:

1. GitHub Release assets are the canonical public release bundle.
2. PyPI publishes the same wheel and sdist via trusted publishing.
3. PyPI provenance/attestations bind the uploaded package files to the GitHub Actions workflow that produced them.

To verify a release as a downstream user:

1. Download the release assets from GitHub.
2. Run:

sha256sum -c SHA256SUMS.txt

3. Confirm the wheel and sdist checksums match the manifest.
4. Confirm the same version exists on PyPI.
5. 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

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: vladimir@albumentations.ai

Escalation happens when any of the following are true:

• a suspected vulnerability affects supported versions
• release verification fails for a tagged release
• the release workflow fails after a public 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.

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.