Threat alerts: from a feed to a notification

1. The whole pipeline

One worker runs a loop every 60 seconds. The left side works only with public data and keeps one shared copy. The right side is per account.

The key design choice: nothing is queried in a customer's data when a threat arrives. Each account's software is copied into a normalized index ahead of time, so a new threat is one lookup across every account plus a version comparison in code.

2. What one feed record holds

The feed is one record per threat (an event, which can be several CVEs). Everything an account match needs is in affected: who the software is, which versions are hit and which fix it. Everything that decides who is told is in signals. This is the shape Zero's public catalog serves at GET /public/v1/threats?since=, trimmed.

{
  "id": "php2shell",
  "name": "PHP2Shell",
  "cves": ["CVE-2026-109618", "CVE-2026-109619"],
  "summary": "Two critical PHP flaws let anyone run code on a PHP web server",
  "severity": "critical",
  "tier": 1,
  "publishedAt": "2026-10-14T16:02:00Z",
  "affectedKnown": true,
  "affected": [
    { // the runtime itself, by upstream version
      "identity": { "kind": "runtime", "ecosystem": "runtime", "name": "php" },
      "aliases": ["php-fpm", "php-cli", "php8.3", "php8.3-fpm", "libapache2-mod-php8.3", "php83"],
      "scheme": "semver",
      "ranges": [ { "introduced": "8.1.0", "fixed": "8.1.34" },
                  { "introduced": "8.2.0", "fixed": "8.2.30" },
                  { "introduced": "8.3.0", "fixed": "8.3.29" } ],
      "fixedVersions": ["8.1.34", "8.2.30", "8.3.29"] },
    { // a distribution's own package: its fixed version includes backported patches
      "identity": { "kind": "os-package", "ecosystem": "deb", "name": "php8.2" },
      "distro": "debian:12", "scheme": "deb",
      "ranges": [ { "fixed": "8.2.30-1~deb12u1" } ], "fixedVersions": ["8.2.30-1~deb12u1"] },
    { "identity": { "kind": "os-package", "ecosystem": "apk", "name": "php83" },
      "distro": "alpine:3.20", "scheme": "apk",
      "ranges": [ { "fixed": "8.3.29-r0" } ], "fixedVersions": ["8.3.29-r0"] },
    { // the official container image, by tag
      "identity": { "kind": "runtime", "ecosystem": "image", "name": "php" },
      "scheme": "semver", "ranges": [ { "introduced": "8.1.0", "fixed": "8.3.29" } ], "fixedVersions": ["8.3.29"] }
  ],
  "signals": {
    "cvss": 9.8, "epss": null, "kev": false,
    "unauthenticated": true, "remoteCodeExecution": true,
    "exploitPublic": false, "exploitedInTheWild": false, "vendorEmergencyRelease": true,
    "named": true, "widelyUsed": true,
    "attention": ["attention:cisa", "attention:news-a", "attention:news-b"],
    "agreeingSources": ["cve-list", "vendor:php"]
  },
  "references": [ { "label": "PHP 8.3.29 release announcement", "url": "https://www.php.net/..." } ],
  "revision": 3
}

The ranges above are simplified to show the shape. Kinds are package (a library in a package manager: npm, Maven, PyPI, Composer…), runtime (php, node, openssl, and container images by tag), os-package (deb, rpm, apk, tied to a distro release) and product (vendor/product, for appliances and hosted software).

3. Sourcing each part of the record

Each field has a best source. The rule that keeps the feed safe: structured sources win, the LLM fills what only text says, and code decides anything that changes who is alerted. The last column is how ArmorCode's LLM research step should get it.

4. The LLM research step, broken down

One research run per candidate threat, in six stages. Blue stages are plain code; purple stages are the LLM.

The research agent's tools

Guardrails for the run: the LLM reads public pages only and never sees customer data; page text is untrusted (instructions in a page are ignored); a cap on searches and fetches per run; and output that fails verification goes out as "We're still working out which versions are affected", never as "not affected".

