Not every finding should block
A release decision needs severity, exposure, supported impact, freshness, and product context.
Release decision
Use pre-release security validation to decide what should block a release.
Run the supported checks relevant to the change, review the highest-priority evidence, and keep the final release decision with the engineering team.
Why This Matters
Some evidence needs immediate action
A sensitive exposed credential or supported high-impact code finding may justify stopping the release.
The decision needs a later check
Revalidate after remediation so the release record reflects current supported evidence.
What SecOpsium Scans
- Supported secrets and code findings on the selected repository branch.
- Supported public web exposure when a target URL is validated.
- Supported GitHub repository controls when configuration audit is selected.
- Previous scan results for comparison.
Validation workflow
- 1Select the repository, branch, and relevant validation scope.
- 2Run the validation before the release decision.
- 3Review high-priority findings and unknown impact.
- 4Decide what blocks, what requires review, and what can follow.
- 5Revalidate the remediated scope before shipping.
Frequently Asked Questions
What should block a release?
The team should decide using current severity, exposure, supported impact, exploitability context, and the product's risk tolerance.
Can this replace release review?
No. It provides scoped evidence for the team's release process.