Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

ns-analyze-vulnerabilities

Étoiles3

Forks0

Mis à jour30 juin 2026 à 12:18

Analyzes live runtime vulnerabilities loaded by connected N|Solid Node.js processes. Use when the user wants to know which CVEs are actually present in running apps, active exploitable/live vulnerabilities, zero-day exposure, supply-chain risk in production, or production package risk. For static npm-audit-style project dependency scans, use ns-audit-dependencies instead.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

nodesource

nodesource/nsolid-plugin

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en sécurité de l'informationProfessions informatiques et mathématiques·SOC 15-1212

SKILL.md

readonly

name	ns-analyze-vulnerabilities
description	Analyzes live runtime vulnerabilities loaded by connected N\|Solid Node.js processes. Use when the user wants to know which CVEs are actually present in running apps, active exploitable/live vulnerabilities, zero-day exposure, supply-chain risk in production, or production package risk. For static npm-audit-style project dependency scans, use ns-audit-dependencies instead.

1. High-Level Overview

Call the vulnerabilities tool with showLimit/page when scanning large fleets.
Summarize the output to identify which application (app) has the most critical issues.

2. Detail Per App

For a specific vulnerable app, call application-packages (parameters: exact app name, mode='flat').
Timeout note: The MCP server allows 180s for this streaming endpoint, but the MCP client may drop after 60s. If it times out, proceed using data already collected from the vulnerabilities tool.

3. Discover First Detection Time

Call events-historic (parameters: type='new-vulnerability-found', plus app, start, and end when known).
CRITICAL: The MCP tool description may incorrectly say vulnerability-detected. Do not use that. Valid Security Events: new-vulnerability-found, package-vulnerabilities-updated, vulnerabilities-database-updated, active-vulns-updated.
If this endpoint returns null, it means there are no matched historical events. Proceed without failing the audit.

4. Propose and Implement

Locate the target package.json in the user's workspace.
Propose an update to a patched version.
Wait for user approval if the update represents a major breaking change. Otherwise, implement the fix.

5. Verify

Re-run the vulnerabilities tool to confirm the vulnerability is resolved.
If results do not change, note that verification may require app restart/redeploy or package refresh before live data updates.

6. Present a Report

Emit the analysis directly in chat as markdown:
- # Runtime Vulnerability Analysis — <appName-or-fleet>
- ## Summary
- ## Evidence
- ## Findings
- ## Remediation Plan
- ## Verification
Ground every CVE, package, version, and severity in vulnerabilities, application-packages, or provided evidence.

7. Write the Report to Disk

Ask the user if they want to save the report to disk.
If the user confirms, write the final report as a markdown file (.md) under .nsolid/assets/ — for example .nsolid/assets/runtime-vulnerability-analysis-<appName>.md.

Guardrails

NEVER suggest bumping a major version without explicitly warning the user about potential breaking changes.
ALWAYS base your analysis on the actual output from the vulnerabilities and application-packages tools.
Only analyze the application requested, or the one with the highest vulnerabilities if none is specified.

Plus depuis ce dépôt

même dépôt

ns-advanced-memory-leak-hunter

nodesource/nsolid-plugin

Performs an advanced N|Solid memory leak hunt comparing baseline vs peak heap evidence to isolate retained constructors, closures, and retainer paths. Use when the user reports recurring/staircase memory growth, elusive leaks, retained objects, closures holding references, or a standard heap sample/snapshot analysis was inconclusive. Prefer supplied baseline/peak assets; capture new samples only when needed.

2026-06-303

ns-analyze-asset

nodesource/nsolid-plugin

Analyzes an existing N|Solid diagnostic asset by asset ID or local asset path using asset-summary. Use when the user asks to inspect, review, summarize, or interpret an already-captured CPU profile, heap profile, heap sample, or heap snapshot, including assets just produced by ns-generate-asset. Do not use to capture new profiles/snapshots.

2026-06-303

ns-cpu-spike-analysis

nodesource/nsolid-plugin

