Day 99

Day 99 - August 8, 2026: Security Maintenance Is Part of Owning Software

A Day 99 reflection on dependency alerts, targeted pnpm overrides, and using AI to reduce the friction of security maintenance.

August 8 was not a feature-development day. I spent it reducing dependency and security debt across several personal repositories.

That work is easy to underestimate because the visible changes are small. A package override moves by one patch release. A lockfile records a different resolution. A pull request contains no new screen, workflow, or user-facing capability. Yet this is part of owning software just as much as building the first version.

A repository can be finished from a feature perspective and still require continuous attention. New advisories change what we know about dependency versions that were acceptable when a lockfile was created. The code did not necessarily change overnight, but the evidence around its risk did.

Detection Is Not Always Remediation

GitHub security alerts were the starting point for today’s work. Several identified vulnerable packages deep in dependency trees, including fast-uri, ip-address, js-yaml, nanoid, postcss, and brace-expansion.

Some alerts arrive with a Dependabot pull request that is ready to review. That is the easiest path: inspect the proposed update, let the repository checks run, and merge it if the evidence supports the change.

Other alerts stop after detection. GitHub can identify the vulnerable package without producing a complete fix for the repository. This is especially common with transitive dependencies. The package may not appear in the normal dependency list because another tool or framework brings it into the graph.

At that point, the maintainer still has several questions to answer. Which dependency introduced the package? Is a patched version available on the same compatible release line? Will the parent dependency accept it? Which lockfile entries should change? Does the application still pass its normal checks after the new resolution?

The alert is useful evidence, but it is not the whole remediation.

Overrides As A Narrow Tool

Several fixes today used pnpm overrides. An override tells the package manager to select a particular version even when the vulnerable package is transitive. That can be a practical way to move to a patched release without waiting for every parent package in the chain to publish its own update.

In domain-placeholder-platform PR 67, the overrides and lockfile moved fast-uri from 3.1.4 to 3.1.5 and ip-address from 10.2.0 to 10.3.1. The related PR 68 was part of the same remediation sequence. I treated it as part of that sequence rather than manufacturing a separate accomplishment from a proposal whose useful dependency state was established by the surrounding changes.

PR 69 continued the cleanup by resolving js-yaml at 4.3.1 and nanoid at the patched 3.3.17 release.

The same pattern appeared in Tech Talent Pulse. PR 41 moved fast-uri from 3.1.4 to 3.1.5 through the override and lockfile, while PR 42 addressed the additional js-yaml and nanoid alerts using patched resolutions appropriate to that repository’s dependency graph. I did not assume its nanoid version had to match another repository. Similar alerts can sit inside different trees with different compatibility constraints.

Overrides are not proof that an application is secure, and they should not be applied blindly. They deliberately take control of a resolution that would otherwise belong to the upstream dependency graph. That makes compatibility checks, lockfile review, and the repository’s normal validation especially important. They are a narrow escape hatch, not a substitute for understanding the tree.

AI Lowered The Investigation Cost

Codex was most useful today in the space between an alert and a reviewable change.

I could provide the vulnerable package information and ask it to inspect the dependency graph, identify how the package entered the repository, find an appropriate patched version, and determine whether a focused override made sense. It could then update the relevant configuration, regenerate the pnpm lockfile, run the repository’s checks, and prepare the work for review.

That sequence turns a collection of small but interruptive investigations into a repeatable maintenance workflow:

  1. Start with the alert rather than guessing from the manifest.
  2. Trace the installed package back through the dependency graph.
  3. Select a patched version that respects the repository’s compatibility constraints.
  4. Make the smallest manifest or override change that resolves the vulnerable version.
  5. Regenerate and inspect the lockfile.
  6. Run the repository’s own build, test, formatting, and security checks.
  7. Review the resulting diff as a pull request.

AI did not discover the vulnerabilities, publish the patches, or make the result inherently safe. GitHub surfaced the findings. Package maintainers produced corrected releases. pnpm supplied the dependency-resolution mechanism. Repository governance defined what could change and which evidence had to pass. The agent helped connect those pieces with much less manual friction.

That is a grounded but valuable role. Dependency trees are structured enough for an agent to investigate efficiently, repetitive enough that automation helps, and consequential enough that narrow scope and verification still matter.

A Multi-Repository Cleanup

The rest of the day repeated the pattern across repositories without requiring every fix to look identical.

boo-boo-story PR 106 was the broadest dependency-hardening change. It updated override resolutions covering fast-uri, js-yaml, postcss, brace-expansion, and nanoid, then recorded those selections in the lockfile. The important story was not the list of packages. It was resolving several newly visible transitive findings in one reviewable maintenance pass while leaving product behavior out of scope.

project-template-node PR 37 applied the same dependency-remediation discipline to a reusable Node project foundation. Keeping a template healthy matters because stale dependency state can otherwise be copied into every project created from it.

terminal-run PR 39 focused on the js-yaml denial-of-service alert. It selected the patched js-yaml resolution through the package override and updated the lockfile, keeping the change focused on dependency state rather than expanding it into unrelated application work.

Across these pull requests, I was responding to alerts and reducing the known vulnerable dependency surface. I was not establishing that the applications had been exploited, and I was not proving that no vulnerabilities remained. Exploitability depends on how a dependency is reached and how an application uses it. The right claim is smaller: newly surfaced dependency risks received targeted remediation, and the proposed repository states could be evaluated through normal review and validation.

Maintenance Is Product Work Too

Technical debt is often described as old architecture, duplicated code, or a refactor postponed to ship a feature. Dependency security belongs in the same conversation.

Every external package is a continuing relationship with upstream code and newly discovered information. A lockfile gives an installation consistency, but it also preserves yesterday’s dependency decisions until someone revisits them. Security alerts are one signal that the revisit is due.

Today’s output was a set of small configuration and lockfile changes across several repositories. There was no dramatic launch at the end. The value was that those repositories moved forward rather than quietly accumulating known dependency debt.

This is also an area where AI assistance feels particularly practical. The work contains repeated graph inspection, version comparison, narrow edits, lockfile regeneration, and validation. Lowering the cost of those steps makes it more likely that maintenance happens promptly instead of waiting for a future cleanup day.

The responsibility does not move to the agent. The maintainer still decides which change is justified, reviews the diff, interprets the checks, and owns the dependency state afterward. AI simply makes that responsibility easier to exercise across more than one repository.

Software ownership continues after the interesting feature work is done. Sometimes the day’s best engineering result is not adding a capability. It is making the existing software a little healthier, with evidence, before moving on.

Definition Of Done

Day 99 reached the August 8 dependency-maintenance checkpoint: