Malscan STIX Processor

Status: Live Output: per-ecosystem STIX 2.1 bundles at https://vulnetix.com/malscan-stix/ Type: publisher (DB read → STIX 2.1 → S3) Source slug: malscan-stix Schedule: every 15 minutes (cron(0/15 * * * ? *))

Overview

malscan-stix-processor is the publishing half of the malware-scanning feedback loop: every malicious package the registry scanners detect contributes its C2 / exfil infrastructure back into a public threat feed, and the detection engine then matches future packages against that feed — so infrastructure burned in one attack flags the next package that reuses it. See Known-Bad IOC Feed (STIX) for the full loop.

Each run reads the malware-IOC pipeline and writes per-ecosystem STIX 2.1 bundles to S3 (vdb-manager-artifacts), served unauthenticated at https://vulnetix.com/malscan-stix/….

Feeds produced

Two feed kinds are published per ecosystem:

Each indicator is a STIX indicator object with a pattern ([domain-name:value = '…'], [ipv4-addr:value = '…'], [url:value = '…']), plus name, description, labels (carrying severity:* and ecosystem:*), external_references (the originating advisory) and valid_from.

Composite ecosystems (e.g. npm,pypi) fan out per ecosystem; anything outside a recognised package ecosystem lands in the generic catch-all feed.

Manifest, checksums & determinism

• Every feed is accompanied by a sibling <feed>.sha256.
• A top-level index.json manifest lists every published feed with its URL, sha256 and indicator count.
• Output is deterministic — a feed file’s bytes change only when its indicator set changes, so unchanged feeds keep a stable checksum across runs.

Consumption

The engine’s iocscan package fetches index.json and the requested ecosystem’s dns + urls bundles (plus the always-included generic feed), sha256-verifies them against the manifest, caches them with a 1-hour TTL, and matches package source against the resulting in-memory IndicatorSet. A match is folded into the finding set as evidence and is recorded back as a MalwareIoc whose references carry the file/line and STIX provenance — which this processor then re-exports on its next run. See Malware Detection and Known-Bad IOC Feed (STIX).

S3 Persistence

Not used. This processor does not currently archive payloads or quarantine failures to S3. Per the S3 Persistence Contract this is non-compliant — see the compliance matrix for the implementation roadmap.

⚠ Not in the compliance matrix — status needs verification.

Expected paths when implemented:

• Archive: malscan-stix/files/{sha256}/{filename}
• Quarantine: failed-feeds/malscan-stix-processor/{YYYY-MM-DD}/{reason}/{filename}
• Likely reasons: (none documented)