Municipal CI receives Git webhooks for the housing portal. How should the pipeline reject forged start requests?
Select an answer to reveal the explanation.
Short Explanation
Webhook signature checks are the bouncer at the housing CI door—forged POSTs get turned away. Open secrets and wide-open listeners invite fake pipeline starts.
Full Explanation
Webhook receivers must authenticate Git events before starting jobs. For municipal housing-portal CI, that means validating webhook signatures or shared secrets on each request so only authentic Git server events can start builds. Signature verification is the control that rejects forged HTTP POSTs to the listener URL. Civic systems that accept unauthenticated triggers risk running untrusted pipeline code, exhausting runners, or promoting attacker-controlled artifacts under the housing portal's identity.
Accepting every HTTP POST with no signature check fails by concept because anyone who discovers the URL can start jobs. Publishing the webhook secret in the public open-data catalog fails because a published shared secret is no longer a secret; attackers can sign forged payloads at will. Disabling authentication on the CI listener so anonymous callers can trigger builds fails by removing the trust boundary entirely and inviting unauthorized pipeline starts.
Exam caveat: validating signatures proves the event came from a holder of the webhook secret (typically the Git host); it does not replace branch protections, CODEOWNERS, or secret scanning inside the pipeline. Also, "transparency" for open government data catalogs must never include CI webhook secrets—public datasets and private trigger credentials are different classes of information.
Operational check: send a correctly signed test webhook and confirm the housing-portal job starts; replay an unsigned or wrongly signed POST and confirm the listener rejects it with no job. Rotate the webhook secret and verify old signatures fail while new ones succeed.