arm-dev-env is a rolling development image, built on demand from main; it is not published as versioned or tagged artefacts. Security fixes always land on main, and consumers pick them up by rebuilding the image.

This repository builds a Docker image that bundles a cross-compilation toolchain (CMake, Ninja, the arm-none-eabi GNU toolchain, Task, LLVM FileCheck, Git) on a Debian base. It contains no application code of its own. A vulnerability in this context typically means one of:

1. Supply-chain compromise. The Dockerfile downloads pre-built binaries from third-party release servers (GitHub, developer.arm.com). A weakness in how those downloads are version-pinned or integrity-checked — one that could let an attacker substitute a malicious binary — is the most serious class of issue here.
2. A vulnerable bundled component. A CVE in the base image or one of the bundled tools that materially affects users of the image. The CI Validation workflow runs a Trivy scan on every build and reports findings to the repository's Security tab; informational CVE noise from that scan is not, by itself, a vulnerability in this repository.
3. Build-time information disclosure. The build leaking secrets (for example via build args or logs) into the published image layers.

If you believe you've found something matching one of those, please report it privately as described below.

Please do NOT report security vulnerabilities through public GitHub issues.

1. Preferred: use GitHub Security Advisories to report the vulnerability privately.

2. Alternative: email the maintainer directly at matejg03@gmail.com.

When reporting, please include:

• A clear description of the vulnerability and the conditions that trigger it.
• Steps to reproduce — including the exact base image / tool version involved and the repository commit you built from.
• Potential impact assessment.
• Any suggested fix or mitigation (optional but appreciated).

1. Acknowledgement. We will acknowledge receipt of your report within 48 hours.

2. Communication. We will keep you informed of our progress and may ask for additional information.

3. Credit. Unless you prefer to remain anonymous, we will credit you in the security advisory and release notes.

4. Disclosure. We follow responsible disclosure practices. We ask that you give us reasonable time to address the issue before any public disclosure.

This security policy was last updated on 2026-06-19.