MopokeHQ watches every SBOM your pipelines upload, matches new advisories the moment they land, and turns hundreds of findings into a short list of upgrades. Deep GitLab integration today, with GitHub, Gitea, Forgejo and Bitbucket next.
Early access. Works behind a firewall, because nothing connects in.
Finding CVEs is the easy part. MopokeHQ runs the whole response, then keeps the proof your auditor and your clients ask for.
OSV, php.net, CISA KEV and EPSS feeds, pulled continuously.
Every stored SBOM is re-checked when an advisory lands.
Priority from severity, exploitation, and where it runs.
One action per upgrade, grouped across projects.
Closed only when the fixed version is seen deployed.
Client notices drafted for you, sent by a person.
A hash-chained log and one-click evidence packs.
Most scanners only look when a pipeline runs. MopokeHQ keeps every SBOM and re-matches all of them whenever a new advisory is published, so a CVE disclosed tonight is matched against the release you shipped three weeks ago. No rescan, no new pipeline.
How matching worksguzzlehttp/guzzleOSV, 01:58Every exposure carries its confidence. Deploy events from GitLab, a mopoke deploy step in any CI or a runtime check-in tell MopokeHQ what is actually running. Uncertain states are set in italics, the same way they are in the app.
MopokeHQ closes an exposure on its own only when the fixed version is seen deployed. A fix that exists only on a branch waits for one logged click from a person.
| Deployment | Version | Confidence |
|---|---|---|
| booking-api, production | 7.8.1 | Confirmed live |
| booking-api, main | 7.8.1 | Likely live |
| client-portal, feature/pay | 7.9.0 | Possible |
| client-portal, production | 7.9.2 | Fixed, closed automatically |
The Now screen lists actions, not advisories. Findings are grouped by the upgrade that closes them, across every project, so one PHP release that fixes twelve CVEs in seven projects is a single line with a single deadline.
Ordering is deterministic: priority first, then SLA, then confidence. You can always see why something sits where it does.
Example: findings on PHP 8.3.x
Lilly reads each matched advisory and writes a plain note on what it means for your package and version. It never sees your source code for triage, and it never decides on its own.
This advisory affects the multipart parser. client-portal never accepts uploads, and its routes do not use the parser, so this looks unlikely to apply there.
Applies: unlikely (0.12)
Group projects by client. When a fix is confirmed live, MopokeHQ drafts the notice in plain English. A person approves it, it sends from your own domain, and it is kept as evidence.
Security update for your booking site
A security fix for a component used by your booking site was published on Tuesday. We upgraded it the same day and confirmed the fixed version was live in production on Wednesday at 9:40am. There is no sign it was exploited, and there is nothing you need to do.
Every match, acknowledgement, fix and client message lands in an append-only, hash-chained log. Pick a framework and a period, and MopokeHQ produces the evidence pack: a PDF for people and JSON with the chain hashes for anyone who wants to check it.
c41f…9e028a3d…17bcf0e9…44a12b77…c3d891ce…0a5fOn GitLab, add the include and set one masked token on the group, and every project in it starts reporting. Anywhere else, the same CLI runs as a job in your pipeline. The scan runs on your runners and pushes out, so a server behind a firewall needs no changes.
include: - remote: https://app.mopokehq.com/ci/scan.ymlstages: - test - deployOn GitLab, then add MOPOKE_TOKEN as a masked CI/CD variable on the group.
You know where your data lives. SBOMs, scan results and evidence are stored in one region and encrypted per organisation. Sydney today, more regions coming. Lilly, the AI, sees minimal facts only, and one switch turns it off. Security and data
An SBOM (software bill of materials) lists every component in a build. SBOM management means keeping those lists for every build and acting on them over time. MopokeHQ stores the SBOM from each upload and re-checks it whenever a new advisory lands, so an old build still gets matched against a new CVE.
It takes the SBOMs and scan results your CI pipelines produce, matches them against vulnerability advisories as they are published, works out which findings are running in production, and turns them into a short list of upgrades with deadlines. Every step is logged as compliance evidence.
No. MopokeHQ is built for teams on GitLab Free and Premium, on gitlab.com or self-managed. The scan runs as a job in your own pipeline from one include line.
No. The mopoke CLI runs on your own runners and pushes results out. MopokeHQ never connects in, so a self-managed GitLab, Gitea or Forgejo behind a firewall works without any changes.
All stored data, including SBOMs, scan results and evidence, lives in one region: Sydney, Australia, with more regions coming. AI features send minimal facts to an AI provider outside that region, and one switch per organisation turns them off.
npm and Composer packages through OSV advisories, PHP runtime releases from php.net, and container images through image SBOMs. Exploitation signals come from the CISA Known Exploited Vulnerabilities catalogue and FIRST EPSS.
No. MopokeHQ produces evidence for your own ISO/IEC 27001:2022 Annex A 8.8, SOC 2 CC7.1 and Essential Eight controls. MopokeHQ itself does not hold SOC 2 or ISO 27001 certification.
Yes. Any CI that can run a container can call the mopoke CLI to upload an SBOM, so matching, priorities, alerts and evidence work today. GitLab has the deepest integration so far: merge request comments, fix merge requests and deployment events. Native GitHub, Gitea, Forgejo and Bitbucket integrations are coming.
One job in your CI pipeline. Your first SBOM is matched against every advisory we hold within minutes.