SBOMs, generated for you

Every container you ship already has a software bill of materials, whether you write one or not. It is the list of components inside the image. Regulations such as the EU Cyber Resilience Act expect you to keep that list, and you need it the instant a new vulnerability appears and someone asks which of your devices are affected.

The trouble is that producing and attaching an SBOM to every artifact is one more step, and steps get skipped. A missing SBOM is a blind spot: no component inventory, no vulnerability matching, a hole in your compliance coverage that you tend to notice at the worst possible time.

So we closed the gap. From today, when you publish a container without an SBOM, Meshanics generates one for you.

It appears right on the artifact, clearly labeled so you always know where it came from. From there it flows into everything that already reads an SBOM: continuous vulnerability matching across your fleet, and your compliance coverage, which now climbs on its own instead of waiting for someone to remember.

A few things worth knowing.

Your own SBOM always wins. If you attach one, we never overwrite it. Generation is only a fallback for artifacts that arrive without one, and producing the SBOM in your build is still the most precise option, because your build sees exactly what went into the image.

We are careful with your image. To generate the SBOM we read the image and then remove it. Nothing about your image is retained. We record the component inventory, never the contents.

It is a standard document. The generated SBOM is CycloneDX, the same format you would attach yourself, so it works with whatever else you already do with it.

Models, configs and firmware are not container images, so they are handled on their own terms. For a model, attach the SBOM to the runtime container that loads it, which is what vulnerability tracking follows.

If you run containers on a fleet and have ever found a missing SBOM at exactly the wrong moment, that is now one less thing to carry.