carverauto/serviceradar

Fork 0

fix: update SBOM workflow to use syft config file and fix permissions #2444

Merged

mfreeman451 merged 1 commit from refs/pull/2444/head into main

2025-11-22 23:35:40 +00:00

mfreeman451 commented

2025-11-22 23:31:20 +00:00

(Migrated from github.com)

Owner

Imported from GitHub pull request.

Original GitHub pull request: #1976
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/pull/1976
Original created: 2025-11-22T23:31:20Z
Original updated: 2025-12-08T06:54:40Z
Original head: carverauto/serviceradar:chore/fix_sbom-syft
Original base: main
Original merged: 2025-11-22T23:35:40Z by @mfreeman451

User description

Summary

Fixes the failing SBOM (syft) workflow in CI/CD.

Changes

Remove unsupported exclude parameter from anchore/sbom-action@v0
Create .syft.yaml config file for exclusions instead
Change permissions from contents: read to contents: write for release asset uploads
Only upload to release assets when triggered by release event

Issue

The workflow was failing with:

Warning: Unexpected input(s) 'exclude', valid inputs are [...]
Error: Resource not accessible by integration

Solution

The newer version of anchore/sbom-action doesn't support the exclude parameter directly. Instead, we need to use a syft config file. Also added write permissions for attaching SBOMs to releases.

PR Type

Bug fix

Description

Replace unsupported exclude parameter with .syft.yaml config file
Upgrade workflow permissions from read to write for release uploads
Add conditional release asset upload based on event type
Consolidate SBOM exclusion patterns into dedicated config file

Diagram Walkthrough

flowchart LR
  A["SBOM Workflow"] -->|Remove unsupported exclude| B["Create .syft.yaml config"]
  A -->|Update permissions| C["contents: write"]
  A -->|Conditional upload| D["github.event_name == release"]
  B --> E["Syft action with config"]
  C --> F["Release asset upload"]
  D --> F

File Walkthrough

Relevant files

Bug fix

sbom-syft.yml

Migrate to syft config file and fix permissions

.github/workflows/sbom-syft.yml

Upgraded workflow permissions from contents: read to contents: write
to enable release asset uploads
Added new step to create .syft.yaml config file with exclusion
patterns for node_modules, vendor, target, .git, build, and release
directories
Replaced inline exclude parameter with config: .syft.yaml reference in
anchore/sbom-action
Added conditional upload-release-assets parameter to only upload when
triggered by release event

+15/-9

Imported from GitHub pull request. Original GitHub pull request: #1976 Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/pull/1976 Original created: 2025-11-22T23:31:20Z Original updated: 2025-12-08T06:54:40Z Original head: carverauto/serviceradar:chore/fix_sbom-syft Original base: main Original merged: 2025-11-22T23:35:40Z by @mfreeman451 --- ### **User description** ## Summary Fixes the failing SBOM (syft) workflow in CI/CD. ## Changes - Remove unsupported `exclude` parameter from `anchore/sbom-action@v0` - Create `.syft.yaml` config file for exclusions instead - Change permissions from `contents: read` to `contents: write` for release asset uploads - Only upload to release assets when triggered by release event ## Issue The workflow was failing with: ``` Warning: Unexpected input(s) 'exclude', valid inputs are [...] Error: Resource not accessible by integration ``` ## Solution The newer version of `anchore/sbom-action` doesn't support the `exclude` parameter directly. Instead, we need to use a syft config file. Also added write permissions for attaching SBOMs to releases. ___ ### **PR Type** Bug fix ___ ### **Description** - Replace unsupported `exclude` parameter with `.syft.yaml` config file - Upgrade workflow permissions from read to write for release uploads - Add conditional release asset upload based on event type - Consolidate SBOM exclusion patterns into dedicated config file ___ ### Diagram Walkthrough ```mermaid flowchart LR A["SBOM Workflow"] -->|Remove unsupported exclude| B["Create .syft.yaml config"] A -->|Update permissions| C["contents: write"] A -->|Conditional upload| D["github.event_name == release"] B --> E["Syft action with config"] C --> F["Release asset upload"] D --> F ``` <details> <summary><h3> File Walkthrough</h3></summary> <table><thead><tr><th></th><th align="left">Relevant files</th></tr></thead><tbody><tr><td>Bug fix</td><td><table> <tr> <td> <details> <summary>sbom-syft.yml<dd><code>Migrate to syft config file and fix permissions</code>                    </dd></summary> <hr> .github/workflows/sbom-syft.yml <ul><li>Upgraded workflow permissions from <code>contents: read</code> to <code>contents: write</code> to enable release asset uploads <li> Added new step to create <code>.syft.yaml</code> config file with exclusion patterns for node_modules, vendor, target, .git, build, and release directories <li> Replaced inline <code>exclude</code> parameter with <code>config: .syft.yaml</code> reference in anchore/sbom-action <li> Added conditional <code>upload-release-assets</code> parameter to only upload when triggered by release event</ul> </details> </td> <td><a href="https://github.com/carverauto/serviceradar/pull/1976/files#diff-f79636c7ac6e657fd98f9ead92fd4ffe68b8306a9a329bb602e3d1520b8a8017">+15/-9</a>    </td> </tr> </table></td></tr></tr></tbody></table> </details> ___

qodo-code-review[bot] commented

2025-11-22 23:31:39 +00:00

(Migrated from github.com)

Author

Owner

Imported GitHub PR comment.

Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/1976#issuecomment-3567145853
Original created: 2025-11-22T23:31:39Z

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
⚪	Excessive workflow permissions Description: The workflow permission was elevated to `contents: write`, granting broader repository write access to the entire workflow which increases risk if any step or dependency is compromised; scope this permission to only the job or step that needs it or use a dedicated token to minimize impact. sbom-syft.yml [9-9] Referred Code `contents: write`
	Shell heredoc safety Description: The step writes a `.syft.yaml` from shell without quoting EOF or setting safe shell options, which can allow unintended shell expansion or injection if future variables are interpolated; use a quoted heredoc (e.g., <<'EOF') and `set -euo pipefail` to harden. sbom-syft.yml [17-27] Referred Code `- name: Create syft config run: \| cat > .syft.yaml <<EOF exclude: - "/node_modules/" - "/vendor/" - "/target/" - "/.git/" - "/build/" - "/release/" EOF`
	Release asset upload risk Description: The SBOM action may upload release assets when the event is `release`, and combined with `contents: write` this could allow unintended asset modification if the workflow is triggered in forked contexts or reused; ensure `pull_request` from forks cannot reach this path and restrict `permissions` at job level. sbom-syft.yml [35-36] Referred Code `config: .syft.yaml upload-release-assets: ${{ github.event_name == 'release' }}`
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Action Auditing: The workflow changes introduce permission escalation and conditional uploads without explicit audit logging of key actions, which may or may not be handled elsewhere in the CI logs. Referred Code `permissions: contents: write jobs: generate-sbom: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Create syft config run: \| cat > .syft.yaml <<EOF exclude: - "/node_modules/" - "/vendor/" - "/target/" - "/.git/" - "/build/" - "/release/" EOF ... (clipped 8 lines)` Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Step Failures: The workflow steps (config creation, SBOM generation, artifact upload) do not include explicit failure handling or retries, relying on default action behavior which may be acceptable but is not explicit in the diff. Referred Code `- name: Create syft config run: \| cat > .syft.yaml <<EOF exclude: - "/node_modules/" - "/vendor/" - "/target/" - "/.git/" - "/build/" - "/release/" EOF - name: Generate SPDX SBOM (syft) uses: anchore/sbom-action@v0 with: path: . format: spdx-json output-file: SBOM.spdx config: .syft.yaml upload-release-assets: ${{ github.event_name == 'release' }} ... (clipped 4 lines)` Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Write Permission Scope: Elevating workflow permissions to contents: write broadens access without explicit scoping or justification in-code, which may be necessary for release uploads but cannot be fully validated from the diff alone. Referred Code `permissions: contents: write jobs: generate-sbom:` Learn more about managing compliance generic rules or creating your own custom rules

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

