Skip to main content
Submitting a well-prepared report increases the chance of fast verification and helps reviewers spend their time on analysis rather than chasing down missing information. Follow these guidelines to make your reports as strong as possible before they enter the review queue. OpenSourceMalware only tracks assets associated with malicious open source activity. Do not submit threat reports for assets that are malicious but delivered through other means (e.g. a phishing campaign).

​
Before you report

Work through these three checks before opening the submission form.

​
1. Verify malicious intent

Confirm that the resource is genuinely malicious and not a false positive. Common malicious indicators include:
  • Obfuscated or suspicious code patterns that serve no legitimate purpose
  • Unauthorized data exfiltration (sending data to external endpoints without user knowledge)
  • Backdoors or remote command execution capabilities
  • Crypto-mining behavior embedded in packages or containers
  • Credential stealing routines targeting API keys, tokens, or passwords
If you can explain specifically what the code does and why it’s harmful, your report will hold up to scrutiny.
Reports flagged as false positives are displayed on your profile. Take time to verify that a resource is genuinely malicious before submitting. Your community reputation depends on submission accuracy.

​
2. Check for existing reports

Search the OpenSourceMalware database before submitting to avoid duplicate reports. Use the Browse Threats page to look up the package name, domain, IP, or other identifier. If you submit through the API, you can also use the check-malicious endpoint. Browse Threats and check-malicious only show reports that have passed review, so a report that’s still pending won’t appear. If you submit a package that already has a report in any status, the API returns a 409 error that includes the existing report’s ID. Duplicate submissions are tracked as an outcome and reflected on your profile.

​
3. Gather evidence

Collect supporting evidence before you write your report. Strong evidence sources include:
  • OSV or GHSA advisory URLs
  • Analysis blog posts or security research reports
  • Code samples or screenshots demonstrating the malicious behavior
  • Third-party verification sources (vendor advisories, CVE entries, threat intel feeds)
Having links ready when you fill out the form makes it straightforward to include them in the evidence URLs field.

​
What to include in your report

​
Required information

These three fields must be completed for a report to enter the review queue:
  • Report type — Package, Repository, URL, Domain, IP, Wallet, or Container
  • Resource identifier — The package name, URL, domain, IP address, wallet address, or image reference
  • Threat description — A clear explanation of what the malware does and why it’s malicious
Your threat description is the most important part of the report. A strong description is:
  • Clear and concise — Explain the threat in plain terms that a reviewer can follow without guessing
  • Actionable — Make the risk and impact clear so others can act on the information
  • Evidence-based — Reference your sources and findings rather than asserting conclusions without support
Including these fields significantly speeds up review and improves your report’s chances of verification on the first pass:
  • Affected versions — Specific versions or version ranges where the malicious behavior is present
  • Severity level — Critical, High, Medium, Low, or Info
  • Payload description — Technical details about what the malicious code or behavior does, including specific function names, endpoint URLs, registry keys, or other details that demonstrate the behavior.
  • Publisher information — Author username, email address, or organization
  • Tags — Relevant categorization labels such as dprk, rat, or typosquat (see Tags for a full guide)
  • Evidence URLs — Links to advisories, analysis posts, or third-party reports

​
Report quality standards

For an example of a strong threat report, refer to https://opensourcemalware.com/npm/axiosGood reports:
  • Cites multiple evidence sources (e.g., OSV advisory + code sample + blog post)
  • Provides detailed technical analysis of the malicious behavior
  • Specifies affected versions accurately using proper version notation
  • Links to official advisories such as OSV or GHSA entries
  • Uses an appropriate severity level that reflects the actual impact
  • Lacks evidence or proof of malicious behavior
  • Reports a legitimate package as malicious without substantiation
  • Provides a vague or unclear description (“this package looks suspicious”)
  • Submits a duplicate without first checking the Browse Threats page
  • Exaggerates severity (e.g., labeling a low-impact issue as Critical)

​
Review timeline

Reports are typically reviewed by experienced community members within 24 hours. Complex or high-severity cases may require additional time for thorough investigation. You will receive notifications when your report status changes. Check your profile at any time to track all your submissions and their current status.