OAuth lets Malveon ask a tool what changed. Webhooks let the tool tell Malveon the moment it happens, with no polling. The catch: a webhook endpoint is a public URL, and anyone who finds it can POST to it. So the first thing Malveon does with any incoming webhook is prove it is genuine.
Here is how that verification works, provider by provider.
Why an unverified webhook is a problem
A webhook endpoint that processes whatever it receives is an open door. An attacker who guesses the URL could inject fake deploy events, forged incident alerts, or bogus status changes. For a system whose whole job is to be the trustworthy view of what is happening, accepting unverified input would defeat the point.
HMAC signatures, checked per provider
Every major provider signs its webhooks. When you set up the integration, you and the provider share a secret. The provider hashes each request body with that secret and sends the result as a header. Malveon recomputes the same hash and compares. If they do not match, the request is rejected with a 401 before the body is ever parsed.
The header and scheme differ by provider, so Malveon checks each one the way that provider signs it:
- Slack: an x-slack-signature header, a v0 HMAC-SHA256 computed over the request timestamp and body.
- GitHub: an x-hub-signature-256 header, an HMAC-SHA256 of the payload.
- Jira: an x-hub-signature header, also SHA-256 based.
- Linear: a linear-signature header.
- Sentry: a sentry-hook-signature header.
- Datadog: an x-datadog-signature header.
A request that arrives without a signature, or with one that does not recompute correctly, never reaches the code that would act on it.
The endpoints that work differently
Not every provider ships HMAC signing by default. Microsoft Teams, Confluence, and Google Docs send change notifications that are not HMAC-signed out of the box, so those endpoints rely on different validation rather than pretending to verify a signature that is not there. Being explicit about that gap is part of doing this correctly. A verification step that silently passes everything is worse than none, because it looks safe.
Why this matters for what you see
The value of Malveon is that the deploy event, the incident alert, and the status change in front of you are real. Signature verification is the floor under that promise. Every event that makes it into your view cleared the check that it actually came from the tool it claims to come from.
Every webhook Malveon accepts is verified against the sending provider signature first. Spoofed events are rejected at the door, so the picture you act on is one you can trust.