Request, review, revoke, and audit evidence-bound release exceptions.
On this page
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. Review actions require an authenticated person in the workspace.
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 supported release-authorization integration. Dashboard approval alone does not change GitHub branch rules or deploy your application.
The public documentation does not define a backend HTTP gate contract. Use the repository integration provisioned during enterprise onboarding; do not build a custom client against dashboard service routes.
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.
Ask the supported integration for a fresh authorization decision 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 workspace roles can export from the dashboard.
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.
