Skip to content

.trivyignore File for the Project #81

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Nov 10, 2025
Merged

.trivyignore File for the Project #81

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
9 changes: 9 additions & 0 deletions .trivyignore
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
# Critical issues
AVD-AWS-0104

# High issues
AVD-DS-0002
AVD-DS-0019

# Medium issues
AVD-DS-0013
Comment on lines +1 to +9
Copy link

@coderabbitai coderabbitai bot Nov 10, 2025

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🔴 Critical

🧩 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-0013

To 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

  1. Trivy integration test data / built-in misconfigs (AVD-DS-0002). [4]
  2. Trivy docs / misconfiguration scanning (explanation of DS checks). [2]
  3. 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.