Run any Skill in Manus with one click

eunomai-dependency-upgrade

Stars0

Forks0

UpdatedJuly 1, 2026 at 22:02

Universal hygiene for adding or upgrading third-party dependencies — pin via lockfile, scan for known CVEs (SCA) before merging, read the changelog, take breaking changes incrementally, run the tests, and track licenses. Use when adding a new dependency, bumping versions, or responding to a security advisory. Anchored to OWASP A03:2025 (Software Supply Chain) and SLSA.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

grojof

grojof/eunomai

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	eunomai-dependency-upgrade
description	Universal hygiene for adding or upgrading third-party dependencies — pin via lockfile, scan for known CVEs (SCA) before merging, read the changelog, take breaking changes incrementally, run the tests, and track licenses. Use when adding a new dependency, bumping versions, or responding to a security advisory. Anchored to OWASP A03:2025 (Software Supply Chain) and SLSA.

eunomai-dependency-upgrade

Open-source makes up the majority of modern codebases, so dependencies are a primary risk surface. This is the universal hygiene for changing them — anchored to OWASP A03:2025 Software-Supply-Chain Failures and SLSA. It does not replace your package manager — it's the checklist around it.

Before adding a new dependency

Do you need it? Prefer the standard library or a few lines over a dependency. Fewer deps = smaller attack surface.
Vet it: maintained (recent commits/releases), reputable author, healthy usage, and an acceptable license for your project.
Check it's clean: run an SCA / CVE scan (e.g. npm audit, osv-scanner, pip-audit — or the scanner/registry the project's rules designate) before committing it.

When upgrading

Pin via a lockfile and commit it — deliberate, reproducible versions; upgrade on purpose, not by drift.
Read the changelog / release notes. Note breaking changes and deprecations.
One major at a time. Don't jump several majors at once; upgrade, build, test, repeat.
Scan again (SCA). Confirm the new version (and its transitive deps) has no known critical/high CVE; if one exists, check exploitability before shipping. Deciding to ship anyway is a risk acceptance — record the waiver (CVE id, rationale, revisit date) where the project keeps decisions (an ADR, or the location its rules designate).
Run the full test suite. Treat a dependency upgrade like any other change — green tests before merge.
Track licenses. Record/respect the dependency's license (an SBOM — SPDX/CycloneDX — captures name, version, supplier, and license); a new dep must not introduce an incompatible license.

Responding to a security advisory

When a CVE is published for a dependency you use: identify affected versions, upgrade to the patched release (or apply the documented mitigation), scan, test, and ship. An up-to-date lockfile + SBOM makes "are we affected?" a lookup, not an investigation.

Boundary

Universal hygiene only — the policy (which CVE severity blocks a release, approved registries, SLSA level) is the project/org's call, declared in its rules, not here.

More from this repository

same repository

eunomai-living-docs

grojof/eunomai

Refresh a project's user-facing docs (root README + docs/) toward eunomai's v2 standard — Diátaxis as a lens via a `type` frontmatter field, a knowledge-domain coverage lens (the six KDD domains), an OKF-routable substrate (frontmatter + path-as-identity + a product-shaped README map), doc-set profiles by repo destination (library, API, CLI, framework, firmware, app — or custom), and a deterministic frontmatter gate. Use when docs have drifted, after shipping a feature, or when docs-check reports drift. Project-docs only (may create ADRs from interview answers; never edits existing ones).

2026-07-090

eunomai-onboard

grojof/eunomai

Cold-start orchestrator that applies eunomai to a new or existing project. Use when bringing a foreign project up to eunomai's standards — analyze it, assess what already exists (coexistence-first), establish/restructure docs (or create them), seed conventions (CLAUDE.md, OpenSpec config, permissions, hooks — each skippable), audit existing skills, then hand off. One-shot and dispensable; orchestrates the pillars, does not reimplement them.

2026-07-090

eunomai-skill-finder

grojof/eunomai

Trust-gated steward for a project's skills. Use when you need a capability and want to adopt/create a skill safely, when a third-party skill should be vetted before use, or when asked to audit existing skills. Discovers candidates, applies a trust gate (security veto + judgment), adopts/improves/creates via skill-creator, and records per-skill provenance. Best-effort floor-raiser, not a security guarantee.

2026-07-010

eunomai-secure-coding

grojof/eunomai

Universal secure-coding directives anchored to the OWASP Top 10:2025 and CWE Top 25. Use proactively while writing or changing code that handles input, auth, data, secrets, files, network calls, or dependencies — to avoid injection, broken access control, crypto and auth failures, SSRF, and unsafe deserialization. Writing-time guidance; for a diff audit use /security-review, for runtime blocking see safe-controls.

2026-07-010

diagnosing-bugs

grojof/eunomai

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.

2026-06-250

name	eunomai-dependency-upgrade
description	Universal hygiene for adding or upgrading third-party dependencies — pin via lockfile, scan for known CVEs (SCA) before merging, read the changelog, take breaking changes incrementally, run the tests, and track licenses. Use when adding a new dependency, bumping versions, or responding to a security advisory. Anchored to OWASP A03:2025 (Software Supply Chain) and SLSA.

eunomai-dependency-upgrade

Before adding a new dependency

Do you need it? Prefer the standard library or a few lines over a dependency. Fewer deps = smaller attack surface.
Vet it: maintained (recent commits/releases), reputable author, healthy usage, and an acceptable license for your project.
Check it's clean: run an SCA / CVE scan (e.g. npm audit, osv-scanner, pip-audit — or the scanner/registry the project's rules designate) before committing it.

When upgrading

Pin via a lockfile and commit it — deliberate, reproducible versions; upgrade on purpose, not by drift.
Read the changelog / release notes. Note breaking changes and deprecations.
One major at a time. Don't jump several majors at once; upgrade, build, test, repeat.
Scan again (SCA). Confirm the new version (and its transitive deps) has no known critical/high CVE; if one exists, check exploitability before shipping. Deciding to ship anyway is a risk acceptance — record the waiver (CVE id, rationale, revisit date) where the project keeps decisions (an ADR, or the location its rules designate).
Run the full test suite. Treat a dependency upgrade like any other change — green tests before merge.
Track licenses. Record/respect the dependency's license (an SBOM — SPDX/CycloneDX — captures name, version, supplier, and license); a new dep must not introduce an incompatible license.

Responding to a security advisory

Boundary

Universal hygiene only — the policy (which CVE severity blocks a release, approved registries, SLSA level) is the project/org's call, declared in its rules, not here.