Reporting AI Supply-Chain Risk With Evidence Levels, Not Inflation

Reporting AI Supply-Chain Risk With Evidence Levels, Not Inflation Security reports often turn a malicious package into a broader story about AI risk. The Apex Accelerator case has enough real detail to support a serious report, but the evidence still has levels. A package registry entry, an installed artifact, a network connection, a malware execution, and confirmed data loss are different findings. Decision-makers need that difference. Elastic Security Labs documented the campaign under REF8801. The packages @apexacc/cli and @apexacc/audit presented themselves as AI and Web3 tools. Elastic found malicious launch behavior, attacker-controlled model routing, a persistent MCP server, fabricated audit results, CloudSyncD on macOS, and a staged information stealer on Windows. GHSA and OSV record the package classification. Level one: package presence The first level is a package record. The organization can establish that a package name and version exist in a registry, cache, image, or inventory. This supports a review of where the package was used. It does not establish malicious execution. The package record should include the source, version, publisher, advisory, and the time of the check. For this event, GHSA and OSV are stronger sources than a search result title. Level two: installed artifact The second level is a local artifact that matches a known malicious file. A launcher hash, downloaded executable, or quarantine record can show that the package delivered something. This is stronger than package presence because it connects the package to a specific host and file. Investigators should preserve the file and its metadata before deleting it. The hash should be checked against the research, not copied from an unsupported summary. Level three: observed execution The third level is process and network evidence. A script interpreter starts from the package process, a temporary file is written, a published domain is contacted, or a loader appears in the process tree. This level supports a statement that the execution path occurred. It still does not prove every later stage. The Windows chain had a packaging failure in one sample, and the macOS C2 did not return additional payloads during the analyzed period. A report should describe the evidence it has rather than assume the full chain from the first indicator. Level four: data collection or exfiltration The fourth level is evidence that the stealer collected or sent data. This may come from archive creation, file access, network uploads, Telegram activity, or matching telemetry. Without that evidence, the team can describe potential exposure from the stealer's collection scope, but should not call it confirmed theft. The distinction matters for notification, legal review, and executive messaging. A possible credential exposure requires containment and review. A confirmed exfiltration requires a different response. Where external counts belong The external counts belong in a supporting context section. A product="npm" query returned 110 observations at 2026-11-04T15:46:32Z. A grouped query across five published domains returned 2 observations at 2026-11-04T15:47:09Z. Neither result establishes an affected organization. The first measures npm-related product fingerprints. The second measures indexed domain matches. A report that places either number under a heading such as "victims" is misleading, even if the number is technically accurate. A report structure that stays honest Begin with the event and the primary sources. Then state the package evidence, the platform-specific execution evidence, the network indicators, and the external observations. Next, separate confirmed findings from possible exposure and open questions. End with decisions: which systems to inspect, which credentials to rotate, which persistence to remove, and which logs to preserve. Use the same nouns throughout. A package is a package. An asset observation is an asset observation. A victim is a person or organization with evidence of harm. When the evidence supports only the first three, write that. Why this helps defenders Clear evidence levels let a security team prioritize without overstating the incident. They can search for the package, inspect the endpoint, review the model and MCP configuration, and rotate credentials in a sequence tied to actual findings. They can also explain why a large external count did not trigger a company-wide breach notification. The Apex campaign is a strong reminder that AI supply-chain risk is often ordinary software supply-chain risk with new data paths. The package path, endpoint behavior, identity exposure, and external infrastructure can all be investigated. Each one needs its own evidence. References Elastic Security Labs, REF8801 analysis GitHub Advisory Database, @apexacc/cli OSV, MAL-2026-17924 OSV, MAL-2026-17923 The Hacker News event report