Diagnoses high CPU or slow execution in a Node.js app using supplied evidence or N|Solid CPU metrics/profiles. Use when the user reports CPU spike, high CPU percent, slow endpoint/function, event loop blocking, flamegraph/profile analysis, hot loop, or asks why an app is slow. Prefer existing asset IDs, summaries, trace data, or local profiles before capturing a new profile.

2026-06-303

ns-generate-asset

nodesource/nsolid-plugin

Captures a new N|Solid diagnostic asset for a connected Node.js app. Use when the user explicitly asks to collect, capture, or generate a CPU profile, flamegraph, heap sample, heap snapshot, or heap tracking asset and wants it saved or handed off for analysis. For existing assets, use ns-analyze-asset instead.

2026-06-303

ns-memory-spike-analysis

nodesource/nsolid-plugin

Diagnoses memory growth, heap spikes, RSS increases, OOMs, and suspected leaks in Node.js apps using supplied heap evidence or N|Solid heap sampling/snapshots. Use when the user reports memory leak, heap growing, high RSS, out-of-memory, heap snapshot/profile analysis, or wants memory root-cause triage.

2026-06-303

ns-analyze-tracing

nodesource/nsolid-plugin

Analyzes N|Solid/OpenTelemetry tracing evidence for request latency, HTTP errors, and service dependencies. Use when the user asks about slow endpoints, API timeouts, distributed traces/spans, N+1 queries, await chains, microservice latency, cascading failures, or trace IDs. Query N|Solid only when no trace data was provided. Do not assume full waterfall details unless supplied.

2026-06-303

name	ns-analyze-vulnerabilities
description	Analyzes live runtime vulnerabilities loaded by connected N\|Solid Node.js processes. Use when the user wants to know which CVEs are actually present in running apps, active exploitable/live vulnerabilities, zero-day exposure, supply-chain risk in production, or production package risk. For static npm-audit-style project dependency scans, use ns-audit-dependencies instead.

1. High-Level Overview

Call the vulnerabilities tool with showLimit/page when scanning large fleets.
Summarize the output to identify which application (app) has the most critical issues.

2. Detail Per App

For a specific vulnerable app, call application-packages (parameters: exact app name, mode='flat').
Timeout note: The MCP server allows 180s for this streaming endpoint, but the MCP client may drop after 60s. If it times out, proceed using data already collected from the vulnerabilities tool.

3. Discover First Detection Time

Call events-historic (parameters: type='new-vulnerability-found', plus app, start, and end when known).
CRITICAL: The MCP tool description may incorrectly say vulnerability-detected. Do not use that. Valid Security Events: new-vulnerability-found, package-vulnerabilities-updated, vulnerabilities-database-updated, active-vulns-updated.
If this endpoint returns null, it means there are no matched historical events. Proceed without failing the audit.

4. Propose and Implement

Locate the target package.json in the user's workspace.
Propose an update to a patched version.
Wait for user approval if the update represents a major breaking change. Otherwise, implement the fix.

5. Verify

Re-run the vulnerabilities tool to confirm the vulnerability is resolved.
If results do not change, note that verification may require app restart/redeploy or package refresh before live data updates.

6. Present a Report

Emit the analysis directly in chat as markdown:
- # Runtime Vulnerability Analysis — <appName-or-fleet>
- ## Summary
- ## Evidence
- ## Findings
- ## Remediation Plan
- ## Verification
Ground every CVE, package, version, and severity in vulnerabilities, application-packages, or provided evidence.

7. Write the Report to Disk

Ask the user if they want to save the report to disk.
If the user confirms, write the final report as a markdown file (.md) under .nsolid/assets/ — for example .nsolid/assets/runtime-vulnerability-analysis-<appName>.md.

Guardrails

NEVER suggest bumping a major version without explicitly warning the user about potential breaking changes.
ALWAYS base your analysis on the actual output from the vulnerabilities and application-packages tools.
Only analyze the application requested, or the one with the highest vulnerabilities if none is specified.