Where it fits / Implementation guide

Connect your workflow.

Setup, examples and limits for adding maintenance checks to your SDLC.

The software development lifecycle

Software keeps moving.
Maintenance belongs in the loop.

Choose with evidence. Ship through your existing checks. Review what changes after release.

Explore what happens at each stage

01 · Plan & code
Choose dependencies. Review upstream maintenance before adoption, using package lookup or an authenticated MCP client.
Developer → maintenance evidence
Use your IDE security checks for code and secrets. Resolve dependencies through your chosen registry or Artifactory.
02 · Build & test
Run tests, secret detection, code and dependency security scans. Add a maintenance report when a supported manifest changes.
CI → security checks + maintenance check
Start with a review report. Introduce any blocking maintenance policy deliberately, after reviewing unknowns and false positives.
03 · Package & release
Generate an SBOM for the built artifact. Store it with the artifact and its digest, keeping signing, scanning and promotion in your release workflow.
One SBOM → two complementary reviews
Send the supported inventory to your security platform and to isitdeadyet Pro for matching public packages’ maintenance context.
04 · Deploy & operate
Deploy the approved artifact. Keep admission controls, runtime visibility and cloud security in your existing platform.
Runtime inventory → selected artifact SBOM
Use your deployment records to identify what actually runs. A live Wiz-to-isitdeadyet runtime selection loop is a future integration.
05 · Review & maintain
Re-import the selected inventory on your schedule. Add explicit watches for ongoing package alerts and check relevant product support dates.
Evidence → team decision → next change
Investigate upstream support, plan an upgrade or migration, and send the reviewed change through the same tests and security gates.

↻ Findings return to planning. A release that was well supported can need attention later, even when its source code has not changed.

Complementary roles

Your stack. One extra perspective.

Store & deliverArtifactory

Find security riskXray · Wiz · Dependency-Track

Plan maintenanceisitdeadyet

Compare roles and supported connections

Tool / role	What it contributes	How isitdeadyet fits
Artifactory	Artifact storage and distribution	Import supported inventory or use a scoped read-only JFrog connection.
Xray / Dependency-Track	Dependency security findings and policy review	Review upstream maintenance alongside the findings; preserve their source and security decisions.
Wiz	Code-to-cloud security and runtime context	Import a supported exported inventory. Live runtime API integration still needs tenant validation.
isitdeadyet	Maintenance evidence, licence changes, deprecation and supported product lifecycle information	A review list with assessment dates and explicit unknowns, plus alerts for selected watches.

Complementary roles, not exclusive feature claims or partnerships. Maintenance health is not security clearance, and an end-of-life date is not itself a vulnerability.

Put it to work

Start at the handoff that matters to you.

Expand a recipe for setup, commands and downloadable GitHub Actions YAML.

Use it from your tools: MCP clients

Connect an MCP client to look up packages, check supported manifests and review changes. HTTP access requires the instance’s configured MCP token; it is not a general account API key.

claude mcp add --transport http is-it-dead-yet https://isitdeadyet.dev/mcp --header "Authorization: Bearer <the instance's MCP_TOKEN>"

For a self-hosted instance, node dist/mcp.js serves the tools over stdio on the machine configured with database access. The public manifest checker used by the CLI is POST /api/report.

01Check a public manifestLocal development & CI · Public packages

Copy the reviewable CLI source to tools/iidy.mjs at a revision you trust. Run with Node.js 22 or later. This avoids depending on an npm publication.

node tools/iidy.mjs scan package.json --fail-on none
node tools/iidy.mjs scan package.json --fail-on dead,abandoned --json

--fail-on none reports maintenance findings without failing on verdicts. The second command exits 1 for dead or abandoned entries. Both exit 2 if the check cannot run. Unassessed packages do not make a clean report proof of coverage.

The public checker creates a shareable report. Use public dependency identities only; private inventories belong in Pro imports.

Optional local pre-commit hook

Add to .pre-commit-config.yaml for an npm project. It makes a network request when package.json changes; it is not a lockfile-tree scanner.

# Copy the reviewed CLI to tools/iidy.mjs first; requires Node.js.
repos:
  - repo: local
    hooks:
      - id: dependency-maintenance
        name: Review dependency maintenance
        entry: node tools/iidy.mjs scan package.json --fail-on none
        language: system
        files: ^package\.json$
        pass_filenames: false

CI: public maintenance report

Download manifest-check.yml ↓

# Add to an existing trusted workflow after checkout and Node.js setup.
# Copy the reviewed packages/cli/bin/iidy.mjs to tools/iidy.mjs first.
- name: Review public dependency maintenance
  run: node tools/iidy.mjs scan package.json --fail-on none --json > maintenance.json
