When a Simple Script Depends on 43 Components: Why You Should Know What Your Software Is Made Of

Recently, I looked into one of my small utility scripts. It simply fetches Mikrotik router configurations and saves them to a repository.

At first glance, it’s pure minimalism: just a few lines of dependencies in requirements.txt. But digging deeper, I discovered that this “microscript” (forgive my love of wordplay) actually pulls in 43 components.

It all started with three familiar libraries — paramiko, requests, and yaml. Then the dependency chain grew on its own: each library pulled in dozens of helper packages for encryption, parsing, logging, and serialization.

If you visualize this as a dependency graph, it looks like a tree — and one infected branch can endanger the whole thing. That’s exactly how the software supply chain works: a single vulnerable library can compromise an entire application.

A Bit of Context

According to the Sonatype Open Source Malware Index (Q1 2025), in just the first three months of this year researchers identified 17,954 malicious open-source packages — almost double compared to the same period last year.

More than half were linked to data exfiltration, and around 7% to hidden crypto mining.

And all of this spread through dependencies — the “invisible” components we automatically pull in without thinking twice.

Solving the Problem

The solution exists — it’s called SBOM (Software Bill of Materials), essentially a list of ingredients for your software.

Unlike conventional vulnerability scanners, SBOM doesn’t search for bugs — it shows the structure and origin of your code:

• what components make up the product,
• who created them,
• under what licenses they’re distributed,
• and how they connect to each other.

Other tools analyze code by symptoms; SBOM provides an X-ray view of the entire system, allowing you to make informed security and risk decisions.

It’s a modern approach that, in 2025, received a major update from CISA (Cybersecurity and Infrastructure Security Agency) — bringing new features that make it even more informative and practical.

What It Means for Businesses, Developers, and Customers

For businesses, SBOM is a risk management and transparency tool. It helps quickly identify whether your product is affected by a new vulnerability and provides traceable accountability to clients and partners. Companies working with government contracts or large corporations increasingly face the requirement to “provide an SBOM” it’s becoming part of standard agreements.

For developers and teams, SBOM brings order to dependencies and removes “black boxes.” It lets you see which packages end up in the build, which pull outdated or risky libraries, and where updates are needed. In short it’s a new level of transparency for the CI/CD process.

For customers and users, it’s a trust indicator. An SBOM shows that the product wasn’t just built, but built responsibly with visibility and control. When a client receives software accompanied by an SBOM, they gain confidence that the supplier truly understands what their code contains.

Ultimately, SBOM becomes not a bureaucratic formality but a shared language of transparency between business, developers, and clients where everyone knows what they rely on and what risks they’re managing.

Conclusion

My little script reminded me: in today’s world, there are no small programs behind every line of code lies an entire ecosystem.

SBOM helps see that ecosystem and manage it before vulnerabilities appear. It also gives businesses, developers, and customers confidence that their product stands on a transparent and secure foundation.

I’m curious what’s your take on SBOM?

• Do you already use it in your projects?
• Do you see it as a must-have standard or still just a “trend”?

#supplychainsecurity #sbom #cybersecurity #devsecops