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.

​
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 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 is harmful, your report will hold up to scrutiny.

​
2. Check for existing reports

Search the OSM database before submitting to avoid duplicate reports. Use the Browse Threats page to look up the package name, domain, IP, or other identifier. 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 present 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 the malicious behavior
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 Informational
  • Payload description — Technical details about what the malicious code or behavior does
  • Publisher information — Author username, email address, or organization
  • Tags — Relevant categorization labels such as backdoor, crypto-stealer, or typosquatting
  • Evidence URLs — Links to advisories, analysis posts, or third-party reports

​
Writing good descriptions

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
  • Technical — Include specific function names, endpoint URLs, registry keys, or other technical details that demonstrate the behavior
  • 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

​
Report quality standards

  • 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)
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.

​
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.