Add acli (Atlassian CLI) to sandbox image

[guyoron1]

Adds acli to the base sandbox image so agents can query Jira natively.

Closes #1248

[fullsend-ai-review]

Review

No findings.

Previous run

Review

Findings

Low

• [supply-chain] images/sandbox/Containerfile:181 — The download URL uses a floating latest path segment (https://acli.atlassian.com/linux/latest/…) without an explicit ACLI_VERSION build argument. The per-architecture SHA256 checksums added in this revision fully mitigate the binary substitution risk flagged in the prior review — builds will now fail deterministically if the upstream binary changes. However, unlike every other versioned tool in this Containerfile (ORT, gitleaks, tirith), there is no version ARG, so there is no way to audit which acli release is installed, and upstream updates will break builds silently rather than being tracked as intentional version bumps. If acli.atlassian.com supports version-specific download paths, adding ARG ACLI_VERSION would bring acli in line with the other tools. If it does not, the current SHA256-pinned approach is the correct mitigation and the supply chain table entry in images/README.md accurately reflects this.
  Remediation: If the acli download server supports versioned URLs, add ARG ACLI_VERSION and use it in the URL path. If not, add a comment above the acli section noting that the SHA256 checksums serve as the version pin because the upstream distribution only offers a latest endpoint.

Previous run

Review

Findings

Low

• [supply-chain] images/sandbox/Containerfile:181 — The download URL uses a floating latest path segment (https://acli.atlassian.com/linux/latest/…) without an explicit ACLI_VERSION build argument. The per-architecture SHA256 checksums added in this revision fully mitigate the binary substitution risk flagged in the prior review — builds will now fail deterministically if the upstream binary changes. However, unlike every other versioned tool in this Containerfile (ORT, gitleaks, tirith), there is no version ARG, so there is no way to audit which acli release is installed, and upstream updates will break builds silently rather than being tracked as intentional version bumps. If acli.atlassian.com supports version-specific download paths, adding ARG ACLI_VERSION would bring acli in line with the other tools. If it does not, the current SHA256-pinned approach is the correct mitigation and the supply chain table entry in images/README.md accurately reflects this.
  Remediation: If the acli download server supports versioned URLs, add ARG ACLI_VERSION and use it in the URL path. If not, add a comment above the acli section noting that the SHA256 checksums serve as the version pin because the upstream distribution only offers a latest endpoint.

Previous run (2)

Review

Findings

High

• [supply-chain] images/sandbox/Containerfile:175 — The acli binary is downloaded from a floating latest URL (https://acli.atlassian.com/linux/latest/…) with no SHA256 checksum verification. Every other binary in this Containerfile pins an explicit version and verifies integrity via sha256sum -c. The supply chain security section of images/README.md states the invariant: "Every binary downloaded during the build is version-pinned and SHA256-verified per architecture." Using a latest tag makes builds non-reproducible and exposes the supply chain to silent substitution — a compromised or MITM'd upstream would result in arbitrary code execution as root during image build.
  Remediation: Pin a specific acli version in the URL path, add ARG ACLI_VERSION and ARG ACLI_SHA256_{AMD64,ARM64} build arguments, and verify the download with echo "${ACLI_SHA} /usr/local/bin/acli" | sha256sum -c -, following the pattern used by gitleaks, tirith, and ONNX Runtime in this file.

Medium

• [correctness] images/sandbox/Containerfile:175 — No architecture validation for $TARGETARCH. Every other tool installation in this Containerfile validates the architecture via a case "$TARGETARCH" in amd64|arm64) block, mapping values where needed and failing explicitly for unsupported architectures. The acli install passes $TARGETARCH directly into the URL without validation. If acli.atlassian.com expects different architecture identifiers or an unsupported architecture is used, the build fails with an opaque curl error rather than a descriptive message.
  Remediation: Add a case "$TARGETARCH" block consistent with the other tool installations. This also enables architecture-specific SHA256 checksums once version pinning is added.

• [docs-currency] images/README.md:17 — The base sandbox image tool inventory does not include acli. The supply chain security table (lines 100–111) also needs an entry documenting acli's pinning and verification method. Both must be updated to keep the documentation accurate.
  Remediation: Add acli to the tool list in the image description table and add a row to the supply chain security table.

Low

• [docs-currency] images/sandbox/Containerfile:1 — The Containerfile header comment (lines 1–13) lists all pre-installed runtime dependencies but does not mention acli. This header serves as a quick reference for what the image contains.
  Remediation: Add an acli entry to the header comment list.

[fullsend-ai-review]

[low] supply-chain

The download URL uses a floating latest path segment without an explicit ACLI_VERSION build argument. SHA256 checksums mitigate binary substitution, but there is no version ARG for auditability and upstream updates will break builds silently.

Suggested fix: If the acli download server supports versioned URLs, add ARG ACLI_VERSION and use it in the URL path. If not, add a comment noting that SHA256 checksums serve as the version pin because the upstream distribution only offers a latest endpoint.

[ralphbean]

Yeah, I agree with this. Does atlassian provide versioned urls?

As this currently stands (with /latest/ in the url), then when atlassian releases a new version, all of our image builds will suddenly break on our main branch because the digest doesn't match anymore.

We want to do digest checking.

Can you revise this to use a url that includes a version number so that we don't "automatically" update when atlassian puts out a new cli?

[ralphbean]

Yeah, I agree with this. Does atlassian provide versioned urls?

As this currently stands (with /latest/ in the url), then when atlassian releases a new version, all of our image builds will suddenly break on our main branch because the digest doesn't match anymore.

We want to do digest checking.

Can you revise this to use a url that includes a version number so that we don't "automatically" update when atlassian puts out a new cli?

[ralphbean]

/fs-retro take a look at inline PR feedback I provided above. A change that would break CI on main arbitrarily in the future isn't acceptable. What should we change to make it more obvious to the review agent that it should treat situations like that as a high priority finding?

[maruiz93]

Thank you for the PR. I appreciate it as I didn't know what was the best atlassian CLI if the official one or not. I agree with the other reviewers (@ralphbean and the agent). I just did a quick search and in the atlassian docs I only see the reference to the latest version and it seems others have already complained about this: https://community.atlassian.com/forums/DevOps-discussions/acli-versioned-download/td-p/3116576

For the timebeing, I suggest composing the url with version v1.3.15-stable (this is the changelog)

[gklein]

@guyoron1 For now we can pin it to the the latest version marked stable by Atlassian. e.g.:

ARG ACLI_VERSION=1.3.18-stable
RUN curl -fsSL \
        "https://acli.atlassian.com/linux/${ACLI_VERSION}/acli_${ACLI_VERSION}_linux_${TARGETARCH}.tar.gz" \
        -o /tmp/acli.tar.gz

See more details at the Atlassian brew formula for acli

[guyoron1]

Thanks @gklein and @maruiz93 for the feedback. Updated in the latest push — acli is now pinned to 1.3.18-stable with versioned URL and updated SHA256 checksums.