What I learned is that in hopes to secure the software supply chain we have ran a very similar playbook and mostly over engineered the problem, with SBOMs and VEX documents and expected the industry to comply. But what was discovered was that every SBOM looks different depending on who produced it and at what step in the chain, and it didn’t make anything more secure because it was nothing but an ingredients list and in some cases a CVE dump attached. This is not helpful for anyone who actually triages software.
I built Vigilance to be a simple alternative to the problem to watch for one thing in any part of the supply chain. What files changed in ability and what that ability is. It compares one version of a file to another and says what inside it gained a new ability. This takes what used to be a diff of files from a few thousand in worst case to a list of under 4 with clear stated intentions and at any point within the supply chain. I built it to reduce noise and make the boots on the ground job of triaging simpler and easier.
It’s a single Go binary, no dependencies, no AI, no CVE database. It can run on edge devices to end user computers, build servers to dev machines and air gapped environments. The free version sends basic telemetry reports up for that state file hash and any powers, no file paths, no names, no user information. This is going to be used for research and improving the product. The paid version is licensed completely offline so no telemetry is sent to us but it operates the exact same way to the user on an unlimited number of machines.
Early adopters get two years free if they supply a logo and/or testimonial for the product.
You can try it on most npm packages in the sandbox at https://vigihq.com/sandbox. The sandbox has a daily cap and I am happy to answer any questions.