What does malicious packages cover in practice?
malicious packages: The practical scope is Detect lookalike or untrusted packages entering the dependency graph.. Start with the listed entities or files and confirm the result on representative code.
Detect malicious packages before merge.
See how malicious packages fits local review, which evidence Code Radar produces, where coverage ends, and how trusted findings move into CI.
radar scan . --quickWhat malicious packages means here.
The malicious packages rule identifies review patterns that can create exploitable behavior or hide material maintenance risk, then returns the affected location, severity, confidence, and remediation context.
Rule reference
Evidence to inspect
Verify the input scope, finding detail, workflow handoff, and product boundary before you install or buy.
CriterionEvidence to inspectBoundary
Input scopeSelected files, configuration, scan mode, and enabled rules.Only included paths and configured checks are evaluated.
Finding detailFile, line, rule ID, severity, explanation, and repair direction.Illustrative output is not a result from your repository.
Workflow handoffLocal result, report format, agent context, and optional CI signal.Enable exports or CI only when the workflow needs them.
Decision fitUse the same criteria on a real repository before choosing a plan or tool.No universal winner or guaranteed outcome is claimed.
Rule reference
Check this risk locally
Verify the input scope, finding detail, workflow handoff, and product boundary before you install or buy.
The problem this page helps clarify
The useful question is where malicious packages changes the review loop: what enters the scan, who acts on a finding, and which evidence moves forward. Detect lookalike or untrusted packages entering the dependency graph.
- Audience: Developers and reviewers deciding how to handle malicious packages findings before merge.
- Focus: Detect lookalike or untrusted packages entering the dependency graph.
- Review question: What does malicious packages cover in practice?
Coverage and concrete signals
For malicious packages, inspect the concrete scope below instead of relying on a category label. Verify package identity, provenance, install script behavior, lockfile diff, and the reason the dependency entered the graph.
- Focus: Detect lookalike or untrusted packages entering the dependency graph.
- Workflow: Rule ID: RADAR-SCA-MALICIOUS
- Coverage and concrete signals: RADAR-SCA-MALICIOUS, unsafe pattern, safer pattern, Dependency security
FocusExact file location, rule context, severity, confidence, and remediation guidance.Boundary
Detect lookalike or untrusted packages entering the dependency graph.Verify package identity, provenance, install script behavior, lockfile diff, and the reason the dependency entered the graph.A trusted internal registry or pinned package can reduce risk but does not prove package behavior; review provenance and install scripts before accepting it.
Risky pattern / Safer pattern
malicious packages: A useful result must be explainable to a developer and portable to the next review surface. Inspect the concrete evidence below before changing team policy.
Risky patternSafer pattern
npm install lookalike-packageverify package identity, provenance, and lockfile diff
From local signal to shared gate.
malicious packages: Use the smallest workflow that proves value. Each later step should reuse evidence the team already understands. Detect lookalike or untrusted packages entering the dependency graph.
StepCommand or actionDecision
1Run a quick local scanIs the signal useful?
2Inspect and repair findingsIs the fix specific and reproducible?
3Export portable evidenceDoes the reviewer need SARIF, JSON, or HTML?
4Promote the trusted threshold to CIWhich severity should block a pull request?
radar scan . --quick
radar scan . --format sarif --fail-on highEvidence to inspect before you trust the result.
malicious packages: A useful result must be explainable to a developer and portable to the next review surface. Inspect the concrete evidence below before changing team policy. Verify package identity, provenance, install script behavior, lockfile diff, and the reason the dependency entered the graph.
- Rule ID: RADAR-SCA-MALICIOUS
- Exact file location, rule context, severity, confidence, and remediation guidance.
- Terminal output, SARIF, JSON, or HTML artifacts generated from the same finding set.
- Source stays in the workspace or CI runner where the scan executes.
Good fit and limits
Use malicious packages when Developers and reviewers deciding how to handle malicious packages findings before merge. Keep the boundary explicit: A trusted internal registry or pinned package can reduce risk but does not prove package behavior; review provenance and install scripts before accepting it.
Run the local proof before adopting a shared gate.
- Good fit: Developers and reviewers deciding how to handle malicious packages findings before merge.
- Not a fit / do not overreach: A trusted internal registry or pinned package can reduce risk but does not prove package behavior; review provenance and install scripts before accepting it.
Questions to verify before rollout
These questions keep the decision tied to observable evidence rather than a broad product promise.
Which evidence should I inspect for malicious packages?
malicious packages: Inspect Verify package identity, provenance, install script behavior, lockfile diff, and the reason the dependency entered the graph. Keep the source location, rule or comparison context, and exported artifact together.
What should I not infer from malicious packages?
malicious packages: Do not infer universal coverage. A trusted internal registry or pinned package can reduce risk but does not prove package behavior; review provenance and install scripts before accepting it. Use the relevant comparison or workflow page to test the boundary before changing policy.
What should I try first for malicious packages?
malicious packages: Start with a local run, review one real finding, then choose the linked report, agent, CI, or trust workflow that matches the next decision.
Validate the workflow on your own code.
Start with one local scan, inspect the evidence, and expand to reports, agents, or CI only when the signal is useful.