GitHub SAST walkthrough: connect, scan and review workflow findings

What a GitHub SAST workflow should establish

A useful GitHub SAST workflow answers four questions: which repository and commit were analyzed, which analyzers actually ran, what evidence supports each finding, and which checks the team requires before merging. Installing an integration is the beginning of that workflow. It does not by itself prove that the intended private repository is accessible or that a failed scan will block a pull request.

This guide follows CodeStax's GitHub integration (opens in a new tab) and a recorded SAST finding from our October 23, 2026 evaluation of OWASP Juice Shop. The example comes from a public training repository at a pinned revision. It demonstrates a source-level finding in GitHub Actions YAML; it is not a customer incident, a live GitHub check-run capture or a benchmark of all GitHub repositories.

Connect GitHub and import the intended repository

1. Open Dashboard → Integrations and select the GitHub connection. Authorize repository access for the account or organization that owns the code. If the setup uses a GitHub App installation, confirm that the intended repository is included in that installation.
2. Import the repository into CodeStax. Check the owner and repository name, especially when personal forks and organization repositories share a similar name.
3. Open Dashboard → Repositories, select Scan and choose the branch you intend to review. Confirm the recorded default branch rather than assuming it is named main or master.
4. Choose the scan configuration and start the scan. Open the resulting scan detail, then review analyzer coverage before reading the finding list.
5. Keep the scanned commit with your review notes. Compare finding locations against that revision rather than a later version of the default branch.

For a private repository, access depends on the connected credential or permitted App installation. Organization policy or repository selection can restrict that access even when sign-in succeeded. If a repository is missing, check the integration and installation permissions before reconnecting repeatedly. Do not copy an OAuth token into source code or workflow YAML to make cloning work.

Start with a manual scan to establish that the repository connection, branch selection and result display work. Then configure event-driven behavior using the integration guidance for your deployment. Repository SAST and AI code review produce different evidence: a full repository finding should not be described as a live pull request review unless that review actually ran.

Inspect a real GitHub Actions SAST finding

Download the GitHub workflow finding evidence (JSON) to inspect the rule, recorded message, version and artifact hashes. The normalized evaluation path omits the leading dot in .github; the extract preserves the recorded value and supplies the correct pinned source link (opens in a new tab). Line 22 starts the run block, while the interpolation is within that block at line 25.

The following short excerpt comes from the MIT-licensed OWASP Juice Shop source, copyright Bjoern Kimminich and the OWASP Juice Shop contributors. The rule flags a GitHub context expression inserted into a shell script before the runner executes it.

run: |
  cd docs/modules/ROOT/assets/data
  rm challenges.yml
  wget https://raw.githubusercontent.com/juice-shop/juice-shop/${{ github.ref_name }}/data/static/challenges.yml

The source is github.ref_name, the transformation is expression substitution inside an inline script, and the sink is the shell executing wget. The review question is whether a value with unexpected shell meaning can reach that expression. This is why workflow files deserve source review alongside application routes: they execute with the runner's permissions and may use deployment or repository credentials.

Propose safer workflow input handling

GitHub's secure-use reference (opens in a new tab) recommends passing context values through an intermediate environment variable for inline scripts. The proposal below applies that approach, quotes shell expansions and restricts this particular download to the two expected branch names. It is an editorial remediation example, not a patch produced or validated by the recorded evaluation.

- name: Update challenges.yml
  env:
    REF_NAME: ${{ github.ref_name }}
  run: |
    case "$REF_NAME" in
      master|develop) ;;
      *) echo "Unsupported ref" >&2; exit 1 ;;
    esac
    cd docs/modules/ROOT/assets/data
    wget -O challenges.yml "https://raw.githubusercontent.com/juice-shop/juice-shop/${REF_NAME}/data/static/challenges.yml"

The expression is now assigned as an environment value rather than used to generate the shell script. Quoting the variable also keeps it in one argument. The allowlist reflects this workflow's stated branches; adapt it deliberately if the repository needs release branches or tags. Keep token permissions narrow and review what later steps commit. This fragment does not audit the checkout, credentials or every other step in the workflow.

Do not insert an untrusted value into a new eval call or dynamically constructed shell command after moving it to an environment variable. That would reintroduce interpretation as code. The goal is to pass a constrained value to a fixed command. Reviewers should inspect the whole command path rather than treating the presence of env as proof that every use is safe.

Validate the workflow and rescan the changed commit

Validate a candidate workflow in a controlled repository or branch with limited permissions before enabling write-capable automation. The historical record contains no workflow run for this proposal, so this page does not claim that the change passed or that the warning disappeared. Keep the candidate commit, test outcome and new scan together. If YAML parsing fails or the file is excluded, resolve that coverage problem before closing the warning.

A contextual dismissal can be reasonable when the value is constrained and the execution path is unreachable for untrusted input. Record the trigger, permission assumptions and reason, then revisit the decision when the workflow changes. A blanket dismissal of every workflow interpolation warning would lose the context that made this particular assessment defensible.

Connect scan results to GitHub quality gates

The CodeStax integration documentation describes a GitHub App quality-gate Check Run named CodeStax Quality Gate. App installation, repository access and quality-gate configuration are prerequisites. Treat this as a setup path to verify in your own repository: the downloadable example on this page contains a SAST finding, not evidence that a check or PR comment was posted.

1. Configure the intended policy in Settings → Quality Gates or the policy settings for your deployment. Start with thresholds your team has reviewed, and decide how missing required analysis should be handled.
2. Enable Block merge on fail if a failed gate should publish a failure conclusion. The documented default for a failed gate with this option off is a neutral, non-blocking conclusion.
3. Run a scan and verify that the CodeStax Quality Gate check appears on the exact scanned commit. A skipped or absent check is not evidence that the policy passed.
4. Configure GitHub branch protection or a repository ruleset to require the intended check. Confirm repository policy behavior with a controlled failing case before relying on it for merge enforcement.

A check can be visible while merging remains allowed. Conversely, requiring a check that is never published can prevent an otherwise valid change from merging. Verify both the passing and failing paths and make sure the rule covers the target branch. Use the quality-gate setup guide (opens in a new tab) with the GitHub integration reference (opens in a new tab) for the current deployment details.

Troubleshoot access, events and incomplete analysis

For webhook-driven behavior, inspect GitHub's delivery history and the corresponding CodeStax result. A delivered HTTP request and a completed analysis are separate events; connect them using the repository, commit and time. When troubleshooting, preserve the failure evidence and avoid exposing webhook secrets or tokens in screenshots or issue comments. For analyzer errors, fix the missing coverage rather than hiding the status behind a successful job label.

Continue from workflow YAML to application code

The recorded run included both workflow YAML and TypeScript application code, but the selected workflow warning does not demonstrate equal rule depth across every file type. Continue with the TypeScript SAST walkthrough to examine a separate real SQL injection finding in the same pinned repository. Compare the trust boundary and proposed fix: binding SQL values and handling shell input require different changes.

Use SAST for source patterns, SCA for third-party dependencies, and secret detection for exposed credentials. Keep each result's origin and coverage visible in the review. The useful outcome is an auditable decision attached to a specific commit, supported by source, tests and a rescan, rather than an unexplained green badge.