01
Source review
Assess the release branch or commit with notes about the changed trust boundaries and customer impact.
Release security review
Make the release decision from the product that will ship.
Combine source review, binary analysis, and authorized staging tests in one project so release owners can see what changed, what survived validation, and what still requires action.
Source baselineShipped artifactStaging behavior
release://promotion-gateprocessing
source = artifact
signature valid
staging clean
v1.14.0release candidate
PROMOTED ✓
HOLD · fix before promote
surface differences stay attached to the same release decision
Capabilities
Three different security truths in one release
The repository shows intended behavior. The artifact shows packaging and embedded content. Staging shows how identity, routing, configuration, and network controls behave together.
02
Artifact review
Inspect the APK, JAR, installer, firmware, archive, or packaged output that will be delivered.
03
Authorized staging test
Probe runtime behavior when exploitability depends on roles, tenants, gateway behavior, or deployment configuration.
04
Adversarial validation
Pressure-test consequential findings before making a release, remediation, or disclosure decision.
05
Release handoff
File accepted work, generate a candidate fix, or create an explicit accepted-risk decision with reason.
06
Evidence preservation
Tag the release, retain the assessment versions, and export a reviewed record for the decision.
How it runs
Baseline, check the artifact, exercise staging, decide
The four checks standing behind a go / no-go decision.
Baseline
Review source at the release candidate and identify important changes and inherited risk.
Verify artifact
Assess the build output for packaging, manifest, secret, update, or decompilation-visible failures.
Exercise staging
Test only the live behaviors that require deployment context and explicit authorization.
Decide
Resolve critical and high findings, record exceptions, and preserve the evidence supporting promotion.
Outcomes
A decision you can defend afterwards
Coverage across the delivery chain, and a record of why the release shipped.
A clearer go/no-go decision
Separate validated release risk from low-confidence claims and unrelated historical noise.
Coverage across the delivery chain
Catch failures introduced by code, build, packaging, and runtime configuration.
A durable release record
Keep the report, findings, exceptions, remediation, and retest aligned to the version that shipped.
Evaluation FAQ
Questions about release review
Whether every release needs all three surfaces, and how much can be automated.
Do we need all three scan surfaces for every release?
No. Use the surfaces that can change the decision. Source is the normal baseline; add binary or live testing when packaging or runtime behavior materially affects risk.
Can a release review use changed-code scanning?
Yes, but a major release or significant architecture change may justify a broader source review. The right depth depends on change size, exposure, and prior baseline quality.
Can ZeroQuarry make the release decision automatically?
ZeroQuarry provides assessment evidence, review signals, and traceable decisions. Your organization remains responsible for business context and final release authority.
Related workflows
Artifact and staging review
Review the next release you ship
Check the artifact and staging before promotion, and keep the record.