Threat feed

The threat-feed endpoint returns threats that were added to or updated in the OpenSourceMalware database within a rolling time window. Add unverified=1 to the same call to also receive threats that have been reported to us but not yet verified by our team.

Subscription Required: This is a paid endpoint. Check out our pricing and contact us for more info.

Use this endpoint to:

Keep blocklists current: Pull new and updated threats on a schedule and update your block rules without manual review.
Power automated alerting: Feed threats into your SIEM, SOAR, or internal alerting pipeline as they are verified.
Get early warning: Receive unverified findings before human review is complete, and treat them as suspicious until a determination is made.
Recover missed threats: Use a larger lookback (up to 24 hours) to catch up after a poller outage without re-ingesting your entire threat history.

Endpoint

GET https://api.opensourcemalware.com/functions/v1/threat-feed

Required header

Authorization: Bearer osm_your_token

Alternative: Pass API key as query parameter: ?apikey=osm_your_token

Paid Access Required This endpoint requires a Core or Enterprise API key. Standard API tokens will receive a 403 Forbidden response.

Query parameters

Parameter	Required	Description
`ecosystem`	Required	The ecosystem to poll. One ecosystem per call. See the values below.
`hours`	Optional	Lookback window: a whole number from `1` to `24`. Defaults to `1`. Any other value returns `400 Bad Request`.
`unverified`	Optional	Set to `1` to include unverified findings in the same response. `true` and `yes` also work. Requires a Core or Enterprise account; other accounts receive `403 Forbidden`.

Valid ecosystem values:

Packages: npm, pypi, crates, nuget, maven, go, packagist, rubygems, vscode, openvsx, brew, and skills
Other malicious assets: repositories and container
Not supported: domain, wallet, ip, url. Use check-malicious for these.

How polling works

Polling frequency and lookback are separate settings

Polling frequency is how often you call the endpoint. The lookback (hours) is how far back each call reaches. You can poll as often as you need fresh data, and many teams poll far more often than hourly. Your lookback must always be longer than the time between calls. For example, polling every 15 minutes with hours=1 covers every record, with overlap. Polling every 2 hours with hours=1 silently misses an hour of records each time. To confirm you have no gaps, store each response’s to timestamp and check that it lines up with the from timestamp of your next call. If your poller goes down, call once with a lookback that covers the outage. The maximum lookback is 24 hours, so alert on poller failures well before that.

Records can appear more than once

A verified record can come back in threats for two reasons:

Your polling windows overlap, which is expected.
The record’s threat intelligence changed, for example new affected versions or an updated description. Its last_updated timestamp moves forward and it re-enters the feed.

Upsert on id rather than discarding records you’ve already seen. If you already hold the record and last_updated is newer, replace your copy. If last_updated is unchanged, it’s an overlap duplicate you can skip. The feed doesn’t indicate which field changed, so compare against your stored copy if you need to know. A change to version_info can have two impacts: Added versions can affect consumers who weren’t affected before, and removed versions were found to be false positives. Re-run any matching against your dependency inventories when it changes.

A blank or null version_info means every version of the package is malicious. This is the most common case since many packages are owned by threat actors.

Unverified findings

Verified threats are the most accurate threat intelligence we provide. They lag behind real-time detection by however long human review takes, which is how we ensure you’re getting the best quality data. If you’d rather trade a small false positive risk for the earliest possible signal, add unverified=1 to your calls.

Blocking unconfirmed malware can send false positives to your development team and erode trust. Present unverified findings as suspicious, never as confirmed malware. For example, consider a “suspicious asset” policy that places a time-based hold on downloading the package while OpenSourceMalware makes a determination.

Where they appear in the response

With unverified=1, one call returns both kinds of records. You don’t need a separate poll.

threats: verified records, counted in count
unverified_scans: unverified findings, counted in unverified_scans_count

Make sure your parser reads both arrays.

How unverified findings differ

Unverified findings come from automated analysis, so they carry less detail than verified records.

Field	Unverified (`unverified_scans`)	Verified (`threats`)
`status`	`"unverified"`	`"verified"`
`verified_at`, `verified_by`	`null`	Populated
`threat_description`, `payload_description`	`null`	Populated
`tags`	Empty	Populated
`osm_score`	Present	Not present
`osv_advisory_url`	`null`	Populated if an advisory exists
`created_at`, `updated_at`, `first_seen`, `last_seen`	All set to the time of the scan	Set independently

Connecting an unverified finding to its verified record

Every unverified finding is eventually either verified or rejected as a false positive.

When it’s verified, it appears in threats on your next poll and no longer appears in unverified_scans.
When it’s rejected, it appears in the false-positive endpoint.

The id changes when a finding is verified. In unverified_scans, id identifies the scan. In threats, it identifies the verified threat record. Don’t use id to connect the two.

Instead, match on registry and package_name, then check whether the scanned version falls within the verified record’s version_info. Don’t compare version_info values as exact strings, since verified records often list several versions, a range, or every version.

Don’t link to `osm_url` for unverified findings

