The most dangerous thing in your codebase is not a vulnerable dependency. It is the belief that adding another tool will make you secure. That if the dashboard is green, the system is safe. That security is something you can install.

It is not. And the industry that tells you otherwise is selling you something.

The Dependency Is the Vulnerability

Every dependency you add is a potential breach. Not hypothetically — structurally. Code you did not write, maintained by people you have never met, pulled automatically into your build, running in your production environment with your users' data. You are trusting a stranger with something that is not yours to give away.

The security tooling industry has built a business on the back of this problem. The answer they sell you is: add more tools. Add a scanner. Add an agent. Add a dashboard. Let us watch your dependencies for you.

But the scanner is a dependency. The agent is a dependency. They run in your pipeline with elevated permissions, they pull their own updates over the network, and they are as exposed to supply chain compromise as anything else you run. You have added unaudited third-party software with broad access to your build boundary, to tell you your unaudited third-party software is safe. The circularity is not accidental. It is the business model.

In March 2026, Trivy — one of the most widely used open source security scanners — was compromised in a multi-phase supply chain attack. Attackers force-pushed 75 out of 76 version tags in the trivy-action GitHub repository to point to malicious commits, meaning any pipeline referencing a version tag automatically ran attacker-controlled code. The malicious action read directly from GitHub Actions runner memory, harvesting SSH keys, cloud credentials, Kubernetes tokens, and database passwords. It then deployed a persistent backdoor on developer machines and seeded a self-propagating worm across 47 npm packages. The tool you added to catch supply chain attacks became a supply chain attack.

This is not a Trivy-specific failure. It is what the category looks like when you think clearly about it.

The answer to too many dependencies is not another dependency. It is fewer dependencies.

Trust No One

Early in my career I inherited an ASP application with no server-side validation and a security audit due on Monday. A weekend of trying to patch it taught me something no textbook does: the moment you try to catch bad input, you are already losing. Every encoding trick, every character variant, every malformed sequence — there is always another way through a filter. The only position that holds is to trust no one. Validate everything, at the boundary, unconditionally. Not because you know what the attacker will try. Because you do not.

That lesson has not aged. SQL injection is not a sophisticated attack. It is what happens when a developer assumed the input was safe. No tool prevents this. No scanner catches it at runtime. A discipline of treating every external input as hostile until proven otherwise prevents it — and that discipline lives in the engineer, not the pipeline.

Know what your code actually does. Not at the feature level — at the execution level. What process runs with what privilege. What opens a socket. What constructs a query. What writes to disk. If you need a dashboard to answer those questions about your own system, the dashboard is papering over a gap in understanding that will eventually matter.

Build small. A statically compiled binary in a scratch container has almost no attack surface because it has almost no surface at all. Minimal dependencies, minimal privilege, minimal exposure. The discipline of building lean is a security practice. It always has been. The tools just let people forget that for a while.

You Cannot Outsource Responsibility

This is the part the tooling industry does not want you to sit with.

When you ship software that handles your users' data — their records, their financial information, their operational safety — you have made a commitment. Not a contractual one. A human one. That data exists because they trusted you with it. A green dashboard does not discharge that commitment. A compliance badge does not discharge it. A vendor SLA does not discharge it.

Tools do not bear responsibility. Vendors do not bear responsibility. You do. Your team does. Your organisation does.

The substitution of tooling for understanding is not just ineffective — it is a way of not taking that responsibility seriously. It lets you feel secure without becoming secure. It lets you point at a process when something goes wrong instead of asking whether you understood your system well enough to prevent it. And something will go wrong. The question is whether you built it knowing that, or whether you assumed the tool would catch it.

Security is not a product you subscribe to. It is a posture built decision by decision — every dependency you chose not to add, every input you validated, every privilege you did not grant, every piece of user data you treated as genuinely yours to protect.

Get Back to Basics

Use the tools your stack ships with. Go includes govulncheck. It analyses call graphs — it only flags a vulnerability if your code actually reaches it, not merely if the dependency exists. It is maintained by the Go team against the official Go vulnerability database. It carries no new trust boundary. If you trust your compiler, you trust this. That is sufficient.

Write code small enough to understand completely. Validate at every boundary. Grant the minimum privilege the task requires. Treat your users' data as a responsibility you chose, not a liability to manage.

This is not a new idea. It is the oldest idea in the discipline. It got buried under a decade of tooling sales and compliance theatre. The way back is straightforward: stop adding tools and start doing the engineering.