[appleboy]

Summary

Pin the patched upstream Lambda image by immutable digest and update vulnerable example Go dependencies. Align the example CI and README with Go 1.26, and restrict live deployments to master.

Related issues

N/A — repository-wide Trivy audit requested; no issue identifiers supplied.

AI authorship

• AI was used
• Tool / model: OpenAI Codex
• AI-authored files: entrypoint.sh, .github/workflows/ci.yml, Dockerfile, README.md, example/go.mod, example/go.sum
• Human line-by-line reviewed: None — not yet reviewed by a human.

Change classification

Core: action runtime changes affect consuming workflows; request two reviewers including the owner.

Plan reference

Restore the existing Trivy gate, preserve action inputs/entrypoint behavior, and verify before committing. Do not lower vulnerability severities or ignore CVEs.

Compatibility and scan-policy verification

Network-disabled amd64 debug parsing confirms empty layers/architectures become empty lists and six explicit list values remain intact. No AWS operations performed.

Verification

Checkout fix/trivy-security-scan at 2784329de6b7edce3d672d8248b3a17c3cd5b307 and run from lambda-action/. Prerequisites: Trivy 0.69.3 with the current vulnerability DB, Docker with linux/amd64 support, Go 1.26+, actionlint for modified workflows. Local commands were wrapped with rtk; Docker ran in Colima. No service credentials needed.

Command	Status	Observed result
trivy fs --scanners vuln,secret --severity CRITICAL,HIGH --exit-code 1 .	Passed	No findings at the configured severity after the fix.
git diff --check master...HEAD	Passed	No whitespace errors.
docker build --platform linux/amd64 -t lambda-action:trivy-fix .	Passed	Image built in local Colima Docker.
trivy image --scanners vuln --severity CRITICAL --exit-code 1 lambda-action:trivy-fix	Passed	0 CRITICAL; local image was exported with docker save and scanned using --input. Existing CI still reports HIGH via SARIF.
docker run --rm --platform linux/amd64 --entrypoint /bin/drone-lambda lambda-action:trivy-fix --help	Passed	Expected executable and CLI options available.
cd example && go test ./...	Passed	Example compiles on Go 1.26.7; package has no test files.
actionlint .github/workflows/ci.yml	Passed	Updated Go matrix and default-branch filter valid.

Behavioral scenario

Run the filesystem scan above; expect exit 0. Build and scan the image with the commands above; expect exit 0 and zero CRITICAL vulnerabilities. Run CLI help without credentials; expect usage output without contacting a service.

Execution status: Passed locally. GitHub PR checks will independently run after creation; no hosted result is claimed here. Live notification/deployment checks were not run because they affect external services.

Cleanup: docker image rm lambda-action:trivy-fix removes the test image.

Security check

No credentials in the diff. Existing scan severities remain intact. No vulnerability exceptions added.

Risk and rollback

Upstream runtime/dependency upgrades may affect service integration; review compatibility before merging. Revert this commit to restore the previous image and configuration.

Reviewer guide

Review .github/workflows/ci.yml, Dockerfile, README.md, example/go.mod, example/go.sum. Confirm the Trivy PR jobs finish successfully and review any remaining HIGH findings in uploaded SARIF. Service integration requires owner review in a disposable environment.

Hosted verification

Trivy Security Scan passed at 2784329de6b7edce3d672d8248b3a17c3cd5b307: https://github.com/appleboy/lambda-action/actions/runs/37485829797

[dajiaohuang]

AI-assisted source review found a separate documentation issue in the README's AWS Policy example: it grants s3:PutObject and iam:ListRoles on the Lambda function ARN. That ARN cannot authorize an S3 object write, and iam:ListRoles requires Resource: "*"; the statements should be split so S3 targets the configured object ARN, IAM uses *, and Lambda operations retain the function ARN. AWS references: https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html and https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentityandaccessmanagementiam.html .

This is unrelated to PR #88's image/dependency changes. I prepared a local README correction, but did not push a branch or run the action: the current workflow triggers on every push and its steps deploy using AWS_* secrets. I will not trigger that real AWS deployment path. PR #88's proposed master-only push filter may remove branch-push deployments once merged.