Okay, so we just wrapped up a pretty gnarly migration project at work—moving a legacy on-prem monolith to a multi-cloud microservices setup. Naturally, we leaned on FOSSA for the open source compliance piece. Their marketing is all about being "comprehensive," and for the bulk of our codebase (libraries, dependencies, even some obscure JS packages), it delivered.
But here's the hot take: the moment we hit firmware blobs and container base images, the "comprehensive" claim started to crack.
* **Firmware:** We have these custom hardware appliances that ship with embedded Linux and proprietary firmware blobs. FOSSA basically shrugged. It wanted a package manager manifest that didn't exist. We had to manually cobble together SBOMs from the vendor's (incomplete) docs and cross-reference with a separate, old-school audit. Total workflow breaker.
* **Containers:** It's better than nothing—it can peel apart a Docker image and identify the OS packages. But the depth felt shallow. We found issues with:
* **Transitive dependencies in distro packages:** If a vulnerability is buried deep in a library that `apt` installed, we missed it until a separate Trivy scan flagged it.
* **Build-time dependencies left in final images:** FOSSA's scan often reflected the *build* environment, not the pruned final image, leading to false positives and noise.
In the end, our "comprehensive" stack needed **three** tools: FOSSA for the main app code, a dedicated container scanner, and a manual process for firmware. That's a lot of overhead and context switching for a DevOps team trying to automate everything.
Anyone else run into this? How are you stitching together firmware and container SBOMs with your main code scan? Is there a way to make FOSSA play nice here that we missed, or is this just a known gap?