> For the complete documentation index, see [llms.txt](https://docs.sealsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sealsecurity.io/setup-apps-os/artifact-server/editing-dependencies.md).

# Editing dependency files

Under the Artifact Server deployment method, your manifest tells the build which sealed versions to pull. There are no Sealing Rules in this setup; the equivalent of a "rule" is a version pin in the manifest. To remediate a vulnerable package, replace its origin version with the sealed version (for example, `2.7.4-sp1` instead of `2.7.4`); the next build pulls the sealed artifact from the Seal Artifact Server in place of the public version.

The mechanics of editing — direct dependencies, transitive overrides, lockfile handling — vary by ecosystem. Because this is day-to-day operational work, not one-time setup, the per-ecosystem detail lives under [Working with Seal Apps under Artifact Server](/using-platform/working-with-seal-apps/artifact-server.md).

This page covers the parts that are setup-time: when manifest editing is the right path, and what the alternatives are.

## When you edit the manifest yourself

Under the Artifact Server deployment method, manifest editing is the only way packages get sealed. There is no Seal CLI step in the pipeline, so nothing automates the pin. Every sealed version that ships in your build came from a manifest entry you wrote.

Under the CLI-in-CI deployment methods (Remote, Local, Automatic Remediation), the Seal CLI handles the substitution at build time and the manifest is left alone. Customers occasionally combine the two — for example, an Artifact-Server-only Seal Project plus a CLI-in-CI Seal Project — but within one Seal Project the deployment method is set, and so is the way packages get sealed.

## Direct vs transitive dependencies

For dependencies you list directly in your manifest, pinning is the simple case: change the version range to the sealed `-sp[N]`. For transitive dependencies — packages brought in by your direct dependencies — pinning your own section does nothing; the depending package still asks for the vulnerable version. Each ecosystem has its own mechanism for forcing transitive resolution, and some have none.

The detailed per-ecosystem syntax for both cases is documented under [Working with Seal Apps under Artifact Server](/using-platform/working-with-seal-apps/artifact-server.md).

## Related

* [Working with Seal Apps under Artifact Server](/using-platform/working-with-seal-apps/artifact-server.md): the day-2 details, including the per-ecosystem editing syntax.
* [Configuring package managers](/setup-apps-os/artifact-server/configuring-package-managers.md): the package-manager setup that points your build at the Seal Artifact Server.
* [Maven-specific server features](/setup-apps-os/artifact-server/maven-server-features.md): Maven's `+safest` and `+safest-until-<cutoff>` suffixes for picking up newer iterations without re-editing the manifest.