# --fail-on none reports findings without failing on maintenance verdicts.
# Exit 2 still fails this step when the check cannot run.
# This creates a shareable report: use only public dependency identities.

02Bring your existing inventoryAfter the build · Private Pro imports

Generate full CycloneDX JSON 1.4–1.6 with your existing trusted build tooling. A findings-only export can omit packages without vulnerabilities.
Import it in Platform integrations, then generate a scoped CI token for that source.
Copy the inventory upload helper to your repository and configure the source ID and masked token.
Add the upload after generation. Keep your existing security-platform upload and release gates.

CI: upload the same inventory for maintenance review

Download inventory-upload.yml ↓

# Add after your existing build, tests and compatible SBOM generation.
# Copy the reviewed tools/ci/upload-inventory.mjs into your repository first.
# Node.js 22+, Pro source, and its scoped CI upload token are required.
- name: Check inventory format locally
  run: node tools/ci/upload-inventory.mjs --check bom.json
- name: Upload maintenance inventory
  env:
    IIDY_UPLOAD_TOKEN: ${{ secrets.IIDY_UPLOAD_TOKEN }}
    IIDY_SOURCE_ID: ${{ vars.IIDY_SOURCE_ID }}
  run: node tools/ci/upload-inventory.mjs bom.json
# Keep your existing Dependency-Track upload and security gates separately.
# Upload success means accepted inventory, not a passed maintenance gate.

Uploads require Node.js 22+, Pro and configured private storage. This helper accepts CycloneDX JSON 1.4–1.6, up to 2 MiB. Sources allow up to 2,000 components; account limits include five sources and twenty uploads/manual actions per rolling day. Sources and tokens expire after 30 days. Send secret-bearing uploads only from trusted workflows.

03Keep reviewing after releaseWeekly schedule · Selected inventory

Use the SBOM for the deployed artifact digest, rather than assuming the latest build is what runs. The weekly example refreshes an existing selected snapshot; connect your own registry retrieval step for production use.

Scheduled: weekly inventory review

Download weekly-review.yml ↓

# Prerequisites: reviewed helper at tools/ci/upload-inventory.mjs,
# Node.js 22+, and a compatible bom.json committed on the default branch.
# This refreshes a selected inventory snapshot; it does not discover runtime images.
name: Weekly maintenance review
on:
  schedule:
    - cron: '0 6 * * 1' # Monday 06:00 UTC
  workflow_dispatch:
permissions:
  contents: read
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
        with:
          node-version: '22'
      - name: Refresh maintenance context
        env:
          IIDY_UPLOAD_TOKEN: ${{ secrets.IIDY_UPLOAD_TOKEN }}
          IIDY_SOURCE_ID: ${{ vars.IIDY_SOURCE_ID }}
        run: node tools/ci/upload-inventory.mjs bom.json
# Replace/reconfigure the source before its 30-day expiry.
# For production, retrieve the inventory for the deployed artifact digest
# using your existing registry workflow instead of a committed sample BOM.

Re-importing updates the snapshot assessment. It does not add watches automatically or create tickets. Add important packages to your watchlist explicitly; review changes before opening a migration PR.

What about dependencies inside your dependencies?

A manifest may cover only direct dependencies. A suitable lockfile or generated SBOM can include transitive dependencies, depending on the generator and build. Import coverage still depends on supported ecosystems and identities; not every OS package or private component can be assessed.

Direct dependency needs attention

Review its evidence and supported releases. Decide whether to monitor, upgrade or evaluate an alternative. A suggested alternative still needs compatibility testing.

Transitive dependency needs attention

Find which direct dependency brings it in using your package manager or inventory graph. Review an upstream update before forcing a replacement.

npm explain package-name

The current CLI checks supported manifests. It does not provide separate direct/transitive policy gates or full dependency paths. Use your package manager to trace the dependency before deciding what to change.

Available today

Begin with what you already use.

Package checks, MCP tools, Pro inventory imports, selected JFrog connections and explicit package watches.

Explore integrations →

Know the boundaries

Imports are snapshots. Watches are added explicitly. Runtime selection and migration decisions remain with your team.

What is still ahead?

Live Wiz runtime selection, direct Dependency-Track sync, automatic monitoring of imported portfolios and reviewed migration PR workflows are future possibilities. They are not working automation today.

Examples reflect supported features as of 12 September 2026. Check format, plan and source limits before connecting a workflow. Provider links above document their own roles.

Connect your workflow.

Software keeps moving.Maintenance belongs in the loop.

01 · Plan & code

02 · Build & test

03 · Package & release

04 · Deploy & operate

05 · Review & maintain