Imported GitHub PR comment. Original author: @qodo-code-review[bot] Original URL: https://github.com/carverauto/serviceradar/pull/1976#issuecomment-3567145853 Original created: 2025-11-22T23:31:39Z --- ## PR Compliance Guide 🔍  Below is a summary of compliance checks for this PR: <table><tbody><tr><td colspan='2'>Security Compliance</td></tr> <tr><td rowspan=3>⚪</td> <td><details><summary>Excessive workflow permissions </summary> Description: The workflow permission was elevated to <code>contents: write</code>, granting broader repository write access to the entire workflow which increases risk if any step or dependency is compromised; scope this permission to only the job or step that needs it or use a dedicated token to minimize impact. <a href='https://github.com/carverauto/serviceradar/pull/1976/files#diff-f79636c7ac6e657fd98f9ead92fd4ffe68b8306a9a329bb602e3d1520b8a8017R9-R9'>sbom-syft.yml [9-9]</a> <details open><summary>Referred Code</summary> ```yaml contents: write ``` </details></details></td></tr> <tr><td><details><summary>Shell heredoc safety </summary> Description: The step writes a <code>.syft.yaml</code> from shell without quoting EOF or setting safe shell options, which can allow unintended shell expansion or injection if future variables are interpolated; use a quoted heredoc (e.g., <<'EOF') and <code>set -euo pipefail</code> to harden. <a href='https://github.com/carverauto/serviceradar/pull/1976/files#diff-f79636c7ac6e657fd98f9ead92fd4ffe68b8306a9a329bb602e3d1520b8a8017R17-R27'>sbom-syft.yml [17-27]</a> <details open><summary>Referred Code</summary> ```yaml - name: Create syft config run: | cat > .syft.yaml <<EOF exclude: - "**/node_modules/**" - "**/vendor/**" - "**/target/**" - "**/.git/**" - "**/build/**" - "**/release/**" EOF ``` </details></details></td></tr> <tr><td><details><summary>Release asset upload risk </summary> Description: The SBOM action may upload release assets when the event is <code>release</code>, and combined with <code>contents: write</code> this could allow unintended asset modification if the workflow is triggered in forked contexts or reused; ensure <code>pull_request</code> from forks cannot reach this path and restrict <code>permissions</code> at job level. <a href='https://github.com/carverauto/serviceradar/pull/1976/files#diff-f79636c7ac6e657fd98f9ead92fd4ffe68b8306a9a329bb602e3d1520b8a8017R35-R36'>sbom-syft.yml [35-36]</a> <details open><summary>Referred Code</summary> ```yaml config: .syft.yaml upload-release-assets: ${{ github.event_name == 'release' }} ``` </details></details></td></tr> <tr><td colspan='2'>Ticket Compliance</td></tr> <tr><td>⚪</td><td><details><summary>🎫 No ticket provided </summary> - [ ] Create ticket/issue  </details></td></tr> <tr><td colspan='2'>Codebase Duplication Compliance</td></tr> <tr><td>⚪</td><td><details><summary>Codebase context is not defined </summary> Follow the <a href='https://qodo-merge-docs.qodo.ai/core-abilities/rag_context_enrichment/'>guide</a> to enable codebase context checks. </details></td></tr> <tr><td colspan='2'>Custom Compliance</td></tr> <tr><td rowspan=3>🟢</td><td> <details><summary>Generic: Meaningful Naming and Self-Documenting Code</summary> **Objective:** Ensure all identifiers clearly express their purpose and intent, making code self-documenting **Status:** Passed > Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a> </details></td></tr> <tr><td> <details><summary>Generic: Secure Error Handling</summary> **Objective:** To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. **Status:** Passed > Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a> </details></td></tr> <tr><td> <details><summary>Generic: Secure Logging Practices</summary> **Objective:** To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. **Status:** Passed > Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a> </details></td></tr> <tr><td rowspan=3>⚪</td> <td><details> <summary>Generic: Comprehensive Audit Trails</summary> **Objective:** To create a detailed and reliable record of critical system actions for security analysis and compliance. **Status:** <a href='https://github.com/carverauto/serviceradar/pull/1976/files#diff-f79636c7ac6e657fd98f9ead92fd4ffe68b8306a9a329bb602e3d1520b8a8017R8-R36'>Action Auditing</a>: The workflow changes introduce permission escalation and conditional uploads without explicit audit logging of key actions, which may or may not be handled elsewhere in the CI logs. <details open><summary>Referred Code</summary> ```yaml permissions: contents: write jobs: generate-sbom: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Create syft config run: | cat > .syft.yaml <<EOF exclude: - "**/node_modules/**" - "**/vendor/**" - "**/target/**" - "**/.git/**" - "**/build/**" - "**/release/**" EOF ... (clipped 8 lines) ``` </details> > Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a> </details></td></tr> <tr><td><details> <summary>Generic: Robust Error Handling and Edge Case Management</summary> **Objective:** Ensure comprehensive error handling that provides meaningful context and graceful degradation **Status:** <a href='https://github.com/carverauto/serviceradar/pull/1976/files#diff-f79636c7ac6e657fd98f9ead92fd4ffe68b8306a9a329bb602e3d1520b8a8017R17-R41'>Step Failures</a>: The workflow steps (config creation, SBOM generation, artifact upload) do not include explicit failure handling or retries, relying on default action behavior which may be acceptable but is not explicit in the diff. <details open><summary>Referred Code</summary> ```yaml - name: Create syft config run: | cat > .syft.yaml <<EOF exclude: - "**/node_modules/**" - "**/vendor/**" - "**/target/**" - "**/.git/**" - "**/build/**" - "**/release/**" EOF - name: Generate SPDX SBOM (syft) uses: anchore/sbom-action@v0 with: path: . format: spdx-json output-file: SBOM.spdx config: .syft.yaml upload-release-assets: ${{ github.event_name == 'release' }} ... (clipped 4 lines) ``` </details> > Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a> </details></td></tr> <tr><td><details> <summary>Generic: Security-First Input Validation and Data Handling</summary> **Objective:** Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities **Status:** <a href='https://github.com/carverauto/serviceradar/pull/1976/files#diff-f79636c7ac6e657fd98f9ead92fd4ffe68b8306a9a329bb602e3d1520b8a8017R8-R12'>Write Permission Scope</a>: Elevating workflow permissions to contents: write broadens access without explicit scoping or justification in-code, which may be necessary for release uploads but cannot be fully validated from the diff alone. <details open><summary>Referred Code</summary> ```yaml permissions: contents: write jobs: generate-sbom: ``` </details> > Learn more about managing compliance <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#configuration-options'>generic rules</a> or creating your own <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/#custom-compliance'>custom rules</a> </details></td></tr> <tr><td align="center" colspan="2">   </td></tr></tbody></table> <details><summary>Compliance status legend</summary> 🟢 - Fully Compliant 🟡 - Partial Compliant 🔴 - Not Compliant ⚪ - Requires Further Human Verification 🏷️ - Compliance label </details>

