Yes, a shared library is a supply chain link. A flaw or a bad release reaches every client that uses it. The risk is manageable: version it, review changes, publish from CI, let each client upgrade on its own schedule, and keep a list of which client runs which version.
Why agencies build them
Reusing buttons, forms, auth helpers and analytics wrappers saves time. It also means that a vulnerability in your form helper is a vulnerability in twenty client sites, and a mistake in a release can break all of them on the same morning.
You become a supplier to your own clients, with the same duties as any upstream package maintainer.
Controls that matter
Semantic versioning with changelogs. Clients pin to a version. Breaking changes need a major bump and a note.
Review for every change. At least two sets of eyes on code that touches input handling, auth or network calls.
CI-only publishing. Publish from a pipeline with a scoped token, not from a laptop. Keep the publishing credential out of developers' hands.
Dependency hygiene inside the library. The library has its own dependencies. A flaw there flows downstream. Scan it like a product.
A registry of consumers. A simple table of client, site, library version and owner. When an advisory lands, you know the blast radius in minutes.
| Client | Site | Library version | Last updated | Owner |
|---|---|---|---|---|
| Client A | Marketing site | 4.2.1 | 2026-09-03 | Name |
| Client B | Portal | 3.9.0 | 2026-05-12 | Name |
Upgrade windows. Do not force every client at once. Do offer a fast path for security fixes.
When an advisory hits
Treat the library like any package with a known flaw.
- Confirm whether the vulnerable code path is present in each consumer.
- Release a fixed version and a short note.
- Raise upgrade pull requests across consumer repositories.
- Track which clients have upgraded.
- Tell clients plainly what happened and what you did.
Pull requests across many repositories are easier with automation that bumps one dependency in every repo and opens a review for each.
Ownership at handover
If the library is the agency's, say so in the handover pack. Does the client get a copy, a license to use it, a published package they can keep installing? Without an answer, the client's site depends on something they cannot rebuild. Agree this in the contract with counsel's help.
Keep an inventory
A shared library is easy to forget in an SBOM because it looks like first party code. List it as a component with its version. For the broader inventory problem, see how to keep a dependency inventory across every client site.
Quick check
Should the library be open source?
Only if you want that. Open sourcing adds maintainer duties and exposes code. Private is fine if you control access and releases.
How do we find which clients use a vulnerable version?
Keep the consumer table, and also search lockfiles across repositories. The table is faster, the search is the check.
Last reviewed: 19 October 2026.
