Ship quickly without making security a guess.
SaaS teams release many times a week. Fendix gives each release one explainable security decision — from the evidence you require, the coverage you actually got and the policy you committed — so delivery speed and security stop competing.
Where SaaS release security breaks down
Not for lack of scanners. For lack of a decision that holds up at deployment speed.
Releases outrun review
Several deploys a day leave no room for a manual security sign-off, so it either slows the pipeline or gets skipped.
Alert lists nobody reads
Every tool reports everything. A list that never shrinks teaches engineers to stop looking.
Fixed issues come back
A vulnerability fixed in March quietly returns in May, and nothing flags it as a regression.
Exceptions outlive their reason
A risk accepted under deadline pressure is still accepted a quarter later, with no expiry and no one reviewing it.
Green builds with missing evidence
The dependency scan fails, the build stays green, and “no findings” is read as “nothing to fix”.
Customer security reviews
An enterprise customer asks what was checked before the last release, and the answer is assembled by hand.
How a SaaS release gets its decision
The same seven steps run on every pull request and every deployment candidate.
- 1
Code or API change
A pull request or a release candidate triggers the pipeline job.
- 2
Security evidence
Fendix tests the running API and analyzes code, dependencies and secrets; SARIF from your other tools joins the same evidence.
- 3
What changed in this release
Baselines separate new findings from known ones, and tracking flags anything that was fixed and came back.
- 4
Required coverage
If an analyzer you require failed or never reported, the release is INCOMPLETE, not PASS.
- 5
Policy evaluation
Your committed threshold and confidence rules decide which findings block. By default, severity alone does not.
- 6
Release decision
PASS, WARN, BLOCK or INCOMPLETE, with the reason for each blocking or held-back finding.
- 7
Decision record
The decision, its evidence and the policy version are stored with the release for later review.
Three releases, three decisions
Illustrative scenarios with fictional services. Thresholds and outcomes depend on the policy you commit.
A new endpoint ships without an auth check
The live API test shows the new route answers without credentials, and the code analysis finds the handler missing its authentication guard. Corroborated evidence at or above the threshold: the release is blocked, with both observations in the reason.
DecisionBLOCKA hotfix bumps a dependency
No other analyzer finds anything, but the dependency scan could not resolve the new lockfile, and dependency evidence is required. The release is incomplete, and the record names the missing analyzer and why it did not run.
DecisionINCOMPLETEA known issue with an accepted risk
A medium-severity CORS finding below the blocking threshold was accepted with a reason and a 30-day expiry. Nothing blocks; the finding stays visible with who accepted it and until when, and it reopens for review when the acceptance lapses.
DecisionWARN
What changes for each team
- Engineering
- A decision in the pull request with the reason attached, instead of a long report to triage before merging.
- Security
- A release policy reviewed once as code and enforced in every pipeline; exceptions that carry a reason and expire.
- Engineering leadership and compliance
- A decision history per release to answer customer security reviews with evidence instead of reconstruction.
Bring the release your team is deciding now.
We'll use your repository or staging API to show how the decision is reached — or evaluate it over 14 days in a managed pilot.