fix(lambda-nodejs): use official bun installer for ARM64 compatibility

[dsilbergleithcu-godaddy]

Description

Fixes Docker bundling failures when using bun on ARM64 architectures (AWS Graviton instances).

Problem

The current Dockerfile uses npm install --global bun@1.1.30 which fails on ARM64 because the npm package @oven/bun-linux-x64-baseline doesn't exist for ARM64 architecture.

Solution

Replace npm-based installation with the official bun installer that automatically detects and downloads the correct platform binary.

Changes

• Replace RUN npm install --global bun@1.1.30
• With RUN curl -fsSL https://bun.sh/install | bash -s "bun-v1.1.30" && ln -s /root/.bun/bin/bun /usr/local/bin/bun
• Added explanatory comments

Security Considerations

⚠️ Supply Chain Risk: This change introduces an additional external dependency (bun.sh) in the build process. While this follows bun's official installation method and doesn't necessarily increase overall risk compared to npm registry dependencies, it does change our security posture by adding another potential attack vector. The bun.sh domain could theoretically be compromised to serve malicious installers.

Risk Mitigation Options (for future consideration):

• Pin to specific commit hash of the install script
• Download and vendor the installer script
• Use checksum verification

Testing

• ✅ Verified on AWS Graviton instance (GitHub Actions)
• ✅ Maintains compatibility with existing x64 builds

Closes #35534

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter fails with the following errors:

❌ Fixes must contain a change to a test file.
❌ Fixes must contain a change to an integration test file and the resulting snapshot.

If you believe this pull request should receive an exemption, please comment and provide a justification. A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed, add Clarification Request to a comment.

[dsilbergleithcu-godaddy]

I actually don't want to change the tests at all. Ideally the tests should all run exactly as they are and should pass. We shouldn't really care what the source of the bun package is, but as long as it's installed then our test suite should prove that bun still works. Riiiiight? :)

[pahud]

Consider Security Hardening like this as the external dependency (bun.sh) might be a security concern?

# Alternative with checksum verification (future enhancement)
RUN curl -fsSL https://bun.sh/install -o /tmp/install.sh && \
    echo "expected_checksum /tmp/install.sh" | sha256sum -c && \
    bash /tmp/install.sh "bun-v1.1.30" && \
    ln -s /root/.bun/bin/bun /usr/local/bin/bun && \
    rm /tmp/install.sh

[dsilbergleithcu-godaddy]

Hey @pahud, this is a good call. I'm DEFINITELY concerned about the security implications of this change and the risk of supply chain poisoning. Let me try this out and update the PR if it all works

[dsilbergleithcu-godaddy]

Ug. The trouble here is that your suggestion (which is good) verifies the installer hasn't changed. We likely want to do that... but we also likely want to confirm the sha hash on the downloaded binary... which is significantly harder.

The hashes are available on github (yay) but the installer doesn't have a way to check them during installation or confirm them before install. And in looking over bun's installer docs I don't see anything that shows a way to do installation of the package without the installer. So downloading the correct binary, validating it, and installing it, is challenging. Though likely a good idea.

[dsilbergleithcu-godaddy]

I'm not sure what to do here. A breaking change was introduced in a feature that we don't need (we don't even use bun). It wasn't well tested and CDK does not do semver, so there was no warning.

My instinct here is to rip bun out or make it optional in some way as there isn't a secure way to solve this problem, and I don't need the feature. But that's selfish and not helpful to people who DO need this feature.

I defer to you for guidance @pahud. What do you think is a correct forward path? I want to make sure we're being secure here, especially given the potential blast radius of a compromise.

I think the most robust solution would be to pull the package we need from github, validate the sha against a known good sha, and then install it. But that installation will require additional manual steps and perhaps recreation of the bun installer script. Yuck.

[dsilbergleithcu-godaddy]

I'm Closing this PR in favor of one which bumps the package version of Bun to the latest. It appears there is a proper version released for the newer version. Assuming that bun follows proper semver, then there should be no reason to think that this upgrade won't behave as expected.

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.