Package license analysis — detect copyleft conflicts against a permissive policy, surface AGPL / SSPL / GPL contaminants, output SPDX SBOM with per-package license findings. Use when auditing a release for license compliance, vetting a new dependency's license, building an OSS-attribution document, or producing a customer-facing license disclosure.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
--policy strict to catch any non-allowlisted licenses.vulnetix scan --sca.npm view <pkg> license).Follows skills/_lib/contract.md. In short: use the vulnetix_* MCP tools when the agent has them and the CLI otherwise — both shape their own output, so there is no jq step any more. Independent calls go out as concurrent Bash tool calls in one message. One trailing suggestion, not a playbook. See the contract for surface selection, output style and memory writes.
vulnetix license -o json-spdx > .vulnetix/licenses.${TIMESTAMP}.spdx.json
Default policy:
User can override via --policy. Accept user-supplied allowlist via .vulnetix/license-policy.yaml if present.
| Package | Version | License | Policy verdict | Action |
Conflicts highlighted. Suggest replacement packages for blocked licenses (consult vulnetix vdb packages search <name> --license <permitted> if needed).
If --bundle flag provided, also output the file path so the compliance-bundler agent can pick it up.
.vulnetix/licenses/<timestamp>.summary.yaml with conflict counts.
--policy permissive flags GPL-* / AGPL-* / LGPL-* against an MIT/Apache codebase; --policy strict allowlists only MIT, Apache-2.0, BSD-2/3-Clause, ISC, MPL-2.0..vulnetix/license-policy.yaml overrides the built-in policy.--direct-only to scope to top-level packages.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Dockerfile / Containerfile / compose analysis plus optional Trivy / Grype / Syft composition when those binaries are present. Use when reviewing a Dockerfile PR, gating `docker build`, building an image SBOM, evaluating base-image risk, or auditing a registry image for CVEs.
The English summary is being prepared. Showing the original description.
Show what this repository has already decided about its vulnerabilities, read from the durable record rather than by scanning again — open versus resolved, the decision taken on each, and what is still waiting. Use when picking up triage after a break, auditing past decisions, onboarding to a repository with security history, or checking nothing high-severity is open before a release.
The English summary is being prepared. Showing the original description.
Dependency-conflict resolution when a `fix` version bump fails — diagnose the peer-dep tree, find a compatible safe version set, propose package-manager overrides (`overrides`/`resolutions`/`replace`/`[patch]`), fall back to safe-harbour inline patching. Use when an upgrade is blocked by transitive constraints, a peer-dep conflict surfaces, or you need to override a vulnerable transitive without bumping the parent.
The English summary is being prepared. Showing the original description.
Work through which package to add for a capability, and what each option costs — maintenance, licence, bundle weight, transitive risk, and whether the platform already does it. Use when someone needs a library for a job and has not picked one yet, when weighing two candidates, or when a package looks convenient but unmaintained.
The English summary is being prepared. Showing the original description.
IDS/IPS detection content for a CVE — Snort/Suricata-compatible rules, YARA signatures, ProjectDiscovery Nuclei templates, traffic-filter rules. Capability-aware: skips families when the binary is not installed (no Snort = no Snort output). Use when deploying defences for a CVE without a patch, augmenting SAST with active detection, or feeding the SOC engineering pipeline.
The English summary is being prepared. Showing the original description.
End-of-life detection for runtimes (Node, Python, Java, Go, .NET) and key packages — surfaces past-EOL items, items reaching EOL within 90 days, and EOL base images for containers. Use when planning a runtime upgrade, auditing for unsupported versions, gating a deploy against EOL deps, or producing a remediation roadmap.
The English summary is being prepared. Showing the original description.