Add SBOM workflow, sample app, and SBOMs#1
Conversation
Add a GitHub Actions pipeline (.github/workflows/sbom.yml) to generate CycloneDX SBOMs (JSON/XML), upload artifacts, run Trivy (table + SARIF), upload SARIF to GitHub Security, post a PR summary (component count + Trivy output), fail on CRITICAL/HIGH vulnerabilities, and attach SBOMs to releases. Also add a minimal Flask app (app.py), requirements.txt and requirements-dev.txt (cyclonedx-bom), .gitignore updates (venv, caches, CI outputs), example SBOM outputs (sbom.json, sbom1.json), and expand README with local setup and CI behavior.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (2)
📝 WalkthroughWalkthroughAdds a simple Flask app and CI pipeline that generates CycloneDX SBOMs, runs Trivy filesystem scans, uploads SARIF and SBOM artifacts, posts PR comments with scan summaries, and attaches SBOMs to releases. Supporting files and pre-generated SBOMs are included. (50 words) Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant GH as GitHub (Actions)
participant Runner as Actions Runner
participant CycloneDX as CycloneDX tool
participant Trivy as Trivy scanner
participant GH_Sec as GitHub Security (SARIF)
participant Release as GitHub Release
Dev->>GH: push / open PR / create release
GH->>Runner: start workflow (sbom-and-scan)
Runner->>CycloneDX: generate SBOMs from `requirements.txt` (sbom.json, sbom.xml)
Runner->>Trivy: run filesystem scan -> produce `trivy-results.txt`, `trivy.sarif`
Trivy-->>Runner: scan results
Runner->>GH_Sec: upload `trivy.sarif` (SARIF)
Runner->>GH: upload SBOM artifact (sbom-<sha>)
alt on PR
Runner->>GH: post PR comment with SBOM component count + truncated Trivy output
end
alt on release
GH->>Runner: start attach-sbom-to-release job (downloads artifact)
Runner->>Release: upload `sbom.json`, `sbom.xml` as release assets
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool. What Enabling Code Scanning Means:
For more information about GitHub Code Scanning, check out the documentation. |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| @@ -0,0 +1,3 @@ | |||
| requests==2.31.0 | |||
Check warning
Code scanning / Trivy
requests: subsequent requests to the same host ignore cert verification Medium
| @@ -0,0 +1,3 @@ | |||
| requests==2.31.0 | |||
Check warning
Code scanning / Trivy
requests: Requests vulnerable to .netrc credentials leak via malicious URLs Medium
| @@ -0,0 +1,3 @@ | |||
| requests==2.31.0 | |||
| flask==3.0.0 | |||
Check notice
Code scanning / Trivy
flask: Flask: Information disclosure via improper caching of session data Low
🧾 SBOM & Security Scan ResultsCommit: 📦 CycloneDX SBOM47 components inventoried in SBOM. 🔍 Trivy Vulnerability Scan (CRITICAL & HIGH) |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (2)
.gitignore (1)
64-67: Treat generated SBOM files consistently.Lines 64-67 ignore
sbom.xml, butREADME.mdLines 34-35 ask contributors to regenerate bothsbom.jsonandsbom.xml. Becausesbom.jsonis tracked at the repo root, following the docs always rewrites a checked-in file. Either ignore both outputs or move the sample SBOMs out of the root.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.gitignore around lines 64 - 67, The repo currently ignores sbom.xml but not sbom.json, causing regenerated sbom.json to overwrite the tracked file; update the .gitignore to treat generated SBOMs consistently by adding sbom.json alongside sbom.xml (or alternatively move example/sample SBOM files out of the repo root and update README.md accordingly); locate the .gitignore entries for "sbom.xml" and add "sbom.json" (or adjust README.md to point to a non-root sample location) so following the README's regenerate instructions doesn't modify a committed file.requirements-dev.txt (1)
1-1: Pincyclonedx-bomfor reproducible CI output.Line 1 leaves the SBOM generator floating, so the same commit can emit different BOM structure/metadata or break the
cyclonedx-pyinvocation as upstream changes. Since the workflow publishes these files, pin a known-good version and upgrade it deliberately.Suggested change
-cyclonedx-bom +cyclonedx-bom==7.2.2🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@requirements-dev.txt` at line 1, Pin the cyclonedx-bom dev dependency in requirements-dev.txt instead of leaving it unversioned: replace the floating "cyclonedx-bom" entry with a specific, tested version specifier (e.g., cyclonedx-bom==<known-good-version> or a constrained range) so CI produces reproducible SBOM output; update the requirements entry for cyclonedx-bom and, if desired, add a comment noting the chosen version and where to change it when upgrading.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/sbom.yml:
- Around line 11-14: The workflow currently grants contents: write to the whole
sbom-and-scan job; change the sbom-and-scan job permissions to contents: read so
scans, SBOM generation and third-party actions like aquasecurity/trivy-action
run read-only, and move the release upload logic into a new separate job (e.g.,
upload-sbom-release) that runs only on release events and is given permissions:
contents: write; ensure the new upload job consumes the SBOM artifact produced
by sbom-and-scan and contains the existing "upload SBOM to release" step so only
that job has write access.
- Around line 55-73: The workflow uses the unpinned GitHub Action reference
aquasecurity/trivy-action@master in the job steps "Run Trivy vulnerability scan"
and "Trivy SARIF report"; replace both floating refs with a full commit SHA
(e.g., 57a97c7e7821a5776cebc9bb87c984fa69cba8f1 for v0.35.0) so the uses:
entries are SHA-pinned, and add a note to keep SHA updates via
Dependabot/Renovate to automate future upgrades and avoid supply-chain risks.
- Around line 55-63: The Trivy step currently writes a table and is later parsed
with an incorrect grep; change the Trivy action invocation (the step named "Run
Trivy vulnerability scan" that uses aquasecurity/trivy-action@master and writes
trivy-results.txt) to set exit-code: 1 so Trivy itself fails on findings and add
continue-on-error: true to allow the workflow to continue; ensure the step has
an id (e.g., trivy_scan) and remove the fragile grep-based check, then gate the
final failing job/step on the Trivy step outcome by checking
steps.trivy_scan.outcome == 'failure' (instead of parsing trivy-results.txt).
- Around line 39-42: Replace the cyclonedx-py invocation that uses the
environment analyzer with the requirements analyzer so build/dev tooling isn't
captured: change the two commands using "cyclonedx-py environment -o sbom.json"
and "cyclonedx-py environment -o sbom.xml" to use "cyclonedx-py requirements -i
requirements.txt -o sbom.json" and "cyclonedx-py requirements -i
requirements.txt -o sbom.xml" respectively, ensuring the SBOM is generated from
the declared dependencies rather than the entire CI environment.
In `@requirements.txt`:
- Line 1: Update the pinned requests dependency to a non-vulnerable version by
changing the entry requests==2.31.0 in requirements.txt to at least
requests==2.32.4 (e.g., requests==2.32.4) so the CVE-2024-35195 and
CVE-2024-47081 fixes are included.
---
Nitpick comments:
In @.gitignore:
- Around line 64-67: The repo currently ignores sbom.xml but not sbom.json,
causing regenerated sbom.json to overwrite the tracked file; update the
.gitignore to treat generated SBOMs consistently by adding sbom.json alongside
sbom.xml (or alternatively move example/sample SBOM files out of the repo root
and update README.md accordingly); locate the .gitignore entries for "sbom.xml"
and add "sbom.json" (or adjust README.md to point to a non-root sample location)
so following the README's regenerate instructions doesn't modify a committed
file.
In `@requirements-dev.txt`:
- Line 1: Pin the cyclonedx-bom dev dependency in requirements-dev.txt instead
of leaving it unversioned: replace the floating "cyclonedx-bom" entry with a
specific, tested version specifier (e.g., cyclonedx-bom==<known-good-version> or
a constrained range) so CI produces reproducible SBOM output; update the
requirements entry for cyclonedx-bom and, if desired, add a comment noting the
chosen version and where to change it when upgrading.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 29b1717d-407d-4faa-b377-661091f02269
📒 Files selected for processing (8)
.github/workflows/sbom.yml.gitignoreREADME.mdapp.pyrequirements-dev.txtrequirements.txtsbom.jsonsbom1.json
| - name: Run Trivy vulnerability scan | ||
| uses: aquasecurity/trivy-action@master | ||
| with: | ||
| scan-type: fs | ||
| scan-ref: . | ||
| format: table | ||
| output: trivy-results.txt | ||
| exit-code: 0 # we handle failure manually below | ||
| severity: CRITICAL,HIGH | ||
|
|
||
| # ── 7. Trivy — output SARIF for GitHub Security tab ────────── | ||
| - name: Trivy SARIF report | ||
| uses: aquasecurity/trivy-action@master | ||
| with: | ||
| scan-type: fs | ||
| scan-ref: . | ||
| format: sarif | ||
| output: trivy.sarif | ||
| severity: CRITICAL,HIGH |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/sbom.yml | sed -n '55,73p'Repository: mohamedaminehamdi/cyclonedx-python-test
Length of output: 825
🏁 Script executed:
# Check the full workflow to understand permissions
head -50 .github/workflows/sbom.ymlRepository: mohamedaminehamdi/cyclonedx-python-test
Length of output: 1480
🏁 Script executed:
# Look for permissions section in the file
rg "permissions:" .github/workflows/sbom.yml -A 5Repository: mohamedaminehamdi/cyclonedx-python-test
Length of output: 269
🌐 Web query:
GitHub Actions best practices pin to commit SHA immutable ref third-party actions security
💡 Result:
The best practice for securing third-party GitHub Actions is to pin them to a full-length commit SHA, which provides an immutable reference. This prevents supply chain attacks where malicious code could be injected via tag updates, as tags can be force-pushed to new commits, but SHAs cannot (requiring a SHA-1 collision, which is computationally infeasible). Example usage: - uses: actions/checkout@f43a0e5 # v4.1.7 How to find the SHA: 1. Go to the action's repository (e.g., https://github.com/actions/checkout). 2. Switch to the desired tag/branch via the branch dropdown. 3. Copy the full commit SHA from the URL or page. Additional best practices: - Verify the SHA is from the official repository, not a fork. - Use Dependabot or Renovate to automate updates to new SHAs when ready. - For trusted first-party actions (e.g., from GitHub), major version tags like @v4 may be acceptable, but SHA pinning is still recommended. - Enable GitHub policies to enforce SHA pinning at repo/org/enterprise level. - Audit action source code and minimize permissions (e.g., read-only GITHUB_TOKEN). - Use tools like OpenSSF Scorecard or StepSecurity for risk assessment. GitHub officially states: "Pinning an action to a full-length commit SHA is currently the only way to use an action as an immutable release." Policies added in 2025 enforce this and allow blocking risky actions.
Citations:
- 1: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions
- 2: https://docs.github.com/en/actions/reference/security/secure-use
- 3: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 4: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
- 5: https://www.nearform.com/insights/why-you-should-pin-your-github-actions-by-commit-hash
- 6: https://stackoverflow.com/questions/78903499/how-do-i-pin-an-action-to-a-specific-sha
- 7: https://www.codewrecks.com/post/github/github-sha-pinning/
- 8: https://dev.to/ciberconscientes/github-actions-why-you-should-pin-your-actions-to-a-specific-version-1513
- 9: https://medium.com/@adan.alvarez/github-actions-and-the-pinning-problem-what-100-security-projects-reveal-54a3a9dcc902
🌐 Web query:
aquasecurity trivy-action version pinning recommendations
💡 Result:
Aqua Security's trivy-action strongly recommends pinning to a full commit SHA rather than a version tag to prevent supply chain attacks where tags can be force-pushed to malicious commits, as occurred in the March 2026 compromise affecting most tags except 0.35.0. Key recommendations from official sources: - Pin the action itself: uses: aquasecurity/trivy-action@57a97c7 (v0.35.0 safe commit) - Internally, since PR #456 (merged Apr 2025), it pins setup-trivy to e6c2c5e321ed9123bda567646e2f96565e34abe1 (equiv to v0.2.4), enabling SHA allowlisting. - Safe versions post-compromise: trivy-action v0.35.0, setup-trivy v0.2.6, Trivy binary v0.69.3 or earlier. - GitHub and Aqua advise: "Pin GitHub Actions to full, immutable commit SHA hashes — not mutable version tags." Example workflow: - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-action@57a97c7 with: image-ref: 'your-image' format: 'table' exit-code: '1' Use tools like Dependabot/Renovate for automated SHA updates. Review runs from Mar 19-20 2026 for compromise indicators and rotate secrets if affected.
Citations:
- 1: Pin aquasecuriy/setup-trivy to hash instead of tag aquasecurity/trivy-action#456
- 2: Allow pinning setup-trivy by hash aquasecurity/trivy-action#423
- 3: https://www.aquasec.com/blog/trivy-supply-chain-attack-what-you-need-to-know/
- 4: https://github.com/aquasecurity/trivy-action
- 5: GHSA-69fq-xp46-6x23
- 6: https://github.com/aquasecurity/trivy-action/releases
- 7: aquasecurity/trivy-action is compromised aquasecurity/trivy-action#541
- 8: https://github.com/aquasecurity/trivy-action/blob/master/action.yaml
Pin aquasecurity/trivy-action to a full commit SHA.
Lines 56 and 67 use aquasecurity/trivy-action@master, which floats to unpinned code and is extremely risky. GitHub and Aqua Security both require SHA pinning as the only secure approach. Trivy-action experienced a supply-chain compromise in March 2026 where tags were force-pushed to malicious commits; using @master leaves this workflow vulnerable to such attacks. Combined with the write-capable permissions in this job, the blast radius is significant. Pin to a full commit SHA such as 57a97c7e7821a5776cebc9bb87c984fa69cba8f1 (v0.35.0) and use Dependabot or Renovate to automate SHA updates.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/sbom.yml around lines 55 - 73, The workflow uses the
unpinned GitHub Action reference aquasecurity/trivy-action@master in the job
steps "Run Trivy vulnerability scan" and "Trivy SARIF report"; replace both
floating refs with a full commit SHA (e.g.,
57a97c7e7821a5776cebc9bb87c984fa69cba8f1 for v0.35.0) so the uses: entries are
SHA-pinned, and add a note to keep SHA updates via Dependabot/Renovate to
automate future upgrades and avoid supply-chain risks.
| @@ -0,0 +1,3 @@ | |||
| requests==2.31.0 | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, find and read the requirements.txt file
git ls-files | grep -i requirementsRepository: mohamedaminehamdi/cyclonedx-python-test
Length of output: 120
🏁 Script executed:
# Read the requirements.txt file to verify the actual content
cat requirements.txt 2>/dev/null || echo "File not found"Repository: mohamedaminehamdi/cyclonedx-python-test
Length of output: 126
🌐 Web query:
CVE-2024-35195 requests library vulnerability
💡 Result:
CVE-2024-35195 is a medium-severity vulnerability (CVSS 3.1 base score 5.6) in the Python Requests HTTP library, affecting versions prior to 2.32.0. It involves an always-incorrect control flow implementation (CWE-670) where, in a Requests Session, if the first request to a host uses verify=False (disabling SSL certificate verification), subsequent requests to the same host reuse the pooled connection and ignore certificate verification for the connection's lifecycle, even if verify=True is set later. This can lead to unintended man-in-the-middle attacks if applications mix verified and unverified requests. The issue was fixed in Requests 2.32.0 (released May 20, 2024) by ensuring proper handling of verify settings per request. Official GitHub advisory: GHSA-9wx4-h78v-vm56. Relevant commit: a58d7f2ffb4d00b46dca2d70a3932a0b37e22fac. Pull request: #6655. Mitigations: Upgrade to Requests >=2.32.0; avoid verify=False on first requests to hosts requiring verification; close/recreate Session after unverified requests. Distributions like SUSE, Red Hat, Fedora have backported fixes to their packages.
Citations:
- 1: https://nvd.nist.gov/vuln/detail/cve-2024-35195
- 2: https://www.suse.com/security/cve/CVE-2024-35195.html
- 3: https://www.incibe.es/en/incibe-cert/early-warning/vulnerabilities/cve-2024-35195
- 4: https://www.resolvedsecurity.com/vulnerability-catalog/CVE-2024-35195
- 5: https://nvd.nist.gov/vuln/detail/CVE-2024-35195
- 6: https://advisories.gitlab.com/pkg/pypi/requests/CVE-2024-35195
- 7: https://docs.python-requests.org/en/latest/community/updates/
- 8: https://github.com/psf/requests/blob/master/HISTORY.md
- 9: https://github.com/psf/requests/releases
🌐 Web query:
CVE-2024-47081 requests library vulnerability
💡 Result:
CVE-2024-47081 is a medium-severity vulnerability (CVSS 3.1: 5.3, AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N) in the Python Requests HTTP library (versions prior to 2.32.4). It allows leakage of .netrc credentials to third parties via maliciously crafted URLs due to a URL parsing issue, classified as CWE-522 (Insufficiently Protected Credentials). Affected versions: All releases before 2.32.4. Fixed in: Requests 2.32.4 (released June 10, 2025), via commit 96ba401c1296ab1dda74a2365ef36d88f7d144ef and PR #6965. Workaround: Set trust_env=False on Requests Session to disable .netrc usage. Example malicious URL pattern: http://example.com:`@evil.com/` (causes credentials for example.com to be sent to evil.com). Published: June 9, 2025 (NVD). GHSA: GHSA-9hjg-9r4m-mvj7. Upgrade to 2.32.4 or later. As of 2026-03-24, latest is 2.32.5.
Citations:
- 1: https://nvd.nist.gov/vuln/detail/CVE-2024-47081
- 2: https://osv.dev/vulnerability/CVE-2024-47081
- 3: https://ubuntu.com/security/CVE-2024-47081
- 4: GHSA-9hjg-9r4m-mvj7
- 5: https://github.com/psf/requests/blob/master/HISTORY.md
- 6: https://docs.python-requests.org/en/latest/community/updates/
Bump requests off the known-vulnerable pin.
Line 1 pins requests==2.31.0, which is affected by CVE-2024-35195 and CVE-2024-47081. Both are medium-severity vulnerabilities in the requests library fixed in versions 2.32.0 and 2.32.4, respectively. Upgrade to at least requests==2.32.4 to resolve both issues.
Suggested change
-requests==2.31.0
+requests==2.32.4📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| requests==2.31.0 | |
| requests==2.32.4 |
🧰 Tools
🪛 GitHub Check: Trivy
[warning] 1-1: requests: subsequent requests to the same host ignore cert verification
Package: requests
Installed Version: 2.31.0
Vulnerability CVE-2024-35195
Severity: MEDIUM
Fixed Version: 2.32.0
Link: CVE-2024-35195
[warning] 1-1: requests: Requests vulnerable to .netrc credentials leak via malicious URLs
Package: requests
Installed Version: 2.31.0
Vulnerability CVE-2024-47081
Severity: MEDIUM
Fixed Version: 2.32.4
Link: CVE-2024-47081
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@requirements.txt` at line 1, Update the pinned requests dependency to a
non-vulnerable version by changing the entry requests==2.31.0 in
requirements.txt to at least requests==2.32.4 (e.g., requests==2.32.4) so the
CVE-2024-35195 and CVE-2024-47081 fixes are included.
Update GitHub Actions workflow to generate CycloneDX SBOM from requirements.txt (avoid including dev packages) by installing only dev tooling first, then installing runtime deps for Trivy scanning. Adjust Trivy invocation to use exit-code=1 with continue-on-error and check the scan step outcome to fail the pipeline when CRITICAL/HIGH issues are found; still upload SARIF to GitHub Security. Split release logic into a separate job that downloads the SBOM artifact and attaches sbom.json/sbom.xml to the GitHub release, and update workflow permissions accordingly. Update README to document the new cyclonedx commands and add the generated sbom.json artifact.
🧾 SBOM & Security Scan ResultsCommit: 📦 CycloneDX SBOM3 components inventoried in SBOM. 🔍 Trivy Vulnerability Scan (CRITICAL & HIGH) |
2 participants
Add a GitHub Actions pipeline (.github/workflows/sbom.yml) to generate CycloneDX SBOMs (JSON/XML), upload artifacts, run Trivy (table + SARIF), upload SARIF to GitHub Security, post a PR summary (component count + Trivy output), fail on CRITICAL/HIGH vulnerabilities, and attach SBOMs to releases. Also add a minimal Flask app (app.py), requirements.txt and requirements-dev.txt (cyclonedx-bom), .gitignore updates (venv, caches, CI outputs), example SBOM outputs (sbom.json, sbom1.json), and expand README with local setup and CI behavior.
Summary by CodeRabbit
New Features
Documentation
Chores