Listen to this Post
Introduction
GitHub remains a cornerstone of modern software development, but its security practices around webhooks and app keys need modernization. Matt Moore, Founder and CTO at Chainguard, highlights two critical areas for improvement: replacing long-lived shared secrets with OIDC tokens in webhooks and allowing GitHub App keys to be generated externally. These changes would enhance security by reducing exposure to credential leaks and ensuring end-to-end payload integrity.
Learning Objectives
- Understand the risks of long-lived shared secrets in webhooks and the benefits of OIDC tokens.
- Learn why externally generated GitHub App keys improve security over UI-generated keys.
- Explore practical steps to implement these security improvements in your workflows.
You Should Know
1. Securing Webhooks with OIDC Tokens
Problem: GitHub currently relies on long-lived shared secrets for webhook authentication, which can be compromised or leaked.
Solution: Replace shared secrets with OIDC tokens containing:
- The webhook endpoint URI as the `aud` (audience) claim.
- A payload checksum in a custom claim to verify integrity.
Implementation Steps:
- Verify the OIDC Token: Use GitHub’s public keys to validate the token’s signature.
curl -s https://api.github.com/.well-known/openid-configuration | jq .jwks_uri
Fetch the JWKS (JSON Web Key Set) to verify the token.
Check the Audience Claim: Ensure the `aud` matches your webhook URL.
import jwt decoded = jwt.decode(token, options={"verify_signature": False}) assert decoded["aud"] == "https://your-webhook-endpoint.com"
Validate Payload Integrity: Compare the payload checksum against the custom claim.
2. Generating GitHub App Keys Securely
Problem: GitHub generates private keys in the UI, exposing them to GitHub and the user.
Solution: Let users provide a public key for verification while keeping the private key in a secure KMS (Key Management System).
Implementation Steps:
- Generate a Key Pair Securely: Use a KMS or
openssl
.openssl genpkey -algorithm RSA -out private_key.pem -pkeyopt rsa_keygen_bits:4096 openssl rsa -pubout -in private_key.pem -out public_key.pem
Upload the Public Key: Provide `public_key.pem` to GitHub instead of letting GitHub generate the key.
Use the Private Key Securely: Never expose it; sign requests via KMS.
3. Hardening Docker Webhooks (Bonus)
As noted by Jason Hall, Docker webhooks lack secrets entirely (GitHub Issue 51).
Mitigation:
- Use a reverse proxy to add authentication.
- Validate source IP ranges (if Docker provides fixed endpoints).
4. Cloud Hardening for Webhook Endpoints
Best Practices:
- Restrict webhook endpoints to GitHub’s IP ranges.
GitHub’s Meta API for IP ranges curl https://api.github.com/meta | jq .hooks
- Use API gateways (e.g., AWS API Gateway) to enforce rate limiting.
5. Monitoring and Rotation
- Rotate secrets (or OIDC tokens) periodically.
- Monitor for anomalous webhook activity using SIEM tools.
What Undercode Say
- Key Takeaway 1: OIDC tokens eliminate shared secrets, reducing attack surfaces.
- Key Takeaway 2: Externally generated keys ensure private keys never leave secure systems.
Analysis:
GitHub’s current practices lag behind modern security standards. Adopting OIDC tokens and external key generation would align with zero-trust principles. The Docker webhook issue underscores broader industry gaps in securing CI/CD pipelines. Enterprises should pressure vendors to adopt these improvements while implementing interim safeguards like IP restrictions and KMS-backed signing.
Prediction
Within two years, expect GitHub and other platforms to phase out shared secrets in favor of OIDC/OAuth 2.0. Cloud providers will integrate more KMS solutions for key generation, reducing manual key handling. Developers who adopt these practices early will mitigate credential-based attacks and streamline compliance audits.
IT/Security Reporter URL:
Reported By: Mattmoor There – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