Skip to content
Fendix logo

Using release approvals

Authorize a specific release by exception while preserving its original security assessment. An approval does not fix findings or turn incomplete coverage into a clean scan.

All documentation

1. Before you start

  • Select an organization workspace in the dashboard. Release approvals are not available in a personal workspace. Organization MFA requirements still apply.
  • Use the latest completed scan from the GitHub PR integration. It must have a stored repository and full commit SHA, and a BLOCK, WARN or INCOMPLETE assessment. Queued, running, failed or unlinked scans cannot receive exceptions.
  • Members can request exceptions. A different admin or owner must review them; neither the requester nor the person who launched the scan can approve or reject. Viewers can read requests and export records. API keys cannot request, review or revoke.
  • A completed PASS with complete required coverage can pass the authorization gate without an exception.

2. Request an exception

  • Open the scan details and choose the release-approval request link, or open Release approvals in the sidebar and enter the scan ID.
  • Choose production or staging. Explain why the release is needed and describe the compensating controls that limit the risk, such as restricting access until a fix is deployed.
  • Set an expiry in the future, no more than 30 days away, and submit. The request captures the evidence and policy context for that exact scan and commit. It covers the whole scan, not selected findings.
  • Only one current pending or approved request is allowed for the same scan and environment. Ask an independent admin or owner to review it; this version does not send reviewer notifications.

3. Review and decide

  • Open Release approvals in the same organization and refresh the inbox. Check the target, repository, commit SHA, environment, expiry, original assessment and coverage.
  • Expand the evidence and assess the findings, business justification and compensating controls. Record a reason and choose Approve or Reject. Review buttons appear only for eligible reviewers.
  • An approved request displays Approved exception. The original BLOCK, WARN or INCOMPLETE assessment remains visible. Approval applies only to the bound release and environment.
  • Admins and owners can revoke a pending or approved request with a reason. Rejected or revoked requests cannot be reopened; create a new request when appropriate.

4. Check authorization before deployment

  • Your CI administrator must configure the release authorization gate. Dashboard approval alone does not change GitHub branch rules or deploy your application.
  • The gate checks the exact organization, repository, full commit SHA, target and environment using an organization-bound API key with scan:read. Keep the key in protected CI secrets. API clients must inspect authorized: true; HTTP 200 alone does not grant permission.
  • After the scan or review finishes, rerun the configured workflow for the same PR head SHA. The separate Fendix release authorization status can succeed while the original security assessment remains BLOCK. Requiring that original failed check as well will still block merging.
  • Run a fresh authorization check immediately before every deployment and stop if it fails. An earlier green GitHub status is historical: expiration or revocation does not automatically remove it. Never reuse a cached authorization result.
  • A merge or squash commit has a different identity from the scanned PR head. It needs matching scanned provenance; an approval for another SHA does not transfer.

5. Understand a denied or changed request

  • Pending: awaiting an independent review. Rejected or revoked: the exception does not authorize release. Expired: its deadline has passed.
  • Stale: the evidence or policy changed, a newer scan attempt exists, the original scan was deleted, or the reviewer is no longer eligible. Even a newer queued or failed scan can invalidate the previous approval.
  • Refresh the inbox to see the current state. Inspect the latest scan and resolve the cause, then request a new review if an exception is still needed. Extending an old deadline or approving another commit does not restore authorization.
  • If the review action is missing, check the selected organization, your role, MFA and whether you requested or launched the scan. If creation fails, check scan provenance, completion, assessment, expiry and existing requests.

6. Export the decision record

  • Choose the record export action on a request to download JSON containing the captured evidence, decision, identities, reasons and event history. Viewers and higher roles can export; API keys need reports:read.
  • Records retain the evidence snapshot after a scan is deleted, but that release permission becomes stale. Deleting the organization removes its records, so export them according to your retention policy.
  • The record is not a signed compliance certificate. This version supports one independent reviewer and JSON export; it does not include multi-step approval chains, signed PDFs or automatic reviewer notifications.
Open release approvals