qodo-code-review[bot] commented

2025-11-22 23:32:32 +00:00

(Migrated from github.com)

Author

Owner

Imported GitHub PR comment.

Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/1976#issuecomment-3567146362
Original created: 2025-11-22T23:32:32Z

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Security	Pin action to a specific version Pin the `anchore/sbom-action` to a specific commit SHA instead of using the floating tag `@v0` to improve workflow security and reproducibility. .github/workflows/sbom-syft.yml [29-36] `- name: Generate SPDX SBOM (syft) - uses: anchore/sbom-action@v0 + uses: anchore/sbom-action@a15b4e17b5247b1628b764a4331712035ea52919 # Pin to a specific commit, e.g., v0.15.9 with: path: . format: spdx-json output-file: SBOM.spdx config: .syft.yaml upload-release-assets: ${{ github.event_name == 'release' }}` Apply / Chat Suggestion importance[1-10]: 8 __ Why: The suggestion correctly points out a security and reliability best practice. Pinning the GitHub Action version to a specific commit SHA prevents unexpected breaking changes and mitigates supply chain risks, which is a significant improvement for the workflow's stability.	Medium
High-level	Commit `.syft.yaml` instead of generating it Instead of dynamically generating the `.syft.yaml` file in the workflow, commit it directly to the repository. This separates configuration from CI logic, improving maintainability and transparency. Examples: .github/workflows/sbom-syft.yml [17-28] `- name: Create syft config run: \| cat > .syft.yaml <<EOF exclude: - "/node_modules/" - "/vendor/" - "/target/" - "/.git/" - "/build/" - "/release/" ... (clipped 2 lines)` Solution Walkthrough: Before: `# .github/workflows/sbom-syft.yml jobs: generate-sbom: steps: - name: Create syft config run: \| cat > .syft.yaml <<EOF exclude: - "/node_modules/" # ... other exclusions EOF - name: Generate SPDX SBOM (syft) uses: anchore/sbom-action@v0 with: config: .syft.yaml # ...` After: `# .github/workflows/sbom-syft.yml jobs: generate-sbom: steps: # The "Create syft config" step is removed. - name: Generate SPDX SBOM (syft) uses: anchore/sbom-action@v0 with: config: .syft.yaml # This file is now checked into the repo # ... # .syft.yaml (new file in repo) exclude: - "/node_modules/" - "/vendor/" # ... other exclusions` Suggestion importance[1-10]: 7 __ Why: This is a strong suggestion for improving maintainability and adhering to best practices by version-controlling configuration instead of generating it dynamically in a CI script.	Medium
General	Prevent shell expansion in heredoc In the `Create syft config` step, change the heredoc delimiter from `<<EOF` to `<<'EOF'` to prevent accidental shell expansion and make the script more robust. .github/workflows/sbom-syft.yml [17-27] `- name: Create syft config run: \| - cat > .syft.yaml <<EOF + cat > .syft.yaml <<'EOF' exclude: - "/node_modules/" - "/vendor/" - "/target/" - "/.git/" - "/build/" - "/release/" EOF` Apply / Chat Suggestion importance[1-10]: 6 __ Why: This is a valid suggestion that improves the robustness of the script by preventing unintentional shell expansion in the heredoc. While there is no immediate issue, this change makes the code safer against future modifications.	Low
More

