.trivyignore File for the Project #81
Conversation
tmikula-dev
requested review from
ABMC831,
Zejnilovic and
oto-macenauer-absa
as code owners
WalkthroughA new Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Possibly related issues
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
|
Trivy has completed a full security repository scan ✅ You can find the analysis results for this PR branch on this overview.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
| # Critical issues | ||
| AVD-AWS-0104 | ||
|
|
||
| # High issues | ||
| AVD-DS-0002 | ||
| AVD-DS-0019 | ||
|
|
||
| # Medium issues | ||
| AVD-DS-0013 |
There was a problem hiding this comment.
🧩 Analysis chain
Add justification, expiration dates, and tracking for each suppressed vulnerability.
Suppressing security vulnerabilities—especially critical and high severity ones—without documentation is risky. The file lacks:
- Justification: Why is each vulnerability being suppressed? Is it a false positive, accepted risk, or mitigated elsewhere?
- Expiration/review dates: When should these suppressions be re-evaluated?
- Tracking: Links to issues or tickets documenting the decision and any planned remediation.
Without this context, future maintainers cannot assess whether these suppressions remain valid.
Apply this diff to add structured documentation:
# Critical issues
-AVD-AWS-0104
+# AVD-AWS-0104: [Brief description of vulnerability]
+# Reason: [Why suppressed - false positive/accepted risk/mitigated]
+# Tracking: [Link to issue/ticket]
+# Review by: [YYYY-MM-DD]
+AVD-AWS-0104
# High issues
-AVD-DS-0002
-AVD-DS-0019
+# AVD-DS-0002: [Brief description]
+# Reason: [Why suppressed]
+# Tracking: [Link to issue/ticket]
+# Review by: [YYYY-MM-DD]
+AVD-DS-0002
+
+# AVD-DS-0019: [Brief description]
+# Reason: [Why suppressed]
+# Tracking: [Link to issue/ticket]
+# Review by: [YYYY-MM-DD]
+AVD-DS-0019
# Medium issues
-AVD-DS-0013
+# AVD-DS-0013: [Brief description]
+# Reason: [Why suppressed]
+# Tracking: [Link to issue/ticket]
+# Review by: [YYYY-MM-DD]
+AVD-DS-0013To understand what you're suppressing, search for details on these specific vulnerability IDs:
🌐 Web query:
Trivy AVD-AWS-0104 vulnerability details
💡 Result:
Summary — AVD-AWS-0104
- ID: AVD-AWS-0104 (aka aws-vpc-no-public-egress-sgr). [1]
- Severity: CRITICAL. [1]
- Short description: An egress security-group rule allows traffic to 0.0.0.0/0 (unrestricted egress to the public Internet). [1][2]
- Impact: Resources can egress data to the Internet unexpectedly (data exfiltration, unexpected external access, broader attack surface). [1][2]
- Cause: Security group egress rule uses an unrestricted CIDR (e.g., "0.0.0.0/0" or "::/0") or otherwise permits egress to multiple public internet addresses. [1][2]
- Recommended remediation: restrict the egress CIDR to the minimum required IP range(s) or use more specific network controls (NAT/egress gateways, proxy, centralized egress). Update the security-group rule to a tighter CIDR or remove unnecessary open egress. [1][3]
- Examples: insecure — security_group_rule with cidr_blocks = ["0.0.0.0/0"]; secure — replace with a specific CIDR (example: 10.0.0.0/16 or a single host). [1][2]
References
- Rule documentation / explanation (cfsec / Trivy rule): avd-aws-0104 (no-public-egress-sgr). [1]
- Rule metadata/source code (rule registration and text). [2]
- Practical guidance / remediation examples in Trivy / IaC scanning writeups. [3]
If you want, I can fetch the official AVD page and paste the exact examples and JSON/Terraform snippets.
🌐 Web query:
Trivy AVD-DS-0002 AVD-DS-0019 AVD-DS-0013 vulnerability details
💡 Result:
I found authoritative details for AVD-DS-0002 and AVD-DS-0013 but could not locate a public AVD entry for AVD-DS-0019 — do you want me to keep searching or check a local Trivy/AVD copy you have?
-
AVD-DS-0002 — "Image user should not be 'root'": Trivy flags Dockerfiles/images that do not specify a non-root USER. Severity: HIGH. Recommended action: add a non-root USER instruction to the Dockerfile. See Trivy test data / AVD reference. [1][2]
-
AVD-DS-0013 — "RUN should not be used to change directory": Trivy flags RUN instructions that use cd (e.g.
RUN cd /home && mkdir app) and recommends using WORKDIR instead for readability/maintainability. Severity: MEDIUM (best-practice misconfiguration). See Trivy documentation / examples referencing AVD-DS-0013. [3]
Sources
- Trivy integration test data / built-in misconfigs (AVD-DS-0002). [4]
- Trivy docs / misconfiguration scanning (explanation of DS checks). [2]
- Trivy/Hadolint example describing AVD-DS-0013 and recommending WORKDIR. [3]
(If you want, I can: 1) continue searching specifically for AVD-DS-0019; 2) fetch the full AVD pages for each ID; or 3) show remediation examples/patch snippets.)
Add justification, expiration dates, and tracking for each suppressed vulnerability.
Suppressing security vulnerabilities—especially critical and high severity ones—without documentation is risky. The suppressions concern:
- AVD-AWS-0104 (CRITICAL): Unrestricted AWS security group egress allowing traffic to 0.0.0.0/0, creating a data exfiltration and broader attack surface risk
- AVD-DS-0002 (HIGH): Docker image user should not be 'root'
- AVD-DS-0019: Could not be verified in public sources; clarify what this vulnerability is
- AVD-DS-0013 (MEDIUM): Docker best-practice issue (RUN should use WORKDIR instead of
cd)
For each suppression, document:
- Why it's suppressed (false positive, accepted risk, mitigated control, or tracked issue)
- Expiration/review date for re-evaluation
- Link to tracking issue or decision record
Without this, future maintainers cannot assess validity—especially critical for the CRITICAL and HIGH severity items.
🤖 Prompt for AI Agents
In .trivyignore around lines 1 to 9, the listed suppressed vulnerabilities
(AVD-AWS-0104, AVD-DS-0002, AVD-DS-0019, AVD-DS-0013) lack justification,
expiration/review dates, and links to tracking/decision records; add for each
suppressed ID a short justification (false positive / accepted risk / mitigated
control / tracked issue), a clear expiration or next-review date, the severity,
and a link to a tracking issue or decision record (e.g., issue/PR or ADR) and
the reviewer name/date; ensure the format is consistent (one line per
suppression or a small comment block) so future maintainers can assess and
re-evaluate the suppression.
miroslavpojer
left a comment
miroslavpojer
left a comment
There was a problem hiding this comment.
Approving to allow tests with Aquasec.
Release Notes:
Summary by CodeRabbit