5. Example: researching PHP2Shell

What one run looks like, step by step. PHP is a runtime, not a library, so the package databases have nothing on it; that's exactly where research earns its keep. Versions and pages are illustrative.

Later revisions come from the same loop: KEV listing it sets exploitedInTheWild, a Red Hat fix adds an rpm entry, and each revision re-runs matching for every account.

6. PHP2Shell, minute by minute

Each stage has a one-minute budget. The clock starts when the first watched source shows the vulnerability; NVD isn't on the path, because it often takes days.

7. Is an account affected?

Never a bare yes or no. A wrong "you aren't affected" on a Log4Shell-sized day is the worst thing we could say, so Not exposed needs complete coverage.

How one match is decided

Each affected entry in the threat meets each row of an account's index. This is the whole "is this customer affected?" test.

Rolled up per account: any Confirmed or Likely makes the answer Exposed. None, with everything checked, is Not exposed. None, with gaps or unknown versions, is Not found so far.

8. The queries, source by source

Nothing is queried in a customer's data when a threat arrives. Instead, each account's SBOM, assets and findings are read ahead of time, turned into one normalized row per piece of software per place, and kept in an index. At alert time there's one lookup against that index. Below: for each source, the request, one row that comes back, and the index row it becomes.

-- every component version, paged
POST /api/components/list
{ "page": 0, "size": 100 }

-- then, per component version,
-- the repos that use it
GET /api/components/{compositeId}
    /sub-products?page=0&size=100

{ "compositeId": "c-77120",
  "name": "php:8.3.12-fpm",
  "version": "8.3.12-fpm",
  "purl": null,
  "packageManager": null,
  "componentType": "container" }

sub-products:
[{ "subProductId": 8812,
   "name": "checkout-api",
   "productName": "Payments" }]

{ "kind": "runtime",
  "ecosystem": "image",
  "name": "php",
  "version": "8.3.12-fpm",
  "location": { "kind": "repo",
    "id": "8812", "name": "checkout-api",
    "application": "Payments" },
  "source": "sbom",
  "confidence": "confirmed" }

-- every asset, paged
POST /api/v2/assets
{ "page": 0, "size": 100 }

-- properties (images, runtime,
-- engine) come with the details
GET /api/v2/assets/{id}

{ "id": "55120",
  "name": "web-04",
  "kind": "HOST",
  "active": true,
  "os": "Debian GNU/Linux 12",
  "internetExposure": "TRUE",
  "properties": {
    "imageNames": ["php:8.2.18-apache"]
  } }

{ "kind": "runtime",
  "ecosystem": "image",
  "name": "php",
  "version": "8.2.18-apache",
  "distro": "debian:12",
  "location": { "kind": "host",
    "id": "55120", "name": "web-04",
    "internetFacing": true },
  "source": "asset",
  "confidence": "likely" }

componentName, componentVersion,
filePath, cves, status,
subProduct (repo), product (app),
lastSeen

-- from the raw row, where kept:
purl, packageManager,
asset { id, name, armorCodeType,
        internetExposure }

// a host scanner
{ "componentName": "php8.2",
  "componentVersion": "8.2.30-1~deb12u1",
  "asset": { "id": 55120,
    "armorCodeType": "HOST" } }

// a container scanner
{ "componentName": "php",
  "componentVersion": "8.2.18",
  "filePath":
   "php:8.2.18-apache (debian 12.5)",
  "subProduct": "billing",
  "lastSeen": "2026-10-03" }

// version suffix ~deb12u1 → deb
{ "ecosystem": "deb",
  "name": "php8.2",
  "version": "8.2.30-1~deb12u1",
  "distro": "debian:12",
  "location": "host web-04",
  "confidence": "likely" }

// scan target → image + runtime
{ "ecosystem": "runtime",
  "name": "php", "version": "8.2.18",
  "location": "image php:8.2.18-apache",
  "evidence": "Seen in a scan on Oct 3",
  "confidence": "likely" }

