The LogPulse Intelligence Hub does the groundwork centrally: for every relevant CVE a tested detection rule, a mitigation with clear steps and reusable SOAR actions. Your environment turns that into work for your team: a ticket, a block or a disabled account, and a check that it actually worked.
Most security tooling stops at the alert. Then someone has to look up the vendor advisory, write a ticket for the team that runs the system, chase it and check whether the patch actually landed. For one CVE that is manageable. With hundreds of exploited vulnerabilities a year, it is exactly the work that gets left behind.
LogPulse makes that follow-up part of the platform. The knowledge about a CVE (how to see it, how to fix it and what can be automated) is built once in the Intelligence Hub, tested and reviewed by a person. It then reaches every customer environment where it applies. Your team gets a clear task instead of one more alert to interpret.
The chain
Each step builds on the previous one, from the first signal to proof that the vulnerability is gone.
The hub follows CISA KEV, EPSS and NVD several times a day and matches them against your own vulnerability scans from Trivy, Grype or Snyk. You see which exploited CVEs are on your systems.
For every relevant CVE we build a detection rule with tests. It is published only after an engineer has reviewed it and it passes on an attack case and a benign case. Signed, it reaches every environment and watches for exploitation.
Every CVE gets a mitigation: a patch, a configuration change, a workaround or a compensating measure, with the steps from the vendor advisory and a deadline. Only environments running an affected version see it.
A reusable SOAR action carries out the mitigation or hands it off: a ticket for your IT, an IP block at the edge or a disabled account. Destructive actions always wait for an owner's approval.
A CVE counts as mitigated only when a new scan no longer reports it, a check in your logs returns zero or the rule stays silent. That way 'done' is proven, not just reported.
More about the first two steps? From CVE to detection
Almost every CVE calls for a patch or a configuration change on the system itself. LogPulse cannot do that for you. What can be automated fits in a short list: notify, enrich, block, disable and isolate. We build those actions once, with parameters and limits, and link them to each CVE where they help.
Native connections to TOPdesk, Jira Service Management and ServiceNow, with the status flowing back to the notable. Any other ITSM tool through e-mail or a webhook.
A message to e-mail, Slack or a webhook, with the notable, the risk score and the evidence attached.
Before anyone acts, every notable is matched against threat feeds and investigated by the AI Investigator, which writes down its reasoning.
Send the source address to your firewall through a webhook, or block it in Cloudflare with the managed template.
Destructive: only after an owner approves
Disable a compromised user in Microsoft Entra ID through Microsoft Graph, with the target account in the audit log.
Destructive: only after an owner approves
Isolate a machine through the API of your EDR, as a step of a mitigation.
Destructive: only after an owner approves
Connections
A scanner that tries the same exploit 400 times would otherwise bury your service desk. LogPulse creates one ticket per CVE per environment and adds every new sighting as a note to that ticket.
Closed by your IT? LogPulse then checks whether the CVE is gone and reopens the ticket with a note if it is not.
Response that blocks or disables things has to fit your own change and security policy. This is how we set it up.
Rules, mitigations and actions from the hub are published only after review by a LogPulse engineer and a passing test on an attack case and a benign case. Your environment only loads signed versions, so what arrives is exactly what was approved.
Blocking an IP or disabling an account is off by default. Once your organization switches it on, an owner approves each action individually. An action runs at most once and never without that approval.
For every action we record who requested it, who approved it, when, on which target and with what result. That gives your auditor and your CISO one record for NIS2, ISO 27001 and internal controls.
When a connected system adds a response action or trigger through the API or the MCP server, it arrives as a proposal. It only becomes active after someone with the right role approves it, so no automation appears outside your change process.
Every action gets a test run with a simulated notable. Connections run in test mode, so you see the exact request and the ticket as your ITSM would receive it, without anything going out.
Your own settings (parameters, approvals and disabled steps) sit as a layer over the signed base. A new version first shows the difference and can be rolled back, so updates come through without overwriting your arrangements.
Notify, tickets, blocking an IP and disabling an account, with action pipelines, approval steps, mitigations and the ITSM ticket per CVE, are in every plan, Free included. The managed SOAR actions from the hub, Detection Lab and the coverage report for NIS2 and ISO 27001 are in Pro (€59 per month) and Business (€199 per month).
Larger organization or MSP? Book a demo
Last updated: 6 November 2026
Free plan, no credit card. Connect your logs and scans and see today which CVEs are about you.