Software Supply Chain Security: Why 70–90% of Your Code Is an Underrated Risk

If there is one conviction that persists in conversations with engineering teams, it is this: well-known libraries are secure libraries.

The logic behind it sounds intuitive. If millions of projects use the same library, it must be intensively tested, quickly patched, and monitored by the community. In theory, this is true. In practice, it is diametrically false.

At the time Log4Shell was discovered, Log4J was built into almost every Java application. This is exactly what made the incident so devastating. The vulnerability was trivially exploitable, and the blast radius was global. Anyone using Log4J—which was almost everyone—was exposed.

The same applies to the NPM supply chain attacks surrounding s1ngularity and shai hulud: packages with millions of downloads per day, compromised by attackers who knew exactly that popularity is no guarantee of security. On the contrary—it is an incentive.

The pattern is consistent: the more widespread an artifact, the more attractive it is as a target. A successful attack on a single, widely used component allows thousands of downstream projects to be compromised simultaneously.

It would be unfair to claim that teams ignore the risk because they are unaware of it. Awareness exists in most organizations. The real problem lies elsewhere: in the trade-off between speed and security.

New libraries bring features. They enable state-of-the-art implementations with minimal effort. Those who use them deliver faster. Those who wait for hardened, scanned artifacts lose time.

This trade-off is real—and it is made daily in teams, usually implicitly, without a formal process.

The result: Dependency security is not neglected out of ignorance, but because the short-term benefit is more visible than the long-term risk.

In consulting practice, the same patterns appear repeatedly across industries and company sizes. They rarely concern the technical competence of the teams—but rather processes, tooling, and organizational structures.

The most common mistake when building a secure supply chain is the big-bang approach: everything at once, immediately, across the entire company. This fails not due to a lack of will, but due to a lack of foundation.

The right approach is iterative—and it begins not with tooling, but with transparency.

1. Inventory—Do You Know What You Are Really Using?

Before you can secure anything, you must know what exists in the first place. This sounds trivial. In practice, it is the most difficult step for many organizations.

Inventory means: Which dependencies are being used? In which versions? By which teams? From which sources? Reliable answers must exist for these questions—not as an Excel list updated once a quarter, but as a living, machine-readable inventory.
Only those who have this overview can begin to assess risks, set priorities, and take targeted action.

2. Centralization—A Controlled Source for All Teams

The next logical step is the introduction of a central artifact repository. All teams, all applications, and all build processes obtain their dependencies from a single, controlled source.

This central point becomes the pivot of the entire supply chain security strategy. It enables policy enforcement (which packages are allowed, which are not?), systematic scanning, maturity level models for artifacts, and a clear audit trail.

As long as dependencies are pulled from the open internet, there is no lever for control. A central repository creates this lever.

3. Establish Security Gates in CI/CD

Based on a central repository and a complete inventory, CI/CD gates can be used effectively. Automated scans, policy checks, and blocking pull requests for critical vulnerabilities are powerful tools.

However, they are useless without the foundation from steps 1 and 2. CI/CD security gates based on incomplete or decentralized data provide a false sense of security. The right approach: first introduce them informatively (create visibility without blocking processes), then gradually switch to enforced once the foundation is stable.

Theory is one thing. Two anonymized examples from Fullstacks projects show what these principles mean in practice.

Electronics Manufacturer: Maturity Levels for Artifacts

For a large electronics manufacturer, Fullstacks fundamentally restructured artifact management. The starting point: no uniform naming conventions, no defined maturity stages, and no systematic overview of the security status of individual components.

The solution: a multi-stage maturity level model for software artifacts of all kinds. Every artifact passes through defined maturity stages—characterized by scans, policy approvals, and verification steps. Only artifacts that have been scanned multiple times and approved through defined policies can reach certain production environments. The result is a controllable, auditable process instead of a proliferation of uncontrolled sources.

Automotive: Incident Response for a Supply Chain Incident

In the automotive industry, Fullstacks supported a company that fell victim to a targeted attack on its software supply chain. The incident clearly showed what happens when no structured incident response competence is present: the blast radius grows uncontrollably because no one knows which systems and artifacts are affected.

Fullstacks supported the company in reacting quickly and actively, limiting the damage while simultaneously creating the structural prerequisites so that such an incident can be detected earlier and contained more effectively next time.

The question is legitimate: Why now? Why not wait until an incident occurs and then react?

The answer lies in the nature of supply chain attacks. Unlike a direct attack on an application, supply chain compromises often go undetected for months. By the time they are noticed, the damage has long been done. Reaction is then expensive, slow, and public—rarely in the desired direction.

Teams that proactively manage their software supply chain have a fundamental advantage: they know what they are working with. They can manage risks—consciously and prioritized—before an incident has to occur. This competence is not just a security gain. It is a competitive advantage in regulated markets, during audits, and toward customers who increasingly ask for proof.

Those who wait often do not even know how their software actually comes together. And that—regardless of industry and company size—is no longer a sustainable position.