List and Table updates to container-vulnerability-scanning-ci-shift-left-security article

Author: webstackdev

src/content/articles/container-vulnerability-scanning-ci-shift-left-security/index.mdx

@@ -24,7 +24,7 @@ This is what compliance-driven security looks like. Scanning tools get enabled b
 The fix isn't better scanners — it's abandoning compliance theater for actual security outcomes. A scanner that reports 200 unfixable CVEs trains developers to ignore all alerts. A scanner configured to report 3 fixable criticals with clear remediation steps gets those vulnerabilities fixed the same day.
 </Callout>
 
-The difference between scanning that works and scanning that gets disabled comes down to three things: policy configuration that produces actionable findings, base image choices that eliminate CVEs at the source, and documented processes for the vulnerabilities you genuinely can't fix yet. This article uses Trivy as the reference implementation — it's become the de facto open-source choice for CI scanning due to its speed and breadth of coverage.
+<Highlighter>The difference between scanning that works and scanning that gets disabled comes down to three things:</Highlighter> policy configuration that produces actionable findings, base image choices that eliminate CVEs at the source, and documented processes for the vulnerabilities you genuinely can't fix yet. This article uses Trivy as the reference implementation — it's become the de facto open-source choice for CI scanning due to its speed and breadth of coverage.
 
 ## Policy Configuration
 
@@ -58,7 +58,10 @@ Not every pipeline stage needs the same policy. Teams that apply the same strict
 Tiered gates fix this by matching strictness to context:
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:mb-12",
+  }}
   items={[
     {
       lead: "Development branches:",
@@ -90,35 +93,35 @@ The key insight is that you're not lowering security by being permissive on dev
 Some vulnerabilities can't be fixed immediately. You need a process for handling these legitimately rather than pretending they don't exist. The workflow has four steps:
 
 <List
-  variant="check-icons-list"
+  variant="card-grid-list"
   items={[
     {
-      lead: "Developer request:",
-      text: "Add the CVE to `.trivyignore` with a comment explaining why, a ticket reference, and an expiration date.",
+      lead: "Developer request",
+      text: 'Add the CVE to <span class="font-mono">.trivyignore</span> with a comment explaining why, a ticket reference, and an expiration date.',
     },
     {
-      lead: "Security review:",
+      lead: "Security review",
       text: "Is the vulnerable code path reachable? Is there a workaround? What's the actual risk in your context?",
     },
     {
-      lead: "Approval and tracking:",
+      lead: "Approval and tracking",
       text: "Document the exception centrally with calendar reminders for the expiration date.",
     },
     {
-      lead: "Periodic review:",
+      lead: "Periodic review",
       text: "Monthly check whether fixes are now available or risk profiles have changed.",
     },
   ]}
 />
 
-```text title=".trivyignore"
-# CVE in test dependency, not shipped to production
-CVE-2023-12345
+```gitignore title=".trivyignore"
+  # CVE in test dependency, not shipped to production
+  CVE-2023-12345
 
-# No fix available, risk accepted until Q2 2024
-# Ticket: SEC-123
-# Expires: 2024-06-30
-CVE-2023-11111
+  # No fix available, risk accepted until Q2 2024
+  # Ticket: SEC-123
+  # Expires: 2024-06-30
+  CVE-2023-11111
 ```
 Code: Trivy ignore file with documented exceptions.
 
@@ -197,7 +200,7 @@ The tradeoff is debuggability. With no shell in the production image, you can't
 Not every CVE can be fixed immediately. Here are the scenarios you'll encounter:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "No patch available:",
@@ -214,6 +217,8 @@ Not every CVE can be fixed immediately. Here are the scenarios you'll encounter:
   ]}
 />
 
+The key principle for all these scenarios: document and track, don't pretend they don't exist. An acknowledged risk with compensating controls is better than an ignored vulnerability that nobody's watching.
+
 <Download
   resource="container-vulnerability-scanning-ci-shift-left-security"
   title="Download the Container Security Guide"
@@ -234,6 +239,4 @@ Not every CVE can be fixed immediately. Here are the scenarios you'll encounter:
   ]}
 />
 
-The key principle for all these scenarios: document and track, don't pretend they don't exist. An acknowledged risk with compensating controls is better than an ignored vulnerability that nobody's watching.
-
 The goal isn't zero CVEs or passing audits — it's reducing actual risk. A team with 15 documented exceptions and a 10-day remediation SLA has better security posture than a team with 200 ignored findings and a scanner that "passes" because nobody runs it. Measure what matters: time-to-remediation, bypass rates, and trend direction. The checkbox is irrelevant if the vulnerabilities ship anyway.