Dependency & Security Validation

Scenario

You maintain a production Node.js application with many third-party dependencies.

Coding agents may occasionally need to:

• add a package;
• upgrade a package;
• replace a vulnerable dependency;
• respond to a security advisory.

Dependency changes can affect:

runtime behavior
bundle size
licenses
transitive dependencies
build tooling
security exposure

You want agents to make dependency changes deliberately rather than installing packages as the default solution to every problem.

Repository Structure

application/
├── src/
├── tests/
├── package.json
├── pnpm-lock.yaml
└── AGENTS.md

AGENTS.md

# Project Instructions

## Dependencies

- Check whether the repository already provides the required capability before adding a dependency.
- Add dependencies to the package that directly uses them.
- Use `pnpm` for dependency changes.
- Commit intentional lockfile changes with dependency updates.

## New Packages

Before adding a new runtime dependency:

- confirm that it solves a real repository need;
- prefer established packages already used by the repository when appropriate;
- avoid adding a large dependency for trivial functionality;
- check that the package is compatible with the project's runtime and module system.

## Security Updates

- Do not ignore a security advisory solely because the application still builds.
- Determine whether the vulnerable dependency and affected functionality are relevant to this project.
- Prefer supported upgrades or documented mitigations.
- Do not weaken application security controls merely to remain compatible with an outdated dependency.

## Validation

After dependency changes:

- install using the repository package manager;
- inspect the resulting manifest and lockfile changes;
- run relevant tests;
- run `pnpm lint`;
- run `pnpm typecheck`;
- run the production build when runtime or build dependencies change.

## Scope

- Avoid unrelated dependency upgrades during a targeted change unless they are required.
- Do not regenerate the entire lockfile unnecessarily.

What This Does

This treats dependencies as part of the application's architecture and supply chain.

Suppose an agent needs to generate a random identifier.

The first response should not automatically be:

pnpm add some-random-id-package

The repository or runtime may already provide the necessary capability.

Every additional package introduces another dependency relationship that must be maintained.

What This Does NOT Do

The instructions do not say:

- Never add dependencies.

Third-party libraries are valuable and often safer than implementing complex functionality from scratch.

For example, writing custom implementations for:

cryptography
authentication protocols
complex parsers

can be much riskier than using a well-maintained library.

The goal is deliberate dependency management, not avoiding the ecosystem.

The file also does not imply that every advisory means the application is exploitable.

Advisories require context.

Why These Instructions Matter

A dependency update can appear small:

- "some-package": "2.4.1"
+ "some-package": "3.0.0"

But a major version may change:

API behavior
module format
runtime requirements
default security behavior
transitive packages

That is why dependency changes need appropriate validation.

Security advisories require similar judgment.

A vulnerable package may be:

directly reachable in production

or:

development-only and unrelated to the vulnerable code path

Those situations have different risk.

The correct response is to investigate the project's actual exposure and apply an appropriate supported fix.

Key Decisions

Reuse before adding

Search the repository and runtime capabilities before introducing another package.

Keep dependency changes focused

A one-package security update should not automatically become:

upgrade every package
+
rewrite lockfile
+
change build tooling

unless those changes are necessary.

Validate lockfile changes

A package-manager operation can modify more than the dependency you intended to change.

Review the resulting diff.

Treat advisories contextually

Ask:

Is the affected version installed?
Is the vulnerable functionality reachable?
Is this production or development only?
Is a patched version available?
Is there a supported mitigation?

Don't solve security issues by weakening security

If an old dependency conflicts with a security control, disabling the control is generally not an appropriate compatibility strategy.

Validate runtime impact

Dependency changes can affect code without producing a type error.

Run relevant behavioral tests and builds.

When to Use This Pattern

Use this pattern when:

• the application depends heavily on third-party packages;
• dependency updates occur regularly;
• security advisories must be handled;
• lockfiles are committed;
• coding agents are allowed to add packages.

The goal is to make dependency changes intentional, reviewable, and proportionate to the problem being solved.