I've been struggling with how to provide the security team with clear visibility into the supply chains of our base images. Most container registries seem opaque, making it tough to analyze what's inside. We're currently using Trivy scans, but they only identify known vulnerabilities (CVEs) and don't tell us about the build processes or dependencies within images like ubuntu:22.04 or node:18-alpine.
I've also explored SBOMs (Software Bill of Materials), but many of the images we use lack them, and when they do exist, they're often unsigned or incomplete. I'm looking for strategies to verify what's actually included in our base layers.
4 Answers
The truth is, you'll struggle with most public images since they lack meaningful SBOMs or build attestations. You might want to try using tools like Minimus for minimal base images with signed SBOMs or resort to generating local SBOMs with Syft. Also, make sure to check if your registry supports cosign signatures for additional verification.
At my company, we use RHEL and have created our own RHEL8 base image from our package repositories. We keep things straightforward and ensure our containerized applications are built on this trusted base. This way, we maintain better control over our environments.
If you're relying on public images, it's a risky move! Those images are built in vendor CI environments that lack transparency. Instead, consider building your own images from scratch or from trusted vendors that provide signed SBOMs. This can help mitigate supply chain attacks and ensure you're aware of what’s in your images.
Building your own images is often the best route. However, if that's not feasible for you, you can SSH into the container and inspect the contents directly. It’s not ideal, but it allows you to at least get a look around.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures