slimslenders

I think this is very true. Tool search tools can be model agnostic. And programmatic tool calling really just needs a code sandbox tool. We've provided some examples of these patterns on top of a local docker engine (oss project is here https://github.com/docker/mcp-gateway/ and blog is https://www.docker.com/blog/dynamic-mcps-stop-hardcoding-you...).

Community MCP servers available as Docker images are also being listed here https://hub.docker.com/catalogs/mcp

... chiming in as one of the co-creators of this feature. The ability to quickly ascertain whether a change will increase security debt ends up having a positive impact on code reviews too. It's useful to have a spotlight shining on these particular pull requests.

Indeed, there's this curious fact that you can update the FROM instruction to be repos:tag@sha256:... In other words, you can leave the tag in the name even though the next docker build will use the digest sha. I do agree with you - you have to be able to go into the Dockerfile and switch to a new tag by simply editing your FROM instruction directly. In our current implementation, the next pull request will put the current sha into the FROM line (leaving the tag in the repo:tag@digest form) and begin monitoring that tag for updates.

Feel free to get in touch if you want to try out our tool. The support for pinning versions in run layers is just being released but happy to send you a breakdown of how that works.

Just took a look. Very cool! The generate/verify/rewrite phases are very familiar :). I guess we sort of moved rewrite/verify into a PullRequest/CheckRun. Would it make sense to run verify and rewrite as a pre-commit hook too?

will send when we've got some data. Had been wanting to reach out to you about an idea for an automated check anyway.

I came across your article on security updates when I was researching this. Thanks for writing it - it was super helpful. One of the sub goals for us is to quantify the lag that you've observed here. We're also reviewing an automated check that would flag times when an apt upgrade would be material. This is very much based on your bad arguments 1 through 4.

Keeping the FROM readable is indeed a challenge. We thought about a Dockerfile comment to add the context that developers need. There's this peculiar aspect of docker image naming where you can include both a tag and a digest (repository:tag@digest) too. I also think that the pull request is a good opportunity to give good context about where you are now, and what the proposed upstream changes are really bringing.

Thanks! And ya, we found the spec! We are in the middle of adding a feature to help devsecops teams notice when org.opencontainers.image.revision and org.opencontainers.image.source labels are missing (those were the first two which we considered mandatory to ensure that downstream admission controllers can validate checks that are indexed by sha). I had not realized that you were proposing further annotations for base images here. That sounds really promising. I think having a standard set of information available in the images is critical.

Thank you, and yes. I love that idea of a distance metric. I think you're also pointing out that distroless images can end up increasing this developer distance, right? I was originally drawn to the idea of distroless images as a way to reduce vulnerabilities. However, staying up to date with a well maintained distro is effective too.

Ya, it's similar. We needed to add an initial pinning PR, a vulnerability and change log comparison, and scanning for unsupported tags. We also added support for private registries so that we could use the same pattern for non-official images. But the inspiration came from Official image repositories.