Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
62 changes: 62 additions & 0 deletions .github/workflows/shiftleft.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
---
# This workflow integrates Harness SAST and SCA with GitHub
# Visit https://docs.shiftleft.io for help
name: Harness SAST and SCA

on:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1: The --tag branch= expression uses github.head_ref, which is only available for pull_request events. If this workflow is triggered manually via workflow_dispatch, github.head_ref evaluates to an empty string, resulting in a malformed --tag branch= argument that could cause the CLI to error or attach an incorrect tag. Consider guarding the tag with a conditional or using a fallback like ${{ github.head_ref || github.ref_name }} to handle both trigger types.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/shiftleft.yml, line 6:

<comment>The `--tag branch=` expression uses `github.head_ref`, which is only available for `pull_request` events. If this workflow is triggered manually via `workflow_dispatch`, `github.head_ref` evaluates to an empty string, resulting in a malformed `--tag branch=` argument that could cause the CLI to error or attach an incorrect tag. Consider guarding the tag with a conditional or using a fallback like `${{ github.head_ref || github.ref_name }}` to handle both trigger types.</comment>

<file context>
@@ -0,0 +1,62 @@
+# Visit https://docs.shiftleft.io for help
+name: Harness SAST and SCA
+
+on:
+  pull_request:
+  workflow_dispatch:
</file context>

pull_request:
workflow_dispatch:

jobs:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: The workflow does not define an explicit permissions block, so the GITHUB_TOKEN will have the repository's default permissions (often write-all). Following the principle of least privilege, add a top-level permissions block with minimal scopes needed. For a static analysis workflow, contents: read should be sufficient for the main job.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/shiftleft.yml, line 10:

<comment>The workflow does not define an explicit `permissions` block, so the `GITHUB_TOKEN` will have the repository's default permissions (often `write-all`). Following the principle of least privilege, add a top-level `permissions` block with minimal scopes needed. For a static analysis workflow, `contents: read` should be sufficient for the main job.</comment>

<file context>
@@ -0,0 +1,62 @@
+  pull_request:
+  workflow_dispatch:
+
+jobs:
+  NextGen-Static-Analysis:
+    runs-on: ubuntu-latest
</file context>

NextGen-Static-Analysis:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found 2 issues:

1. credential persistence through GitHub Actions artifacts [zizmor:zizmor/artipacked]


2. the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue [actionlint:action]

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: actions/checkout@v3 runs on the deprecated Node 16 runtime. GitHub Actions will show deprecation warnings — upgrade to @v4 to use Node 20.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/shiftleft.yml, line 14:

<comment>`actions/checkout@v3` runs on the deprecated Node 16 runtime. GitHub Actions will show deprecation warnings — upgrade to `@v4` to use Node 20.</comment>

<file context>
@@ -0,0 +1,62 @@
+  NextGen-Static-Analysis:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v3
+    - name: Setup Java JDK v11
+      uses: actions/setup-java@v3
</file context>
Suggested change
- uses: actions/checkout@v3
- uses: actions/checkout@v4

- name: Setup Java JDK v11
uses: actions/setup-java@v3

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the runner of "actions/setup-java@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue [actionlint:action]

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: actions/setup-java@v3 runs on the deprecated Node 16 runtime — upgrade to @v4 to use Node 20 and avoid deprecation warnings.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/shiftleft.yml, line 16:

<comment>`actions/setup-java@v3` runs on the deprecated Node 16 runtime — upgrade to `@v4` to use Node 20 and avoid deprecation warnings.</comment>

<file context>
@@ -0,0 +1,62 @@
+    steps:
+    - uses: actions/checkout@v3
+    - name: Setup Java JDK v11
+      uses: actions/setup-java@v3
+      with:
+        distribution: zulu
</file context>

with:
distribution: zulu
java-version: 11

- name: Download Harness SAST and SCA CLI
run: |
curl https://cdn.shiftleft.io/download/sl > ${GITHUB_WORKSPACE}/sl && chmod a+rx ${GITHUB_WORKSPACE}/sl

- name: Static Analysis

Check failure on line 25 in .github/workflows/shiftleft.yml

View check run for this annotation

Codacy Production / Codacy Static Code Analysis

.github/workflows/shiftleft.yml#L25

Ensure run commands are not vulnerable to shell injection
run: |

Check failure on line 26 in .github/workflows/shiftleft.yml

View check run for this annotation

Codacy Production / Codacy Static Code Analysis

.github/workflows/shiftleft.yml#L26

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"github.head_ref" is potentially untrusted. avoid using it directly in inline scripts. instead, pass it through an environment variable. see https://docs\.github\.com/en/actions/reference/security/secure\-use\#good\-practices\-for\-mitigating\-script\-injection\-attacks for more details [actionlint:expression]

${GITHUB_WORKSPACE}/sl --version
${GITHUB_WORKSPACE}/sl analyze --strict --wait \
--app RACS \
--tag branch=${{ github.head_ref }} \

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code injection via template expansion [zizmor:zizmor/template-injection]

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: The github.head_ref variable is empty for workflow_dispatch triggers, causing manual analysis runs to have an empty branch tag in the Qwiet dashboard.
Severity: MEDIUM

Suggested Fix

Use github.ref_name instead of github.head_ref. The github.ref_name variable correctly provides the branch or tag name for all event types, including workflow_dispatch and pull_request, ensuring consistent tagging.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: .github/workflows/shiftleft.yml#L30

Potential issue: When the workflow is triggered manually via `workflow_dispatch`, the
`github.head_ref` context variable is empty. This causes the `--tag branch=${{
github.head_ref }}` argument to pass an empty string to the `sl analyze` command. As a
result, SAST results from manual runs are stored without a proper branch identifier in
the Qwiet dashboard, making it difficult to track and correlate findings.

Did we get this right? 👍 / 👎 to inform future reviews.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1: Using ${{ github.head_ref }} directly in an inline run script is a script injection risk. An attacker can create a PR from a branch with a malicious name (e.g., containing shell metacharacters or backticks) to execute arbitrary commands. GitHub's security documentation explicitly warns against this pattern. Pass the value through an environment variable instead:

env:
  BRANCH: ${{ github.head_ref }}
run: |
  ... --tag branch=$BRANCH ...
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/shiftleft.yml, line 30:

<comment>Using `${{ github.head_ref }}` directly in an inline `run` script is a script injection risk. An attacker can create a PR from a branch with a malicious name (e.g., containing shell metacharacters or backticks) to execute arbitrary commands. GitHub's security documentation explicitly warns against this pattern. Pass the value through an environment variable instead:

```yaml
env:
  BRANCH: ${{ github.head_ref }}
run: |
  ... --tag branch=$BRANCH ...
```</comment>

<file context>
@@ -0,0 +1,62 @@
+        ${GITHUB_WORKSPACE}/sl --version
+        ${GITHUB_WORKSPACE}/sl analyze --strict --wait \
+          --app RACS \
+          --tag branch=${{ github.head_ref }} \
+          --jssrc .
+      env:
</file context>

--jssrc .
env:
SHIFTLEFT_ACCESS_TOKEN: ${{ secrets.SHIFTLEFT_ACCESS_TOKEN }}
SHIFTLEFT_API_HOST: www.shiftleft.io
SHIFTLEFT_GRPC_TELEMETRY_HOST: telemetry.shiftleft.io:443
SHIFTLEFT_GRPC_API_HOST: api.shiftleft.io:443

# Build-Rules:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: The Build-Rules job is entirely commented out, meaning the security policies defined in shiftleft.yml (blocking critical findings, OSS vulnerabilities) will never be evaluated. Pull requests with critical security findings won't be blocked from merging. If this is intentional for an initial rollout, consider adding a comment explaining when it should be enabled; otherwise, uncomment the job to enforce the defined policies.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/shiftleft.yml, line 38:

<comment>The `Build-Rules` job is entirely commented out, meaning the security policies defined in `shiftleft.yml` (blocking critical findings, OSS vulnerabilities) will never be evaluated. Pull requests with critical security findings won't be blocked from merging. If this is intentional for an initial rollout, consider adding a comment explaining when it should be enabled; otherwise, uncomment the job to enforce the defined policies.</comment>

<file context>
@@ -0,0 +1,62 @@
+        SHIFTLEFT_GRPC_TELEMETRY_HOST: telemetry.shiftleft.io:443
+        SHIFTLEFT_GRPC_API_HOST: api.shiftleft.io:443
+
+#   Build-Rules:
+#     runs-on: ubuntu-latest
+#     permissions: write-all
</file context>

# runs-on: ubuntu-latest
# permissions: write-all

Check warning on line 40 in .github/workflows/shiftleft.yml

View check run for this annotation

Codacy Production / Codacy Static Code Analysis

.github/workflows/shiftleft.yml#L40

