I've been exploring our container supply chain and it's quite alarming. We pull base images from Docker Hub and npm packages from uncertain sources, plus our build process lacks visibility into what's actually included. Recently, during a security audit, they asked for signed Software Bill of Materials (SBOMs), and we had nothing to provide. We also had no provenance attestation in place. With some of our base images having over 500 Common Vulnerabilities and Exposures (CVEs) due to unnecessary bloated components, I'm curious—what steps are others taking to ensure they're not just operating on 'trust but don't verify'? Are you signing everything? How can we effectively audit this at scale?
7 Answers
Honestly, we rely on tools like Semgrep and Trivy within our GitHub Actions to keep potentially harmful code in check. It’s not a foolproof system, but it keeps most of my worries at bay. Plus, here are some rules we use for Semgrep in case you’re interested: it scans for known Docker patterns and other vulnerabilities to help bolster our security.
We either grab base images from trusted sources like Oracle or AWS, or we build our own from scratch. We have a robust image pipeline where we apply configuration management tools, ensure vulnerability scans, and enforce strict version control for installed software. The final touch is signing our images and pushing them to an internal repository. This way, we can rebuild our images regularly and maintain a secure environment. I recommend starting with trusted images and then customizing them according to your specific security needs. It’s not always easy, but with the right setup, you can greatly enhance your security posture.
In our case, we stick to distroless images as our base. After building, we scan everything with Trivy and deploy only if it passes our security gate.
Starting with minimal setup for our containers really eased our spin-up times. We use just enough to get by without extra baggage. It's been working well so far.
First off, make sure your management is seriously committed to tackling these issues and is willing to invest in fixing the chaos. If they are, then consider bringing in a DevSecOps expert to craft a manageable plan—it’s usually a gradual process. On top of that, using common base images and multi-stage builds can streamline security. For Node apps, you could maintain a base node container and keep build dependencies minimal. Regularly review CVEs, and if you’re uncertain about an upstream source, prefer using versioning with git hashes. Automate updates to keep your images secure and up-to-date. That approach can help mitigate risk a lot!
Thanks for the detailed breakdown! Super helpful.
Great pointers! Also, getting familiar with using a consistent base image makes a big difference.
Using a tool like Chainguard can be a lifesaver. If outsourcing is an option, definitely consider handing over the security mess to a vendor. Otherwise, leverage your CI tools to track artifacts and implement some SAST/DAST solutions for security checks.
Sounds like a smart move! We'll look into that vendor option.
I heard they might be launching a secure artifact store soon, which would be a game changer!
Have you considered the potential risks with your compiler and hardware as well? There are some really interesting angles on this in the paper "Reflections on Trusting Trust" where the author dives into the depths of trusting your build chain and tools.
That paper is fascinating! Definitely diving down that rabbit hole.
Totally agree, it's a deeper issue than we're often led to believe.
Sounds like a solid process! Just be cautious; it can sometimes feel like a lot of work—like you’re in a perpetual game of catch-up with vulnerabilities.