Unverified findings include an osm_url, but that page isn’t published until the finding is verified. Don’t display or link to it until the record appears in threats.

Response example

Success (200)

This example uses unverified=1, so it includes both arrays.

{
  "count": 1,
  "window_hours": 1,
  "ecosystem": "npm",
  "from": "2026-10-26T16:30:00.000Z",
  "to": "2026-10-26T17:30:00.000Z",
  "threats": [
    {
      "id": "bbf96529-1912-4a64-af1b-8cd8f6b96ae0",
      "created_at": "2026-10-26T16:45:12.144851+00:00",
      "updated_at": "2026-10-26T16:50:00.460000+00:00",
      "last_updated": "2026-10-26T16:50:00.460000+00:00",
      "report_type": "package",
      "severity_level": "high",
      "status": "verified",
      "verified_at": "2026-10-26T16:50:00.460000+00:00",
      "first_seen": "2026-10-26T16:45:10.625000+00:00",
      "last_seen": null,
      "registry": "npm",
      "resource_identifier": "npm/ts-predict-helper",
      "package_name": "ts-predict-helper",
      "download_count": null,
      "published_date": null,
      "tags": [
        "npm",
        "compromised-account",
        "suspicious-metadata"
      ],
      "version_info": "0.0.1-security",
      "source_id": null,
      "threat_description": "Malicious package detected.",
      "payload_description": "Exfiltrates environment credentials upon preinstall execution.",
      "evidence_references": null,
      "verified_by": "6mile",
      "osv_advisory_url": "https://osv.dev/vulnerability/MAL-2026-6322",
      "ghsa_advisory_url": "https://github.com/advisories/GHSA-xxxx-xxxx-xxxx",
      "researcher": null,
      "researcher_organization": null,
      "malicious_dependencies": [],
      "osm_url": "https://opensourcemalware.com/npm/ts-predict-helper"
    }
  ],
  "unverified_scans_count": 1,
  "unverified_scans": [
    {
      "id": "4c2e8a1f-7b3d-4e9a-a6c5-2f1d8e0b9c37",
      "created_at": "2026-10-26T17:12:44.000000+00:00",
      "updated_at": "2026-10-26T17:12:44.000000+00:00",
      "report_type": "package",
      "status": "unverified",
      "verified_at": null,
      "verified_by": null,
      "first_seen": "2026-10-26T17:12:44.000000+00:00",
      "last_seen": "2026-10-26T17:12:44.000000+00:00",
      "registry": "npm",
      "package_name": "example-suspicious-pkg",
      "published_date": null,
      "tags": [],
      "version_info": "1.0.3",
      "osm_score": 88,
      "threat_description": null,
      "payload_description": null,
      "osv_advisory_url": null,
      "malicious_dependencies": [],
      "osm_url": "https://opensourcemalware.com/npm/example-suspicious-pkg"
    }
  ]
}

For a description of every field, see API response fields.

Error responses

API error responses

Click this card for the latest list of error responses.

cURL examples

Poll for npm threats in the last hour (default lookback):

curl -H "Authorization: Bearer osm_your_token" \
  "https://api.opensourcemalware.com/functions/v1/threat-feed?ecosystem=npm"

Poll for verified and unverified npm threats in the last hour:

curl -H "Authorization: Bearer osm_your_token" \
  "https://api.opensourcemalware.com/functions/v1/threat-feed?ecosystem=npm&unverified=1"

Get PyPI threats from the last 6 hours:

curl -H "Authorization: Bearer osm_your_token" \
  "https://api.opensourcemalware.com/functions/v1/threat-feed?ecosystem=pypi&hours=6"

Get repository threats from the last 24 hours:

curl -H "Authorization: Bearer osm_your_token" \
  "https://api.opensourcemalware.com/functions/v1/threat-feed?ecosystem=repositories&hours=24"

STIX format

The OpenSourceMalware API also supports returning threat feed data in STIX (Structured Threat Information Expression) format, making it compatible with threat intelligence platforms and SIEMs that consume STIX bundles. To request STIX output, contact us for access details.

Overview

Free Endpoints

Paid Endpoints

Query parameters

How polling works

Polling frequency and lookback are separate settings

Records can appear more than once

Unverified findings

Where they appear in the response

How unverified findings differ

Connecting an unverified finding to its verified record

Don’t link to `osm_url` for unverified findings

Response example

Success (200)

Error responses

API error responses

cURL examples

STIX format

​Query parameters

​How polling works

​Polling frequency and lookback are separate settings

​Records can appear more than once

​Unverified findings

​Where they appear in the response

​How unverified findings differ

​Connecting an unverified finding to its verified record

​Don’t link to osm_url for unverified findings

​Response example

​Success (200)

​Error responses

API error responses

​cURL examples

​STIX format

Query parameters

How polling works

Polling frequency and lookback are separate settings

Records can appear more than once

Unverified findings

Where they appear in the response

How unverified findings differ

Connecting an unverified finding to its verified record

Don’t link to `osm_url` for unverified findings

Response example

Success (200)

Error responses

cURL examples

STIX format