Safeguard
Supply Chain•

Malware screening vs vulnerability scanning: two different checks

Vulnerability scanning finds known flaws in honest code. Malware screening looks for code built to harm. Why a package needs both and how to read each.

Safeguard Security Team
3 min read

Vulnerability scanning looks for known flaws in code that was written in good faith, such as a bug that lets an attacker bypass a check. Malware screening looks for code written to do harm, such as a stealer hidden in an install script. A package can pass one and fail the other, so you need both.

What each check asks

Vulnerability scanning asks: does this package and version appear in a database of known flaws? The answer comes from published advisories.

Malware screening asks: does this package contain behavior that looks hostile? There may be no advisory at all. The detection comes from analysis of the package contents.

Where they show up on Gold

A Gold package page lists them as separate checklist items. One is "No high or critical vulnerabilities". Another is "Malware-free", with a sentence such as "Passed Safeguard malware screening". The directory says components go through verification for security, malware and license compliance, and that analysis is done by its Griffin AI.

Why a package can pass one and fail the other

A brand new malicious package has no CVE, so a vulnerability scan shows nothing. A well known library can have a serious CVE and no malicious behavior at all. A package that was clean last week can be taken over and a malicious version published. Each check answers a different question.

Limits of each

Vulnerability scanning cannot see unreported flaws or intent. Malware screening cannot prove the absence of every hostile behavior, and it tends to be a snapshot of a specific version. Both depend on timing: a result is a statement about a version at a moment.

How to use both in practice

  1. Before adding a package, read both checklist items on its page.
  2. Pin exact versions so a later malicious release does not reach you automatically.
  3. Consider a short waiting period before adopting brand new releases.
  4. Review install scripts for anything that fetches or runs code.
  5. Re-check on a schedule.

What a clean pair of results still misses

Neither check tells you whether you configured the package safely or whether your own code misuses it. For the first, use configuration review. For the second, use code analysis.

Where Safeguard fits

Safeguard's dependency scanning and policies help enforce both checks in pull requests, and the free scan at gold.safeguard.sh/scan covers the known vulnerability side for a manifest. For how a clean result can mislead, see /resources/blog/a-clean-scan-does-not-mean-your-software-is-safe.

Quick check

Does the free scan check for malware?

The scan page says it shows which packages carry known vulnerabilities. It does not describe malware checks, so read the package page for that item.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.