Update dependency python to v3.15.0

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
python	uses-with	minor	3.14 → 3.15
python (source)	final	minor	3.14.8-alpine3.24 → 3.15.0-alpine3.24

---

Release Notes

actions/python-versions (python)

v3.15.0: 3.15.0

Compare Source

Python 3.15.0

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[fossabot]

✓ Safe, No Significant Changes Detected

This PR updates dependencies, but no changes were found in the release notes or changelogs.

Dependencies analyzed:

• python 3.14 → 3.15
• python 3.14.8-alpine3.24 → 3.15.0-alpine3.24

---

fossabot skipped detailed analysis because no significant changes were detected.

[fossabot]

[fossabot]

[fossabot]

Needs Review

The scan of the changed Dockerfile identified 2 findings, both related to image pinning and reproducibility rather than direct exploitable vulnerabilities. There are no critical or high severity security issues in this PR. The findings reflect supply chain security best practices that, if left unaddressed, could introduce risk through unpredictable or tampered base images.

Risk Assessment

Low overall risk. Neither finding represents an immediately exploitable vulnerability. The medium severity finding flags that FROM init AS production (line 117) references an internal multi-stage build alias without an explicit external version tag, though init itself is derived from a tagged image (python:3.15.0-alpine3.24). The low severity finding flags that the base image on line 2 is pinned to a version tag but not to an immutable SHA digest. The practical risk is supply chain integrity: if the upstream image tag is ever overwritten (intentionally or via a compromised registry), builds could silently pull a different, potentially malicious image. Exploitability requires either a compromised upstream registry or a man-in-the-middle scenario, making real-world impact moderate but not negligible for a production image.

Recommendations

• Pin the base image on line 2 to a specific SHA256 digest (e.g., FROM python:3.15.0-alpine3.24@​sha256:<digest> AS init) to ensure fully reproducible and tamper-evident builds — use docker buildx imagetools inspect python:3.15.0-alpine3.24 to retrieve the digest.
• Consider suppressing or documenting the medium finding on line 117, as FROM init AS production is an internal multi-stage build alias and not a direct registry pull — its version is already governed by the pinned init stage on line 2. Add an inline suppression comment if your SAST tooling supports it, to reduce noise in future scans.
• Adopt a dependency update tool (e.g., Renovate or Dependabot) configured to automatically update and re-pin base image digests, so reproducibility is maintained as upstream images are patched for CVEs.

Findings

2 issues across 1 file.

Medium

Show 1 medium findings

Dockerfile:117
Detected docker image with no explicit version attached. Images should be tagged with an explicit version to produce deterministic container images -- attach a version when using FROM <image>.
_{Rule: dockerfile.best-practice.missing-image-version}

Low/Info

Show 1 low/info findings

Dockerfile:2
To ensure reproducible builds, pin Dockerfile FROM commands to a specific hash. You can find the hash by running docker pull python and then specify it with python:3.15.0-alpine3.24@​sha256:<hash goes here>
_{Rule: dockerfile.audit.dockerfile-source-not-pinned}

---

fossabot analyzed this PR using SAST security analysis, impact analysis and AI (changed files only).

[fossabot]

Security Finding: Low/Info

To ensure reproducible builds, pin Dockerfile FROM commands to a specific hash. You can find the hash by running docker pull python and then specify it with python:3.15.0-alpine3.24@​sha256:<hash goes here>

_{Rule: dockerfile.audit.dockerfile-source-not-pinned}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (1a598fd) to head (97bd4df).

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #996   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files          106       106           
  Lines         1884      1884           
  Branches       311       311           
=========================================
  Hits          1884      1884           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[fossabot]

[renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

[fossabot]

Needs Review

The scan of the changed Dockerfile identified 2 findings, both related to image pinning and versioning in the build pipeline rather than application-layer vulnerabilities. No critical or high severity issues were found. These findings primarily affect build reproducibility and supply chain integrity.

Risk Assessment

Low overall risk. Neither finding represents a directly exploitable vulnerability in the traditional sense. The medium-severity finding (line 117) flags FROM init AS production, where init is a locally defined multi-stage build alias — the SAST tool does not recognize it as a local stage and treats it as an untagged external image. The actual base image (python:3.15.0-alpine3.24) is properly tagged at line 2. The low-severity finding at line 2 highlights a legitimate supply chain risk: using a mutable image tag (even a specific version like 3.15.0-alpine3.24) rather than an immutable SHA256 digest means that if the upstream registry image were tampered with or accidentally overwritten, a rebuild could silently pull a different image. Exploitability requires a compromised or malicious upstream registry, which is a realistic but non-trivial attack vector.

Recommendations

• Pin the base image at line 2 to a specific SHA256 digest for full reproducibility and tamper-evidence — replace FROM python:3.15.0-alpine3.24 AS init with FROM python:3.15.0-alpine3.24@​sha256:<verified-hash> AS init. Use docker buildx imagetools inspect python:3.15.0-alpine3.24 to retrieve the correct digest.
• Review the medium-severity finding at line 117 (FROM init AS production) in context — init is a local multi-stage alias and not a missing-version external image pull. Consider adding an inline suppression comment (e.g., # nosemgrep or tool-equivalent) to document this intentional pattern and prevent future false-positive noise.
• Consider adopting a dependency update tool (e.g., Renovate or Dependabot) configured to automatically update both the image tag and its digest when new Python base images are released, maintaining pinned digests without manual overhead.

Findings

2 issues across 1 file.

Medium

Show 1 medium findings

Dockerfile:117
Detected docker image with no explicit version attached. Images should be tagged with an explicit version to produce deterministic container images -- attach a version when using FROM <image>.
_{Rule: dockerfile.best-practice.missing-image-version}

Low/Info

Show 1 low/info findings

Dockerfile:2
To ensure reproducible builds, pin Dockerfile FROM commands to a specific hash. You can find the hash by running docker pull python and then specify it with python:3.15.0-alpine3.24@​sha256:<hash goes here>
_{Rule: dockerfile.audit.dockerfile-source-not-pinned}

---

fossabot analyzed this PR using SAST security analysis, impact analysis and AI (changed files only).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud