Github Webhook Laravel Package

Product Decisions This Supports

• Whether to build the GitHub integration in-house or assemble it from packages. Webhook ingestion is the front door of any GitHub integration (PR status sync, CI check display, deploy triggers, issue sync, release notifications, Slack/Teams alerts). This package covers the two unavoidable pieces — HMAC signature validation and payload parsing — so it directly de-risks the "first slice" of that roadmap item.
• Build vs. buy on a very small surface area. The package's real value is roughly 100–200 lines of hash_hmac comparison plus JSON decoding and event/delivery header extraction. That is a genuine build-vs-buy call: adopting a dependency buys maybe 1–2 engineer-days and hands you a maintenance obligation on a security-sensitive path.
• Security posture decisions, not just feature decisions. Because signature validation is the trust boundary for anything GitHub sends us, choosing this package is implicitly a decision about secret management, secret rotation, constant-time comparison, and support for both sha1 and sha256 signatures. That's a decision worth escalating beyond the feature team.
• Which integration model to fund next. If webhooks are only the first step, the roadmap forks: a lightweight "receive events" service (this package is sufficient) versus a full GitHub App (installation tokens, OAuth, rate limits, retries, idempotency — all out of scope here). Deciding now prevents re-platforming in two quarters.
• Use cases this unblocks cheaply: internal CI/CD dashboards, auto-labeling and PR hygiene bots, deployment tracking tied to merge events, mirroring GitHub issues into an internal tracker, and PR-review nudges in chat. Each is a small, independently shippable increment on top of a single webhook endpoint.
• A "vendor and own it" option. Given the small surface and the package's age, the strongest product decision this assessment supports may be to absorb the logic into our codebase under our own tests rather than carry a stale third-party dependency on a security boundary.

When to Consider This Package

Reasonable fit when:

• You need only the two primitives — verify the X-Hub-Signature-256 header against the raw body, then decode the JSON and read X-GitHub-Event / X-GitHub-Delivery.
• You're prototyping or shipping an MVP and the cost of writing and testing HMAC verification yourself genuinely exceeds the cost of a dependency.
• You have a single GitHub org, modest webhook volume, and no multi-tenant or per-customer secret requirements.
• You're comfortable pinning a specific version and owning it — MIT license means forking is trivially permitted.

Look elsewhere — or write it yourself — when:

• Maintenance risk is disqualifying. Last release was November 2020; there's no evidence of PHP 8.2/8.3/8.4 or Laravel 10/11 support. On a modern stack, expect to patch it on day one. Eleven stars and effectively a single maintainer is a bus-factor of one.
• You need anything beyond ingestion. GitHub App installation tokens, OAuth flows, rate-limit backoff, webhook retries, replay protection, idempotency keys, or event fan-out are all out of scope and will be your code anyway.
• You're in a regulated or security-reviewed environment. A five-year-old unmaintained dependency on an authentication path is a hard sell to a security reviewer, and the alternative is short enough to read in a code review.
• You need robust behavior around raw request bodies. Signature checks fail silently if a framework middleware has already transformed the payload; verify that the package's assumptions match your Laravel version's request lifecycle before committing.
• You want first-class observability — structured logs, metrics on rejected signatures, alerting on signature failures — which you'll be adding around it regardless.

Practical recommendation: treat this as reference material rather than a dependency. Read it, absorb the approach, and ship a tested in-house validator (~half a day including tests) unless a spike proves the package drops in cleanly on your current PHP/Laravel versions.

How to Pitch It (Stakeholders)

To executives (one paragraph): We need a trustworthy way to receive events from GitHub so we can automate code-review workflow, deployment tracking, and issue sync. This package does the security-critical part — confirming a request genuinely came from GitHub — and it's MIT-licensed and free. The catch is that it hasn't been updated since 2020, and the code it contains is small enough that we can own it ourselves for roughly half a day of engineering. My recommendation is to fund the capability, not the dependency: we get the same roadmap outcome with less long-term risk and no third-party code on our security boundary.

To engineering: The package is a thin wrapper over HMAC verification plus JSON decoding — real value is about a day of work, and it's on an authentication path. Given no releases since 2020, unknown PHP 8.3/Laravel 11 compatibility, and a single maintainer, I'd rather vendor ~100 lines into our own service with tests covering both SHA-1 and SHA-256 signatures, missing-header rejection, constant-time comparison, and raw-body handling. If a one-hour spike shows it installs cleanly and passes those tests, keep it pinned and wrap it; otherwise we ship our own. Either way the feature estimate doesn't move.

To security/architecture: Flagging explicitly that this decision touches request authentication. Asking for a review of the signature-verification approach and secret rotation plan before we commit, independent of whether we use the package or our own implementation.