README

Reports the installed composer packages of a Magento 2 instance to Zabbix, so that known vulnerabilities in them become visible in monitoring.

The Magento side only answers with an inventory. The matching against the advisory data happens on the Zabbix server, so the shop needs no outgoing connection, no composer binary and no exec().

Shop host                          Zabbix server
─────────                          ─────────────
bin/magento security:packages
  Composer\InstalledVersions
  → {"packages": {...}}
        │
        │  Zabbix agent (passive)
        └──────────────────────▶  magento-security-audit.php
                                    zabbix_get → inventory
                                    packagist.org → advisories (cached 6 h)
                                    Composer\Semver\Semver::satisfies()
                                    → {count, bySeverity, vulns, coreCovered}
                                          │
                                          └─▶ counters per severity → triggers

Install

Shop:

composer require wapplersystems/module-zabbix-client
bin/magento module:enable WapplerSystems_ZabbixClient
bin/magento setup:upgrade

Then copy contrib/zabbix-agent/magento.conf into /etc/zabbix/zabbix_agent2.d/, adjust the path to bin/magento, and restart the agent.

Zabbix server: see contrib/zabbix-server/README.md.

Zabbix frontend: import contrib/zabbix-template/magento-composer-security.yaml and assign the template to the shop host.

Why the matching does not run in Zabbix JavaScript

Magento patch releases carry a -pN suffix. Composer normalizes 2.4.4-p9 to 2.4.4.0-patch9 and sorts it above the plain 2.4.4 — the patch release is the newer one. A hand written semver comparison reads -p9 as a pre-release, sorts it below, and reports a fully patched shop as vulnerable.

That is the worst failure mode a security check can have, so the comparison is left to composer/semver, which is why this half runs in PHP.

For the same reason OSV.dev is not used as the source: it carries no Packagist advisories for Magento at all. Even 2.4.3, affected by CVE-2022-24086, comes back with zero hits.

What is deliberately not reported

Four groups are kept out of the checkable set, because each would produce wrong answers:

• the root package — the project itself is not published,
• replaced and provided virtual packages — no code, no version,
• dev requirements, unless --include-dev is given,
• packages installed from a branch (dev-main, 2.4.x-dev).

The last one matters most. A branch name is not a comparable version, and an advisory database that cannot parse it treats every advisory of that package as a hit. These are reported separately under unresolved, so they stay visible without becoming permanent false alarms.

Coverage, and where it ends

Advisories for the Magento core are filed against the meta packages magento/product-community-edition, magento/project-community-edition and magento/community-edition — not against magento/framework or the individual modules.

An installation shipping none of them has no core coverage. Mage-OS is the practical case: its packages live under mage-os/*, which Packagist does not track, and the magento/* packages it replaces carry no version of their own. Third party libraries are still checked normally, but a finding count of zero says nothing about the core.

The result therefore carries coreCovered, and the template raises its own trigger when it is false — rather than letting the blind spot pass as a clean result.

License

GPL-3.0-or-later