Software security is not a one-time task, but a continuous process, because attackers and their techniques evolve. An exceptionally important part is protecting the software supply chain — from code to production. The lecture showed why risks often hide in dependencies and how to bring them under control.
What the Mat JS library incident revealed
Programmers commonly reach for open libraries that speed up development. In the case of the Mat JS library, a clone emerged that offered a “minified” version, but it inserted code into the square root function to send login credentials to the Discord service. Such malicious changes are often hidden in obfuscated code and look innocent at first glance. It is a reminder that attacks can masquerade as routine optimizations.
The risk is amplified by the popularity of libraries and their interconnections: Mat JS was seeing hundreds of thousands of downloads per week, and thousands of other packages depended on it. When a vulnerability appears at such a node, it has the potential to affect a large part of the ecosystem. Attackers count on developers trusting familiar names and automated updates. That’s why we need to look not only at what we use, but also where it comes from and how it was created.
Transitive dependencies: the blind spot of the chain
Teams usually keep a close eye on direct dependencies, but it is transitive dependencies — those that pull in additional packages — that form a hard-to-see part of the risk. Practical experience shows that the majority of vulnerabilities in projects originate from them. Audits are challenging because the number of such components grows quickly and changes with every update. It creates the impression that we control only the tip of the iceberg.
In the public sector environment, there is also dependence on external suppliers whose internal security processes are a “black box” to the client. If a supplier uses outdated systems or vulnerable libraries, the risk is transferred all the way to the institution. In such a chain, weak points spread across development phases and between organizations. Therefore, it is not enough to protect only your own segments, but to set requirements for the entire chain.
How to defend: from “shift left” to SLSA, SBOM, and provenance
The principle of “shift left security” means moving security checks as early as possible into the process: from writing code, through build and deployment, to production monitoring. The later we uncover a vulnerability, the more expensive and riskier it is to resolve. Standards help, for example SLSA, which defines levels of software supply chain security and recommended practices. Open tools, for example from the community around Sigstore, are used for their practical implementation.
A concrete foundation is the SBOM (software bill of materials) and “provenance” (the origin and method of creation of an artifact). An SBOM states exactly what the software contains; provenance describes where, when, and by what process it was produced. If an organization requires these metadata upon delivery intake and verifies them automatically, it can stop noncompliant software before deployment — a practice already known from some states. Since attacks on the software supply chain are increasing and estimates say a large share of organizations will be affected by 2025, systematic control from the very start of development is no longer a choice and is becoming a necessity.