-- unresolved findings for the
-- threat's CVEs, counted by repo
POST /api/v2/findings/groups/count
{ "field": "subProduct",
  "filters": { "aqlQueryV2": [
   "(cve IN ('CVE-2026-109618',
             'CVE-2026-109619'))
    AND (status IN (<the account's
         unresolved statuses>))" ] } }

{ "8812": 3,
  "9031": 1 }
-- repo id → open findings

checkout-api (8812): confirmed
billing (9031):      confirmed

-- a repo with a finding but no
-- index row is added as confirmed

(runtime, php)   (runtime, php-fpm)
(image,   php)   (deb, php8.2)
(deb, php8.3)    (deb, php8.3-fpm)
(deb, libapache2-mod-php8.3)
(rpm, php)       (apk, php83)
…

SELECT s.*,
  s.internet_facing
   OR coalesce(c.internet_facing,false)
   AS facing
FROM ac.account_software s
LEFT JOIN ac.account_software_coverage c
  ON c.tenant_id = s.tenant_id
 AND c.location_kind = s.location_kind
 AND c.location_id = s.location_id
JOIN unnest($ecosystems, $names)
  AS q(ecosystem, name)
  ON s.ecosystem = q.ecosystem
 AND s.name = q.name
WHERE s.tenant_id = ANY($tenants);

image php 8.3.12-fpm
  → leading version 8.3.12
  → semver: in [8.3.0, 8.3.29)
  → affected, SBOM → confirmed

deb php8.2 8.2.30-1~deb12u1
  → debian:12 fixed 8.2.30-1~deb12u1
  → deb compare: not below fix
  → not affected (patched)

runtime php (no version)
  → unknown version

ac.account_software_coverage
  location (repo / image / host / cloud)
  has_sbom            -- a complete SBOM crawl listed it
  has_software_facts  -- the asset lists its software
  covers              -- kinds listed in full: package,
                      -- runtime, os-package, product
  scanned_at, internet_facing

for each place:
  covered = the place lists, in full, every
            kind of software the threat affects

no matches and every place covered → Not exposed
no matches, some places not covered → Not found so far
  "38 repos have no SBOM yet"
any confirmed or likely match       → Exposed

Worked example (illustrative account)

This account's answer: Exposed, 3 places, 1 internet-facing, and legacy-portal listed as couldn't check.

9. Doing this inside ArmorCode

ArmorCode owns the SBOM, asset and finding data, so it doesn't need Zero's API crawl. It has two ways to answer "is this tenant affected?"

Whichever is used, the live-query version of the three reads looks like this (pseudocode against ArmorCode's own tables; field names are illustrative):

-- SBOM: components named like the threat's entries or aliases
SELECT component, version, purl, sub_product, product
FROM sbom_components
WHERE tenant_id = :tenant
  AND (purl_type, lower(name)) IN (('docker','php'), ('deb','php8.2'), ('apk','php83'), …)
     OR lower(name) IN ('php', 'php-fpm', 'php8.3-fpm', 'libapache2-mod-php8.3', …);

-- Findings: the CVE itself (confirms), or the component (likely)
SELECT sub_product, asset_id, component_name, component_version, last_seen
FROM findings
WHERE tenant_id = :tenant AND status IN (:unresolved)
  AND (cve && ARRAY['CVE-2026-109618','CVE-2026-109619']
       OR lower(component_name) IN ('php', 'php8.2', 'php8.3', 'php83', …));

-- Assets: images, runtimes and engines that name the software
SELECT asset_id, kind, os, internet_exposure, image_names, runtime
FROM assets
WHERE tenant_id = :tenant AND active
  AND (EXISTS (SELECT 1 FROM unnest(image_names) i WHERE i ~ '(^|/)php:')
       OR runtime ILIKE 'php%');

-- Then, in code, for every row: compare the version with the entry's ranges using the
-- ecosystem's comparator (semver, maven, pep440, composer, deb, rpm, apk); a distro row
-- against that distro's fixed version; an unreadable version is "unknown", never "not affected".

10. Eng's questions, answered