-
-
Notifications
You must be signed in to change notification settings - Fork 263
Added Trivy scan in CI/CD pipeline #1208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Add Trivy scanning for staging and production Docker images
Summary by CodeRabbit
WalkthroughThe changes introduce two new GitHub Actions jobs, Changes
Assessment against linked issues
📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (2)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (4)
.github/workflows/run-ci-cd.yaml (4)
231-255: Approve and Suggest: New Scan Job for Staging ImagesThe new
scan-staging-imagesjob is well integrated. It correctly logs in to Docker Hub and invokes the Trivy action to scan both the backend and frontend staging images for vulnerabilities, exiting with code 1 if any 'HIGH' or 'CRITICAL' issues are detected. Consider externalizing theexit-codeandseverityvalues into environment variables or job parameters to simplify future adjustments.
268-268: Dependency Update: Staging Deployment JobAdding
scan-staging-imagesas a dependency for thedeploy-staging-nestjob is a good move. This ensures that deployment will only proceed if the staging images pass the Trivy scan, thereby enforcing a higher security standard.
400-424: Approve and Suggest: New Scan Job for Production ImagesThe
scan-production-imagesjob mirrors the staging scan effectively. It logs in to Docker Hub and uses the Trivy action to scan the production backend and frontend images with the appropriate severity thresholds. As with the staging job, consider parameterizing theexit-codeandseveritysettings for easier future maintenance.
436-437: Dependency Update: Production Deployment JobIncorporating
scan-production-imagesas a dependency for thedeploy-production-nestjob ensures that production deployments only occur after a successful vulnerability scan—this is a solid security enhancement.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/run-ci-cd.yaml(4 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Run frontend e2e tests
|
@arkid15r Please let me know if you had anything else in mind. |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
* Add Trivy scanning for staging and production Docker images * Update code --------- Co-authored-by: Arkadii Yakovets <[email protected]>
|
@coderabbitai suggest the possible way to fix these vulnerability found by trivy. │ Library │ Vulnerability │ Severity │ Status │ Installed Version │ Fixed Version │ Title │ |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain@Naveen-Pal Based on the vulnerabilities found by Trivy, here are the recommended ways to address each issue: 1. libldap-2.5-0 (CVE-2023-2953) - HIGHFix options:
2. perl-base (CVE-2023-31484)Fix options:
3. zlib1g (CVE-2023-45853) - CRITICAL with "will_not_fix" statusFix options:
General recommendations:
Would you like me to provide more specific advice for your Docker setup or help configure Trivy to handle these findings? 🏁 Script executed: Length of output: 186 🌐 Web query: 💡 Result: CVE-2023-2953 is a high-severity vulnerability (CVSS 7.5) affecting OpenLDAP's libldap library in Debian systems, caused by a null pointer dereference in the Affected Debian Versions
Fix ImplementationDebian has addressed this in newer releases:
Workarounds (For Unpatched Systems)
Vulnerability VerificationCheck installed version: dpkg -l | grep 'openldap'Vulnerable if output shows:
Debian maintainers have committed fixes in upstream versions 2.5.14+ and 2.6.4+, with backport commits available in the Debian Security Tracker[4][16]. Users requiring immediate mitigation should consider upgrading to Trixie/Sid or compiling from patched sources until official updates are released for stable branches. Citations:
🌐 Web query: 💡 Result: CVE-2023-31484 is a high-severity vulnerability (CVSS 8.1) in Perl's CPAN.pm module that fails to verify TLS certificates when downloading distributions over HTTPS, enabling man-in-the-middle attacks and potential code execution. Here's how to address it in Debian systems: Fixed Versions by Debian Release
Remediation Steps
sudo apt-get update
sudo apt-get install --only-upgrade perl-base
dpkg -l perl-base | grep "5.32.1-4+deb11u4" # For Bullseye
dpkg -l perl-base | grep "5.36.0-7+deb12u1" # For BookwormThe vulnerability was patched in CPAN.pm 2.35+ by adding mandatory TLS certificate verification through HTTP::Tiny's Systems running older Debian releases like Buster (10) won't receive official fixes and should upgrade to a supported OS version. Cloud/container users should rebuild images using patched base layers from official Debian repositories[6][8]. Citations:
🌐 Web query: 💡 Result: CVE-2023-45853 in zlib1g's "will_not_fix" status indicates the maintainers have determined no patch will be released for this vulnerability in the current packaging configuration. This decision typically occurs when: Key reasons for "will_not_fix" status:
Workaround strategiesFor systems showing this status in Trivy/Grype scans:
Debian maintainers assert zlib1g isn't vulnerable in standard configurations because:
When overriding "will_not_fix" status is appropriateUpgrade paths exist for specific implementations: # For Chainguard-based systems
apk upgrade 'zlib>=1.3-r1'
# Python environments using vulnerable zlib versions
conda install -c conda-forge python=3.12.1 # Contains backported fixMonitor: Track upstream zlib developments while maintaining current mitigations[1][3]. Security teams should periodically reassess the risk profile using EPSS scores (current 0.6% exploit probability)[5]. Citations:
1. libldap-2.5-0 (CVE-2023-2953) - HIGHThis is a null pointer dereference vulnerability in OpenLDAP's Fix options:
2. perl-base (CVE-2023-31484)Interesting - your installed version (5.36.0-7+deb12u1) should already be the fixed version for Debian 12 (Bookworm). This could be a false positive in Trivy scanning. Fix options:
3. zlib1g (CVE-2023-45853) - CRITICAL with "will_not_fix" statusThe "will_not_fix" status exists because the vulnerable component (MiniZip) isn't included in standard Debian zlib packages, according to Debian maintainers. Fix options:
General recommendations:
Would you like me to help with implementing any of these solutions in your specific Dockerfiles? Code Analysis ToolsTool Analysis ResultsCodeRabbit ran static analysis tools on your files and found the following: No specific issues were found in your files. You can proceed with your changes. |
|
@arkid15r, |
I prefer more flexible solution -- use |
* Add Trivy scanning for staging and production Docker images * Update code --------- Co-authored-by: Arkadii Yakovets <[email protected]>



Resolves #1205