Our security team recently presented a daunting report revealing over 500 critical CVEs in our container systems, demanding immediate patches. However, many of these vulnerabilities are in base OS packages we don't even use or buried deep in dependencies. We're currently using Trivy in our CI pipeline, but it often highlights theoretical vulnerabilities, leading to frustrated developers who can't proceed with builds while we miss the actual threats. I'm looking for practical, real-world strategies that have worked for you in this situation:
* How do you identify what vulnerabilities truly need urgent attention versus those that can be ignored?
* Are there any tools that provide useful exploit context or EPSS scoring?
* What automations or workflows have you found effective that don't disrupt development speed?
* What base image practices can help minimize your attack surface from the outset?
I would appreciate any insights or advice you can share!
6 Answers
We don’t block builds, but we do scan using Trivy. I even created an n8n workflow that leverages local LLMs to evaluate vulnerabilities based on their context, including exposure, network segmentation, and existing security measures. The workflow flags vulnerabilities for review if needed and provides detailed summaries, recommendations, and a human-readable format for our team. It was pretty straightforward with the right tools!
Implementing CI/CD processes is key—scan before deployment or fix it afterward. It's all about minimizing disruption.
Which base OS are you using, by the way? I’ve heard that Ubuntu offers a "pro" service to help with CVE patching and kernel updates at scale, but it seems like people don't always favor it over Debian or other options.
If security is really a top priority for your team, consider using a validated clean Alpine version as your base and building your containers from scratch. This way, you can install only what's essential and automate your build process to stay compliant with SecOps. It's a decent initial effort but pays off in the long run!
We switched to Distroless base images to cut through all the OS-level noise. It really helps to focus on vulnerabilities that matter instead of wasting time on libraries that aren't even being used. Also, you can configure Trivy to ignore 'unfixed' vulnerabilities; otherwise, you'll continue blocking builds over issues that can't be patched yet—which isn't ideal for team morale!
Unfixed vulnerabilities? Straight to the penalty box!
Start with scanning but avoid blocking right away. After giving it a month, you can consider turning on blocking—just don’t block issues that can’t be fixed.
This sounds like a hefty task, but honestly, one person could handle it in a single day!