[venkata-stepsecurity]

Adds an INT Release workflow that publishes int builds of the agent to GHCR, so anyone can pull and test an int agent without cutting a release. Other agent repos already publish int builds on push to int; this does the same here, using GHCR as the registry.

The amd64 and arm64 tarballs (the same goreleaser releasers/int.yml build that int.yml runs) and a checksums.txt are pushed as an OCI artifact to ghcr.io/step-security/agent/agent-int:

Trigger	Tags
push to int	latest, <commit sha>
manual run (workflow_dispatch) on any branch	dev-<branch>, <commit sha>
PR to int whose title starts with debug (same-repo branches only)	pr-<number>, <commit sha>

The PR trigger lets you test a branch before merge. Manual runs only become available once this workflow is on the default branch.

Pull an int build:

oras pull ghcr.io/step-security/agent/agent-int:latest
sha256sum -c checksums.txt

The package is public, like the repo, so no login is needed. Without oras, the files can be fetched with curl through the registry API (anonymous token, then manifest, then blob).

Notes:

• On PRs the workflow checks out the PR head commit instead of the merge commit, so the artifact matches the SHA tag.
• int.yml is unchanged.

Tested on this PR (while titled debug: ...): run 40915708938 published agent-int:pr-506 and agent-int:<head sha>. Anonymous oras pull works, both checksums verify, and the amd64 binary embeds the head commit. The archive layout is the same as the GitHub release archives (agent, LICENSE, README.md).

[step-security-bot-int]

Please find StepSecurity AI-CodeWise code comments below.

Code Comments

.github/workflows/int-release.yml

