01 Signal
Advisories, exploitation and runtime releases
MopokeHQ pulls the public sources that matter for npm, Composer and PHP teams and keeps its own copy, so matching never waits on someone else's API.
How MopokeHQ works: from advisory to verified fix
Every vulnerability goes through the same seven steps. The rules for each one are on this page, so you can see why something is a P1 and what closes it.
| Source | What it adds |
|---|---|
| OSV | Advisories for npm, Packagist and more, with affected version ranges |
| php.net | PHP security releases, so a runtime upgrade is an action like any other |
| CISA KEV | Vulnerabilities known to be exploited in the wild |
| FIRST EPSS | The daily probability that a CVE will be exploited |
02 Match
Every SBOM, re-checked on every advisory
The scan job builds an SBOM on your runner and uploads it. MopokeHQ stores it and re-matches every stored SBOM whenever an advisory lands, so old releases are checked against new CVEs without a rescan.
Each exposure is tied to where the code runs. Deploy reports turn Likely live into Confirmed live.
- Confirmed live
- Seen in a reported deployment
- Likely live
- On the default branch, no deploy report yet
- Possible
- Only on another branch
.gitlab-ci.yml
deploy-production: stage: deploy environment: production script: - ./deploy.sh after_script: - !reference [.mopoke-deploy, script]03 Triage
Priority from facts you can check
Severity alone sends you chasing CVEs that never run. MopokeHQ combines CVSS severity, known exploitation, EPSS, live confidence and how critical the project is, then sets a deadline.
| Priority | When | Alert | Default SLA |
|---|---|---|---|
| P1 | Known exploited, malicious package, critical and confirmed live, or a runtime security release | Email straight away, escalated to the whole organisation after 4 hours without acknowledgement | 48 hours |
| P2 | Critical or high, or EPSS of 0.1 or more | Daily digest | 14 days |
| P3 | Everything else that applies | Weekly digest | 30 days |
One email per burst of advisories, grouped by fix. Lilly adds a plain-language note to each alert and can suggest "not affected" on P2 and P3. It never holds back a P1.
What KEV, EPSS and VEX mean here
- CISA KEV
- The US Cybersecurity and Infrastructure Security Agency’s catalogue of vulnerabilities known to be exploited in the wild. A KEV match makes an exposure a P1.
- EPSS
- FIRST’s Exploit Prediction Scoring System: a score from 0 to 1 estimating how likely a vulnerability is to be exploited. An EPSS score of 0.1 or more makes an exposure at least a P2.
- VEX
- A Vulnerability Exploitability eXchange statement records that a product is or is not affected by a vulnerability. Confirming “not affected” in MopokeHQ stores one, with your reason.
04 Fix
A queue of upgrades, not a pile of CVEs
The Now screen groups findings by the upgrade that closes them, across projects, in three tiers: Now, This week and Later. Each line says what to change, where, and by when.
Merge request pipelines only fail on new findings. Existing debt goes on the roadmap instead of blocking every merge. A scheduled mopoke act job in your runner can open fix merge requests, so MopokeHQ never needs write access to GitLab.
- Upgrade laravel/framework to 11.34.24 projects11h
- Upgrade PHP to 8.3.147 projects31h
- Upgrade axios to 1.7.95 projects5d
- Rebuild images on node:22.11-alpine3 images6d
- Replace papercut/pdf-renderno fixed versionLater
05 Verify
Closed when it is fixed in production, not when someone says so
MopokeHQ closes an exposure on its own only when the fixed version shows up in a reported deployment. If the fix exists only on a branch, it waits for one click from a person, and that click is logged.
- Fixed version deployed
- Closed automatically
- Fixed on main, not deployed
- Waiting for confirmation
- Fixed on a branch
- Waiting for confirmation
- Reverted later
- Reopened with a fresh alert
06 Tell
Clients hear about it from you, in plain English
For agencies and MSPs, projects belong to clients. When a fix is confirmed live, Lilly drafts the notice. A person approves it and it sends from your domain. Nothing Lilly writes ever sends itself.
For agencies and MSPs- Default
- Notice when the fix is confirmed live
- Per contract
- Notice at discovery instead
- Monthly
- A security digest per client
- Branding
- Your domain, your logo, your portal
- Possible incident
- Signs of compromise stop the template and flag it
07 Prove
Evidence as a side effect of doing the work
Every step above is written to an append-only, hash-chained log. Choose a framework and a period and MopokeHQ builds the evidence pack: a PDF for people, and JSON with the chain hashes so anyone can check nothing was changed.
Compliance evidence- Essential Eight
- Patch applications, patch operating systems
- ISO 27001:2022
- Annex A 8.8
- SOC 2
- CC7.1
- Format
- PDF plus JSON with chain hashes
Lilly, MopokeHQ’s AI
Where Lilly fits
Lilly writes a plain-language note on each alert: what the advisory means for this package and version. On P2 and P3 it may suggest “not affected”, which you confirm or override with one click.
It sees the package, version, extensions and public advisory text. Never your source code. If it is down, out of credits or switched off, alerts still send.
- Never
- Silences a P1
- Never
- Closes an exposure
- Never
- Sends anything to a client by itself
- AI off switch
- Turns AI off, alerts still send
Questions
What is vulnerability prioritisation?
Deciding which vulnerabilities to fix first. MopokeHQ decides with published rules that combine CVSS severity, CISA KEV, FIRST EPSS, whether the vulnerable version is live, and project criticality. The result is a P1, P2 or P3 with a default SLA of 48 hours, 14 days or 30 days.
What is the difference between CVSS and EPSS?
CVSS rates how severe a vulnerability is. EPSS, from FIRST, estimates how likely it is to be exploited. MopokeHQ uses both: critical or high severity makes an exposure a P2, and so does an EPSS score of 0.1 or more. Known exploitation makes it a P1.
What does a CVSS score of 9.8 mean?
Under CVSS v3, scores from 9.0 to 10.0 are rated critical, so 9.8 is critical. In MopokeHQ a critical finding is a P2 by default. It becomes a P1 when it is confirmed live or known exploited.
How is this different from running npm audit or composer audit in CI?
Audit commands check one project at the moment the pipeline runs. MopokeHQ keeps every SBOM and re-checks all of them whenever a new advisory lands, knows which versions are actually deployed, groups findings by the upgrade that fixes them across projects, and keeps a log you can hand to an auditor.
How does MopokeHQ know what is running in production?
From deploy reports. GitLab deployment events, a mopoke deploy step after your deploy job, or an optional runtime check-in each tell MopokeHQ which commit is live in which environment. Without a deploy report, exposures stay at Likely or Possible.
When does MopokeHQ mark a vulnerability as fixed?
Only when the fixed version is seen deployed. A fix that exists only on a branch waits for one logged click from a person.
Will MopokeHQ fail my pipelines?
The scan job never fails a pipeline because MopokeHQ is unreachable. Merge request gates only fail on new findings, by default a new critical, a new secret or a new known-exploited dependency, so existing debt goes on the roadmap instead of blocking every merge.
Put a mopoke on night watch
One job in your CI pipeline. Your first SBOM is matched against every advisory we hold within minutes.