For a small, long-lived tool, “no dependencies” is not asceticism — it is a property you can defend. The standard library is the one dependency you already trust: it ships with the runtime, it is versioned with the runtime, and you have already accepted its provenance by choosing the platform at all. A tool that reaches no further than that has a closed boundary.
Each dependency you add past that line carries three costs that persist for as long as you keep the tool. The first is transitive trust: you import not one package but everything it imports, and everything those import, down a tree you did not read and cannot easily audit. The second is a supply-chain surface — each node is a place a compromised or withdrawn release can reach you. The 2016 left-pad unpublish demonstrated how little code is needed for this to bite: an eleven-line function, removed from the registry, broke builds across a large slice of the npm ecosystem (The Register). The third is a recurring upgrade tax, paid on someone else’s schedule for as long as the tool lives. The general case for pricing a dependency over its whole life, rather than at the moment you add it, is argued well by Cox (Surviving Software Dependencies).
The boundary is real, and it does not generalize. Below some complexity threshold, writing the two hundred lines yourself is cheaper over the tool’s life than owning the tree. Above it — cryptography, TLS, compression, anything adversarial or subtle — rolling your own is the more dangerous choice, and a well-maintained dependency is the responsible one. The skill is knowing which side of the line you are on.