• [High]Use GitHub's built-in authentication instead of storing PAT in .netrc file
  Storing the personal access token (PAT) in the .netrc file is a security risk as it may be exposed or leaked. GitHub Actions provide the GITHUB_TOKEN secret that can be used for authentication and automatically rotated, which is safer and follows GitHub recommended practice (https://docs.github.com/en/actions/security-guides/automatic-token-authentication). Remove the 'Configure .netrc' step and instead rely on '${{ secrets.GITHUB_TOKEN }}' for authentication for GitHub API and package operations. This might need adjusting how commands authenticate, avoiding manual .netrc config.
• [High]Pin action versions to specific commit SHAs or released tags
  Pinning GitHub Actions to floating tags such as 'latest' or branch names can introduce unexpected breaking changes when upstream actions update. It's recommended to pin actions to immutable commit SHAs or fixed release tags to ensure build reproducibility and security (https://docs.github.com/en/actions/using-workflows/reusing-workflows#sharing-workflows-using-github-repositories). All actions used (e.g., 'step-security/harden-runner@v2', 'actions/checkout@629c2d...', 'actions/setup-go@424fc8...') should reference fully pinned commit SHAs or stable version tags, avoiding mutable references like 'latest'. E.g., use 'actions/setup-go@v1.7.0' instead of 'version: latest' or commit SHA.
• [Medium]Use consistent and minimal permissions to adhere to least privilege principle
  The workflow requests 'permissions: read-all' at the top level which grants overly broad permissions. Best practices recommend assigning the least privileges necessary to jobs and steps to minimize risk (https://docs.github.com/en/actions/security-guides/automatic-token-authentication#understanding-the-permissions-for-the-github_token). Set 'permissions' at the workflow or job level to only what is required. For example, since the 'publish' job requires 'contents: read' and 'packages: write', limit permissions as such or remove 'read-all' from the workflow root unless necessary.
• [Medium]Sanitize branch names carefully and validate tag length
  Sanitizing branch names for tags should strictly conform to Docker tag restrictions. The current use of 'tr -c' with '[A-Za-z0-9_.-]' and truncation to 100 characters is good, but Docker tags support up to 128 characters. Also, consider more robust sanitation to avoid edge cases with unusual characters (https://docs.docker.com/engine/reference/commandline/tag/#extended-description). Increase the length limit to 128 characters, and ensure any invalid characters are replaced with '-' or removed. Consider adding validation to ensure tags conform strictly to Docker's tag regex.
• [Medium]Validate presence of variables before usage to avoid runtime errors
  The workflow assumes the presence of environment variables like 'github.event.pull_request.number' and 'github.event.pull_request.head.sha' which may be undefined in some event contexts, potentially leading to undesired tag names or errors (https://docs.github.com/en/actions/learn-github-actions/contexts). Add conditional checks or default values for these variables to avoid empty or invalid tag values when variables are absent.
• [Low]Use secure storage and usage of secrets
  The workflow uses 'secrets.PAT' but also has 'secrets.GITHUB_TOKEN'. Using two different tokens with overlapping scopes increases complexity and risk of token misuse (https://docs.github.com/en/actions/security-guides/encrypted-secrets). Consolidate authentication to use only 'GITHUB_TOKEN' unless there is a concrete reason for a personal access token. Ensure all secrets have minimal scopes and rotate tokens regularly.
• [Low]Add comments to clarify tag naming conventions
  The bash script block for tagging within 'Pick tags' step is somewhat complex and might be hard to maintain or extend without clear comments about each case. Add detailed comments explaining why each tag naming case is handled the way it is and constraints on the tags.
• [Low]Avoid using deprecated or outdated tools or versions
  Go version 1.27.3 is very recent and likely fine, but verify that the 'goreleaser' action version used is stable and recommended. Using the latest version tag or a specific SHA is better controlled. Check that 'goreleaser/goreleaser-action@5df302e...' corresponds to a stable release and not a custom commit. Prefer released versions or pinned SHAs.
• [Low]Store checksums and artifacts in dedicated directories
  The 'Prepare artifact' step creates an 'upload' directory in the workspace root. Ensuring artifacts and related files are stored in a dedicated directory preserves workspace cleanliness. Consider creating a dedicated folder for build artifacts outside the root if needed or clean up after workflow completion.
• [Low]Consistent naming for environment variables
  The environment variables defined in the workflow are sometimes all caps (e.g., IMAGE) and sometimes lower camel case (e.g., REVISION), which can affect readability and convention consistency (https://12factor.net/config). Use consistent uppercase with underscores for environment variables throughout the workflow.

Feedback

We appreciate your feedback in helping us improve the service! To provide feedback, please use emojis on this comment. If you find the comments helpful, give them a 👍. If they aren't useful, kindly express that with a 👎. If you have questions or detailed feedback, please create n GitHub issue in StepSecurity/AI-CodeWise.

[step-security-bot-int]

Please find StepSecurity AI-CodeWise code comments below.

Code Comments

.github/workflows/int-release.yml

• [High]Avoid storing sensitive credentials in plaintext files
  The workflow appends the GitHub PAT token into ~/.netrc file in plaintext which could be a security risk if the runner environment is compromised or if logs mistakenly expose the file. As per GitHub Actions security best practices (https://docs.github.com/en/actions/security-guides/encrypted-secrets), secrets should not be written to plaintext files or exposed beyond necessity. Modify the '.netrc' configuration step to set restrictive file permissions immediately after writing the file. For example, add 'chmod 600 ~/.netrc' after writing the credentials to restrict access. Alternatively, use GitHub Actions built-in authentication mechanisms that avoid storing tokens in files if supported.
• [High]Use least privilege principle for GitHub Actions permissions
  The workflow uses 'permissions: read-all' at the top level, granting broader permissions than necessary. According to GitHub best practices (https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token), permissions should be limited to only what the job needs to minimize security risks. Specify only the required permissions explicitly, e.g., 'contents: read' and 'packages: write' in the jobs that require those permissions, and remove or restrict 'read-all' at the workflow level.
• [Medium]Pin GitHub Action versions to specific and stable versions
  The workflow pins some actions to specific commit SHAs (good), but others use 'latest' or partial version names like 'v2' or commit SHAs that are not well-known releases. For example, 'actions/setup-go@424fc82d43fa5a37540bae62709ddcc23d9520d4' might be acceptable but 'goreleaser/goreleaser-action@5df302e5e9e4c66310a6b6493a8865b12c555af2' could be better pinned to a proper release tag. Using floating tags such as 'latest' is discouraged as per GitHub Actions guidelines (https://docs.github.com/en/actions/using-workflows/reusing-workflows#referencing-workflows). Pin actions to specific, tagged releases rather than commit SHAs or 'latest'. For example, change 'goreleaser/goreleaser-action' to use a stable release tag and avoid 'version: latest' for setup-go, instead specify the exact version.
• [Medium]Sanitize branch names used in image tags to prevent invalid characters and excessive length
  The workflow sanitizes branch names when creating tags using 'tr' and 'cut' to prevent invalid characters and limit length. However, the cutoff is at 100 characters whereas OCI image tag limits are stricter (max 128 characters and limited charset). Ensuring tags fully comply prevents push failures or inconsistencies. Docker tag rules (https://docs.docker.com/engine/reference/commandline/tag/#extended-description) should be followed strictly. Review and enforce stricter tag sanitization rules, ensure only allowed characters [a-zA-Z0-9_.-] and limit length to 128 characters. Prefer explicit validation and error handling if branch names are invalid.
• [Medium]Avoid using multiple environment variable expansions for the same values
  The workflow calculates SHA in multiple places as '${{ github.event.pull_request.head.sha || github.sha }}'. Repeating this expression increases maintenance overhead and risk of inconsistencies. DRY (Don't Repeat Yourself) principle is recommended as per software engineering best practices (https://martinfowler.com/bliki/Don_tRepeatYourself.html). Define a reusable environment variable or step output for the SHA once and reference it multiple times to avoid duplication and potential mismatches.
• [Low]Use explicit shell commands with error handling in scripts
  Several steps use raw shell scripts without explicit error checking (e.g., 'mkdir upload', 'cp' commands). Although the GitHub runner defaults to failing on errors, explicitly checking commands and handling errors improves reliability and diagnostics per shell scripting best practices (https://google.github.io/styleguide/shellguide.html). Add 'set -euo pipefail' at the top of shell script steps or check exit codes after critical commands to fail fast and show meaningful errors.
• [Low]Use the 'actions/setup-go@v3' stable release instead of commit SHA
  The workflow uses 'actions/setup-go@424fc82d43fa5a37540bae62709ddcc23d9520d4' pinning to a specific commit SHA. GitHub recommends using stable version tags to get updates and fixes more safely. Update usage to 'actions/setup-go@v3' or the latest stable release tag to benefit from patches and fixes while maintaining version stability.
• [Low]Validate the presence of required secrets before running the workflow
  The workflow uses the secret '${{ secrets.PAT }}' without checking if it is set, which could cause silent failures or security issues if missing. GitHub's recommended practice is to ensure all required secrets are configured before use (https://docs.github.com/en/actions/security-guides/encrypted-secrets). Add a preliminary step to verify the presence of required secrets and fail early with a clear message if they are missing.
• [Low]Add comments describing non-trivial script logic for maintainability
  Although the workflow is mostly well-commented, some shell scripts, especially the tag picking logic, could benefit from more detailed explanation about why certain branches are mapped to particular tag name patterns. Good documentation improves maintainability (https://google.github.io/eng-practices/review/developer/on-code-quality). Add more detailed comments in the tag selection step to clarify logic and allowed tag formats.

Feedback

We appreciate your feedback in helping us improve the service! To provide feedback, please use emojis on this comment. If you find the comments helpful, give them a 👍. If they aren't useful, kindly express that with a 👎. If you have questions or detailed feedback, please create n GitHub issue in StepSecurity/AI-CodeWise.

[step-security-bot-int]

Please find StepSecurity AI-CodeWise code comments below.

Code Comments

.github/workflows/int-release.yml

• [High]Securely manage secrets and avoid appending credentials to files in plaintext
  Appending the GitHub PAT token directly to ~/.netrc in plaintext can expose credentials if the runner's environment is accessed or logged improperly. According to GitHub Actions best practices (https://docs.github.com/en/actions/security-guides/encrypted-secrets), secrets should be injected and used without writing them to files unencrypted. Use the built-in GitHub token authentication mechanisms or GitHub Actions official authentication steps rather than writing secrets directly to ~/.netrc. If using .netrc is necessary, ensure the file has strict permissions (e.g., chmod 600) and is deleted after use to minimize exposure. Alternatively, use environment variables or GitHub's login mechanisms to authenticate without writing secrets in files.
• [High]Pin actions versions properly to avoid unexpected changes
  The workflow uses commit SHAs for some actions but 'latest' or loose tags for others (e.g., 'actions/setup-go@424fc82d43fa5a37540bae62709ddcc23d9520d4' which is okay, but 'goreleaser/goreleaser-action@5df302e5e9e4c66310a6b6493a8865b12c555af2' mixes a SHA with 'latest' for the version input). Using 'latest' or unpinned versions can cause builds to break or introduce vulnerabilities unexpectedly. Best practices from GitHub Actions documentation recommend pinning versions to exact SHAs or semver tags (https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#using-third-party-actions). Pin all third-party GitHub actions and tools versions explicitly, ideally with SHA hashes or specific semver versions instead of 'latest' in inputs. For goreleaser-action, specify the version explicitly without 'latest'.
• [Medium]Use explicit and secure permissions for jobs and steps
  The job requests 'permissions: read-all' globally but then sets 'contents: read' and 'packages: write' at the job level. Minimizing permissions follows the principle of least privilege (https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token). Remove 'permissions: read-all' at the workflow level and explicitly assign the minimal required permissions at the job level. For example, grant only 'contents: read' and 'packages: write' where necessary.
• [Medium]Avoid unconstrained concurrency group keys that can cause unnecessary cancels
  The concurrency group uses '${{ github.workflow }}-${{ github.ref }}', which can create many unique groups if refs are branches, tags, or PR refs. This can cause unexpected cancels or missed concurrency if not carefully managed (https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency). Refine the concurrency group to better scope to meaningful units, e.g., limit to branch or PR number in pull requests and branch name for pushes, ensuring that workflows cancel only conflicting concurrent runs.
• [Medium]Reduce potential race-conditions or mismatches in ref versus commit SHA refs
  Setting the ref in checkout to 'github.event.pull_request.head.sha || github.sha' is good to build the PR head commit. However, this conditional might fail if event types or data are absent or malformed, potentially fetching the wrong commit. Add validation or fallbacks to ensure 'ref' is always valid, perhaps incorporating default branches or commit refs. Alternatively, rely on the default checkout behavior for PRs unless there is a compelling reason.
• [Low]Sanitize branch names more robustly when creating tags
  The tag sanitization uses 'tr -c 'A-Za-z0-9_.-' '-' | cut -c1-100' but does not handle unicode or other special characters well. Git tag naming conventions allow broader sets but restricting too strictly may cause collisions. Consider using a safer branch name sanitizer or encoding method (e.g., URL encoding or base64) to avoid tag conflicts or truncation issues, consistent with OCI tag name rules.
• [Low]Use 'actions/checkout@v3' or latest stable release instead of a specific commit sha
  Pinning to a SHA like '629c2de402a417ea7690ca6ce3f33229e27606a5' prevents updates that may include important fixes and features. GitHub recommends using stable versions like 'v3' to balance stability and updates (https://github.com/actions/checkout). Change the checkout action to 'actions/checkout@v3' or pinned minor semver release rather than a specific SHA to benefit from stable updates over time.
• [Low]Add caching for Go modules and dependencies to speed up builds
  The workflow runs 'go mod vendor' every time, but no caching for Go dependencies is implemented. Caching dependencies improves build speed and reduces load on external sites as recommended by Go and GitHub (https://github.com/actions/cache/blob/main/examples.md#go). Add caching steps for Go modules (e.g., cache the ~/go/pkg/mod directory and vendor directory) keyed by go.sum to accelerate subsequent runs.
• [Low]Clean up generated files after upload step to reduce runner disk usage
  Artifacts are prepared in the 'upload' directory, but no cleanup is performed. Over time, if the runner is reused, leftover files may accumulate. Add a cleanup step or use ephemeral runners. If runner reuse is possible, delete or clean 'upload' directory after push completes.
• [Low]Use a more informative job name instead of generic 'publish'
  Naming the job 'publish' is somewhat vague. More descriptive names help maintainability and workflow clarity (https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idname). Rename the job to something like 'publish_int_artifact' to clearly indicate its purpose.

scripts/install-int-agent.sh

• [High]Sanitize the 'tag' input to prevent command injection and enforce stricter validation
  The script validates the 'tag' argument using a regex that allows alphanumeric characters, underscore, dot, and dash; however, the regex allows a leading alphanumeric or underscore but does not fully restrict complex inputs like shell metacharacters or malicious strings that might lead to command injection or unexpected behavior. According to OWASP Command Injection Prevention Cheat Sheet, strict validation and sanitization of all external inputs is critical. Replace the tag validation regex with one that only allows known safe tag formats (e.g., alphanumeric, dots, dashes) and explicitly rejects any shell metacharacters. Additionally, consider rejecting tags with special characters or execute commands via safer means (e.g., arrays or parameter replacement) to avoid injection attacks. For example, use:
  [[ "$tag" =~ ^[a-zA-Z0-9._-]+$ ]] || fail "invalid tag: $tag"
• [High]Avoid using 'python3' inline scripts for JSON parsing; replace with dedicated tools or ensure robust error handling
  The script uses Python one-liners to parse JSON; failures in these scripts cause the overall script to fail or produce incomplete data. According to Shellcheck best practices and POSIX shell scripting guidelines, relying on external scripts inline can be fragile and should have robust error handling or replaced with tools designed for shell, such as 'jq'. Replace Python inline JSON parsing commands with 'jq' for better robustness and readability. For example, replace fetching 'token' with: token=$(curl -fsS "https://ghcr.io/token?scope=repository:${REPOSITORY}:pull" | jq -r '.token') || fail "Failed to get token"
• [Medium]Secure temporary directory handling to prevent symlink or race conditions
  Script uses 'mktemp -d' to create a temporary working directory but does not trap or clean up the temp directory on errors or script exit, possibly leaving sensitive data or temporary files accessible. According to POSIX best practices and OWASP Temporary File Handling guidelines, temporary directories should be securely created and cleaned up. Add trap handlers to clean up the temp directory on script exit or failure:
  work=$(mktemp -d)
  trap 'rm -rf "$work"' EXIT
  This ensures the temp directory is always removed even if the script exits early.
• [Medium]Use 'readonly' or 'declare -r' for constants to prevent accidental modification
  Variables like REPOSITORY, API_URL, and AGENT_DIR are global constants but not marked readonly. According to best practices for bash scripting and effective variable handling, constants should be readonly to avoid accidental reassignment. Declare constants as readonly:
  readonly REPOSITORY="step-security/agent/agent-int"
  readonly API_URL="https://int.api.stepsecurity.io/v1"
  readonly AGENT_DIR="/home/agent"
• [Medium]Check for existence and required tools before use and fail early if missing
  The script assumes tools such as curl, python3, sha256sum, systemctl, and sudo are installed and available. According to robust scripting best practices (e.g., Google Shell Style Guide), scripts should verify the availability of required external commands and tools before proceeding. Add a function to check required commands at the start, e.g.:
  for cmd in curl python3 sha256sum sudo systemctl; do
  command -v "$cmd" >/dev/null || fail "$cmd required but not found"
  done
• [Medium]Use double quotes consistently to prevent word splitting and globbing
  Some variables concatenated or referenced without quotes can lead to word splitting or globbing, which can cause bugs or security issues. As per Shellcheck and Bash scripting best practices, always quote variable expansions unless word splitting is desired. Quote all variable expansions, e.g., change [[ ! -e "$AGENT_DIR/agent" ]] to always use quotes and verify all such cases, including user inputs and command substitutions.
• [Low]Improve error messages with more context and consistent format
  The fail function outputs minimal error context. As per effective shell scripting error handling practices, error messages should include function name and cause to ease debugging. Refactor fail function to include caller function name and optionally a timestamp. For example:
  fail() {
  local caller=${FUNCNAME[1]:-main}
  echo "install-int-agent[$caller]: $*" >&2
  exit 1
  }
• [Low]Handle 'stop' command exit codes and provide more user feedback
  The stop function returns 0 quietly if no agent is installed or stop already ran. According to usability best practices, scripts should indicate status clearly for operators. Add explicit informational messages when no agent is installed or already stopped and consider returning different exit codes. For example, echo "No agent installed to stop." or "Agent stop already executed."
• [Low]Use robust methods to wait for files rather than fixed loops and sleeps
  Waiting for agent.status uses a for loop with sleep 1 up to 30 seconds. This can waste time and may miss events if delays vary. According to best practices in bash scripting, consider event-driven or timeout commands. Use 'timeout' command or inotifywait if available to wait for file creation, or reduce the loop wait time and increase iteration count for finer granularity.
• [Low]Add shellcheck and linting checks for improved maintainability
  The script lacks indications it has been vetted with shellcheck or other linters. Following best practice improves maintainability and reduces bugs. Run 'shellcheck' on the script and apply suggested fixes, such as quoting and unused variable warnings, improving portability and readability.

Feedback

We appreciate your feedback in helping us improve the service! To provide feedback, please use emojis on this comment. If you find the comments helpful, give them a 👍. If they aren't useful, kindly express that with a 👎. If you have questions or detailed feedback, please create n GitHub issue in StepSecurity/AI-CodeWise.

[step-security-bot-int]

Please find StepSecurity AI-CodeWise code comments below.

Code Comments

.github/workflows/int-release.yml

• [High]Avoid storing sensitive tokens directly in the .netrc file without proper file permissions
  The workflow adds the GitHub PAT token to the ~/.netrc file using an append operation but does not explicitly set restrictive permissions on the file. According to GitHub Actions security best practices (https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-tokens-and-credentials), files containing credentials such as .netrc should have correct permissions (e.g., 600) to prevent unauthorized access. After writing to ~/.netrc, add a command to set restrictive permissions: 'chmod 600 ~/.netrc'. Update the Configure .netrc step as follows:

  • name: Configure .netrc
    run: |
    printf "machine github.com login stepsecurity-infra-bot password ${{ secrets.PAT }}" > ~/.netrc
    chmod 600 ~/.netrc

• [High]Use explicit commit SHA references for the checkout action to prevent ambiguous refs
  The checkout step uses a conditional expression to select the ref, which can introduce ambiguity or errors if the pull_request context is undefined. As per GitHub Actions best practices (https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsuses), explicitly setting the ref to either the commit SHA or branch name depending on event type is safer. Refactor the checkout step to explicitly handle different event types, for example by using an if condition per step or by using a variable that is clearly defined for all cases. Alternatively, default to 'github.sha' when the 'pull_request' context is not present.

• [Medium]Restrict the permissions scope for the workflow to least privilege model
  The workflow specifies 'permissions: read-all' at the workflow level, which grants overly broad permissions. GitHub Actions documentation (https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) recommends using least privilege permission scopes to minimize security risks. Remove 'permissions: read-all' from the top-level and explicitly specify only required permissions (contents: read, packages: write) in jobs or steps as needed.

• [Medium]Use consistent versions or tags of actions instead of commit SHAs for better maintainability
  The workflow uses commit SHAs for actions like 'actions/checkout@629c2de40...' and 'actions/setup-go@424fc82d...', which makes the workflow harder to maintain and update. According to GitHub best practices (https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#using-the-actions-yaml-manifest), using released version tags (e.g., v3) is preferred for stability and clarity. Update action references to use pinned version tags like 'actions/checkout@v3' and 'actions/setup-go@v3'.

• [Medium]Add error handling for shell commands in the run steps
  Several run steps execute multiple shell commands without 'set -e' or proper error handling, which may allow failures to go unnoticed. Best practices for shell scripts recommend using 'set -e' or checking exit codes to fail fast on errors. Add 'set -e' at the start of run scripts, for example:

  • name: Prepare artifact
    run: |
    set -e
    mkdir upload
    cp dist/agent_linux_amd64.tar.gz upload/agent_linux_amd64.tar.gz
    cp dist/agent_linux_arm64.tar.gz upload/agent_linux_arm64.tar.gz
    cd upload
    sha256sum agent_linux_amd64.tar.gz agent_linux_arm64.tar.gz > checksums.txt
    cat checksums.txt

• [Low]Sanitize branch names more strictly for tag generation to comply with OCI tag naming conventions
  The branch name sanitization replaces invalid characters but does not limit length securely (limit is cut to 100 chars, but OCI recommends max 128 chars). Also, it uses 'cut -c1-100' which cuts bytes not characters, potentially corrupting UTF-8 multibyte characters. According to OCI image spec (https://github.com/opencontainers/image-spec/blob/main/descriptor.md#image-manifest-property-descriptions), tag names should be ASCII and proper length. Enhance sanitization to handle multibyte characters safely and limit tags to 128 characters, for example using a more robust sanitization function or utility.

• [Low]Cache Go modules to speed up builds
  The workflow runs 'go mod vendor' every build but does not cache Go modules which can slow builds. GitHub Actions recommends caching dependencies to improve performance (https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows). Add a cache step for Go modules prior to 'go mod vendor', for example:

  • name: Cache Go modules
    uses: actions/cache@v3
    with:
    path: |
    ~/.cache/go-build
    ${{ github.workspace }}/vendor
    key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}
    restore-keys: |
    ${{ runner.os }}-go-

• [Low]Use double quotes around environment variables in shell scripts to avoid word splitting
  In the run scripts, variables like $GITHUB_TOKEN, $ACTOR, and $TAGS are used without double quotes, which can lead to word splitting or globbing issues. The ShellCheck tool and Bash best practices (https://mywiki.wooledge.org/Quotes) recommend always quoting variables. Update shell commands to quote environment variables, e.g., change

  echo $GITHUB_TOKEN | oras login ...

to

echo "$GITHUB_TOKEN" | oras login ...

• [Low]Use explicit output variables and reduce reliance on environment variables for sharing data between steps
  The workflow sets environment variables to pass data between steps (e.g., TAGS, ACTOR) but relies on environment variables which can leak between steps unintentionally. The GitHub Actions recommended approach (https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter) is to use step outputs for passing data. Where feasible, use 'echo "::set-output name=var::value"' or the new syntax to set step outputs and reference those outputs explicitly.
• [Low]Pin GoReleaser action version explicitly instead of using commit SHA for clarity
  The workflow uses a long commit SHA for goreleaser/goreleaser-action, which is less readable and harder to update. Using a tagged release intended for actions helps with clarity (https://goreleaser.com/actions/). Update goreleaser action to a stable version tag, e.g., 'goreleaser/goreleaser-action@v4' or specific version.

Feedback

We appreciate your feedback in helping us improve the service! To provide feedback, please use emojis on this comment. If you find the comments helpful, give them a 👍. If they aren't useful, kindly express that with a 👎. If you have questions or detailed feedback, please create n GitHub issue in StepSecurity/AI-CodeWise.