Ensure top-level permissions are not set to write-all
# needs: NextGen-Static-Analysis
# steps:
# - uses: actions/checkout@v3
# - name: Download Harness SAST and SCA CLI
# run: |
# curl https://cdn.shiftleft.io/download/sl > ${GITHUB_WORKSPACE}/sl && chmod a+rx ${GITHUB_WORKSPACE}/sl
# - name: Validate Build Rules
# run: |
# ${GITHUB_WORKSPACE}/sl check-analysis --app RACS \
# --github-pr-number=${{github.event.number}} \
# --github-pr-user=${{ github.repository_owner }} \
# --github-pr-repo=${{ github.event.repository.name }} \
# --github-token=${{ secrets.GITHUB_TOKEN }}
# env:
# # SHIFTLEFT_ACCESS_TOKEN: ${{ secrets.SHIFTLEFT_ACCESS_TOKEN }}

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: The SHIFTLEFT_ACCESS_TOKEN secret is double-commented and will remain commented out even if the surrounding job is uncommented, causing authentication failure.
Severity: MEDIUM

Suggested Fix

Remove the extra # from the SHIFTLEFT_ACCESS_TOKEN line (line 55) so that it is commented at the same level as the rest of the Build-Rules job. This ensures it will be correctly activated when the job is uncommented.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: .github/workflows/shiftleft.yml#L55

Potential issue: In the commented-out `Build-Rules` job, the `SHIFTLEFT_ACCESS_TOKEN`
secret is double-commented. If a developer uncomments the job block by removing the
leading `#` from each line, the line for the access token will remain commented (`#
SHIFTLEFT_ACCESS_TOKEN: ...`). This will cause the `sl check-analysis` command to fail
with an authentication error, preventing security rules from being checked.

Did we get this right? 👍 / 👎 to inform future reviews.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: The SHIFTLEFT_ACCESS_TOKEN line has a double comment (# ... # SHIFTLEFT_ACCESS_TOKEN). If someone uncomments the Build-Rules job by removing the leading # from each line, this environment variable will remain commented out, causing sl check-analysis to fail with an authentication error. Remove the inner # so it's at the same comment level as the rest of the block.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/shiftleft.yml, line 55:

<comment>The `SHIFTLEFT_ACCESS_TOKEN` line has a double comment (`# ... # SHIFTLEFT_ACCESS_TOKEN`). If someone uncomments the `Build-Rules` job by removing the leading `#` from each line, this environment variable will remain commented out, causing `sl check-analysis` to fail with an authentication error. Remove the inner `#` so it's at the same comment level as the rest of the block.</comment>

<file context>
@@ -0,0 +1,62 @@
+#             --github-pr-repo=${{ github.event.repository.name }} \
+#             --github-token=${{ secrets.GITHUB_TOKEN }}
+#       env:
+#         # SHIFTLEFT_ACCESS_TOKEN: ${{ secrets.SHIFTLEFT_ACCESS_TOKEN }}
+#
+#         SHIFTLEFT_API_HOST: www.shiftleft.io
</file context>

#
# SHIFTLEFT_API_HOST: www.shiftleft.io
# SHIFTLEFT_GRPC_TELEMETRY_HOST: telemetry.shiftleft.io:443
# SHIFTLEFT_GRPC_API_HOST: api.shiftleft.io:443
#
Comment on lines +12 to +60

Comment on lines +51 to +61

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: The Build-Rules job is commented out, so security policies defined via sl check-analysis are not being enforced on pull requests.
Severity: CRITICAL

Suggested Fix

Uncomment the Build-Rules job (lines 38-61) in .github/workflows/shiftleft.yml to re-enable the sl check-analysis step. This will ensure that the defined security policies are enforced on pull requests.

Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: .github/workflows/shiftleft.yml#L38-L61

Potential issue: The `Build-Rules` job in the `shiftleft.yml` workflow, responsible for
enforcing security gates with `sl check-analysis`, is entirely commented out. Although
build rules are defined to block critical findings, these rules are never evaluated. As
a result, pull requests containing critical security vulnerabilities will not be blocked
from merging, bypassing the intended security checks.

Did we get this right? 👍 / 👎 to inform future reviews.


Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overly broad permissions [zizmor:zizmor/excessive-permissions]

15 changes: 15 additions & 0 deletions shiftleft.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
version: 2
build_rules:
- id: Allow no critical findings
severities:
- critical
- id: Allow one OSS or container finding
finding_types:
- oss_vuln
- container
threshold: 1
- id: Allow no reachable OSS vulnerability
finding_types:
- oss_vuln
options:
reachable: true
Loading