Imported GitHub PR comment. Original author: @qodo-code-review[bot] Original URL: https://github.com/carverauto/serviceradar/pull/1976#issuecomment-3567146362 Original created: 2025-11-22T23:32:32Z --- ## PR Code Suggestions ✨  Explore these optional code suggestions: <table><thead><tr><td>Category</td><td align=left>Suggestion                                                                                                                                    </td><td align=center>Impact</td></tr><tbody><tr><td rowspan=1>Security</td> <td> <details><summary>Pin action to a specific version</summary> ___ **Pin the <code>anchore/sbom-action</code> to a specific commit SHA instead of using the floating tag <code>@v0</code> to improve workflow security and reproducibility.** [.github/workflows/sbom-syft.yml [29-36]](https://github.com/carverauto/serviceradar/pull/1976/files#diff-f79636c7ac6e657fd98f9ead92fd4ffe68b8306a9a329bb602e3d1520b8a8017R29-R36) ```diff - name: Generate SPDX SBOM (syft) - uses: anchore/sbom-action@v0 + uses: anchore/sbom-action@a15b4e17b5247b1628b764a4331712035ea52919 # Pin to a specific commit, e.g., v0.15.9 with: path: . format: spdx-json output-file: SBOM.spdx config: .syft.yaml upload-release-assets: ${{ github.event_name == 'release' }} ``` - [ ] **Apply / Chat**  <details><summary>Suggestion importance[1-10]: 8</summary> __ Why: The suggestion correctly points out a security and reliability best practice. Pinning the GitHub Action version to a specific commit SHA prevents unexpected breaking changes and mitigates supply chain risks, which is a significant improvement for the workflow's stability. </details></details></td><td align=center>Medium </td></tr><tr><td rowspan=1>High-level</td> <td> <details><summary>Commit <code>.syft.yaml</code> instead of generating it</summary> ___ **Instead of dynamically generating the <code>.syft.yaml</code> file in the workflow, commit it directly to the repository. This separates configuration from CI logic, improving maintainability and transparency.** ### Examples: <details> <summary> <a href="https://github.com/carverauto/serviceradar/pull/1976/files#diff-f79636c7ac6e657fd98f9ead92fd4ffe68b8306a9a329bb602e3d1520b8a8017R17-R28">.github/workflows/sbom-syft.yml [17-28]</a> </summary> ```yaml - name: Create syft config run: | cat > .syft.yaml <<EOF exclude: - "**/node_modules/**" - "**/vendor/**" - "**/target/**" - "**/.git/**" - "**/build/**" - "**/release/**" ... (clipped 2 lines) ``` </details> ### Solution Walkthrough: #### Before: ```yaml # .github/workflows/sbom-syft.yml jobs: generate-sbom: steps: - name: Create syft config run: | cat > .syft.yaml <<EOF exclude: - "**/node_modules/**" # ... other exclusions EOF - name: Generate SPDX SBOM (syft) uses: anchore/sbom-action@v0 with: config: .syft.yaml # ... ``` #### After: ```yaml # .github/workflows/sbom-syft.yml jobs: generate-sbom: steps: # The "Create syft config" step is removed. - name: Generate SPDX SBOM (syft) uses: anchore/sbom-action@v0 with: config: .syft.yaml # This file is now checked into the repo # ... # .syft.yaml (new file in repo) exclude: - "**/node_modules/**" - "**/vendor/**" # ... other exclusions ``` <details><summary>Suggestion importance[1-10]: 7</summary> __ Why: This is a strong suggestion for improving maintainability and adhering to best practices by version-controlling configuration instead of generating it dynamically in a CI script. </details></details></td><td align=center>Medium </td></tr><tr><td rowspan=1>General</td> <td> <details><summary>Prevent shell expansion in heredoc</summary> ___ **In the <code>Create syft config</code> step, change the heredoc delimiter from <code><<EOF</code> to <code><<'EOF'</code> to prevent accidental shell expansion and make the script more robust.** [.github/workflows/sbom-syft.yml [17-27]](https://github.com/carverauto/serviceradar/pull/1976/files#diff-f79636c7ac6e657fd98f9ead92fd4ffe68b8306a9a329bb602e3d1520b8a8017R17-R27) ```diff - name: Create syft config run: | - cat > .syft.yaml <<EOF + cat > .syft.yaml <<'EOF' exclude: - "**/node_modules/**" - "**/vendor/**" - "**/target/**" - "**/.git/**" - "**/build/**" - "**/release/**" EOF ``` - [ ] **Apply / Chat**  <details><summary>Suggestion importance[1-10]: 6</summary> __ Why: This is a valid suggestion that improves the robustness of the script by preventing unintentional shell expansion in the heredoc. While there is no immediate issue, this change makes the code safer against future modifications. </details></details></td><td align=center>Low </td></tr> <tr><td align="center" colspan="2"> - [ ] More  </td><td></td></tr></tbody></table>