Python project. Library missing. Just install it… that’s the plan.
What happens next shows just how absurd some quality standards are: I want to install a single library, and it automatically loads over 100 additional libraries along with it.
Great—everything is noted in the BOM software, and everything is documented in a way that makes it easy to trace. It saves me a lot of work.
But hey—who really knows all this stuff that’s just being loaded here? Who’s checked to make sure all these components are “okay” and aren’t causing any trouble?
Oh, I see—most of it is open source? Well, that’s good, then.
Nope. Not that either. Just because something is open source doesn’t mean it’s any good. Or that anyone has ever checked it.
Even though there are organizations, foundations, and communities that regularly conduct audits on certain (and only a very small number of selected) open-source projects—the gray area is enormous.
However, lawmakers are now requiring us to provide and document an SBOM for our software. This is a correct, important, and absolutely sensible step. But it doesn’t solve any problems yet.
Because it’s only when we work with this SBOM, analyze it, assess risks, and—if necessary—take a closer look at the components used ourselves that we end up with what we actually want:
Digital sovereignty—with deliberate risks and side effects.
#computerScientistsAreCool#oleoleisawesome#opensourcealone-doesn’t-make-you-happy