Skip to content
Fendix logo

The release questions Fendix answers

Scanners report what they found. A release needs a different answer: given the evidence you require, the evidence you actually have, the risks you accepted and the policy you agreed on, should it ship? These are the questions teams bring to Fendix.

Request a technical walkthroughView a Security Decision Record

Six questions, one decision process

Each use case starts from the question a release owner actually asks, then shows how Fendix answers it and where the mechanics are documented.

1

Can this release ship?

One release decision — PASS, WARN, BLOCK or INCOMPLETE — with the reasons behind it, instead of a list of findings to interpret.

How Fendix answers it

Fendix evaluates the evidence for a release against your release policy. By default, a finding blocks only when its severity reaches your threshold and its evidence supports the claim, so severity alone does not block. The hosted decision is ranked so a confirmed blocker always wins and missing required evidence is never reported as a pass.

What you get

  • One decision per release, ranked BLOCK, INCOMPLETE, WARN, PASS
  • The reason behind every blocking or held-back finding
  • Coverage gaps named instead of hidden behind a green build
How the decision model works
2

Did every required check actually run?

No findings is not the same as a clean release. Fendix checks that the evidence you require exists before a release can pass.

How Fendix answers it

Every analyzer records whether it ran and, if not, why. In the hosted workspace, a required analyzer that failed, was unavailable or never reported makes the decision INCOMPLETE rather than PASS. In the CLI, --require-analyzers and --fail-on-coverage-gap turn the same gaps into a failing exit code.

What you get

  • Per-analyzer status, with the reason it did not run
  • INCOMPLETE when required evidence is missing, never a silent PASS
  • Coverage gaps carried into the report and the decision
What required coverage means
3

Which risks were accepted, by whom, and do they still apply?

Accepted risk stays on the record with a reason and an expiry. It does not quietly disappear.

How Fendix answers it

Accepting a risk in the hosted workspace requires a reason and a future expiry; the finding stays visible and the acceptance lapses for re-review on its date. A release exception for a BLOCK, WARN or INCOMPLETE decision must be approved by a different admin, expires within 30 days, and is invalidated when the evidence changes. The original assessment is never overwritten.

What you get

  • A reason, an author and an expiry on every acceptance
  • Release exceptions approved by someone other than the requester
  • Expired acceptances reopen automatically
Release approvals and exceptions
4

Was the issue actually fixed, and does it stay fixed?

A fix counts only when Fendix re-tests it, or when a later scan with complete coverage no longer finds it.

How Fendix answers it

fendix verify re-tests every location of a finding and reports it resolved only when all of them are. In the hosted workspace a finding closes as fixed only after a resolved verification or a later full-coverage scan, and it is flagged as regressed if it comes back.

What you get

  • Every occurrence re-tested, not just the first
  • No “fixed” from a partial or differential scan
  • Regressions flagged when a fixed finding returns
Remediation and fix verification
5

Can every pipeline enforce the same release policy?

Commit the policy next to the code and run the same deterministic evaluation in every pipeline.

How Fendix answers it

The release gate lives in .fendix.yaml in the repository: threshold, confidence enforcement, test-code handling and suppressions. The same engine runs in GitHub Actions, GitLab CI, CircleCI or Jenkins, fails the job when a finding blocks, and publishes SARIF to your code-scanning view. Hosted decisions record the policy version they were made under.

What you get

  • Policy as code, reviewed like any other change
  • The same evidence and policy always give the same result
  • SARIF 2.1.0 and JSON for the tools downstream
How to enforce it in your pipelines
6

Can we show a client what was checked and why the release was approved?

Hand over the decision, its evidence and its coverage, not a screenshot of a scanner dashboard.

How Fendix answers it

Each scan exports as a self-contained HTML report, SARIF or JSON that carries the decision basis for blocking findings, the coverage achieved and the policy version applied. Separate workspaces keep each client's projects, members and history apart.

What you get

  • A self-contained HTML report a client can open without an account
  • The decision basis carried into SARIF and JSON
  • Separate workspaces per client
Fendix for software houses

Scanning is how the evidence arrives

Fendix runs its own analyzers and accepts results from the tools you already use. Every source becomes evidence for the same decision; none of them is the decision.

  • DAST: running APIs

    Configuration leaks, security headers, CORS, exposure, rate limits and cookie flags; credentialed authorization and IDOR checks; opt-in active probes for injection, XSS, SSRF, open redirect, host-header, GraphQL and method tampering.

  • SAST: source code

    Bundled Semgrep rules, Python taint analysis that traces request input to dangerous sinks, and pattern rules for Go, JavaScript and TypeScript, Java, Dockerfiles and Kubernetes manifests.

  • SCA: dependencies

    Known vulnerabilities in PyPI and npm packages (via OSV) and Go modules (via govulncheck), with evidence on whether the vulnerable package is actually imported.

  • Secrets

    Hard-coded credentials in source and configuration, redacted at capture so the value itself never enters a report.

  • Imported SARIF

    Results from CodeQL, Semgrep, Trivy or any SARIF 2.1.0 producer, brought in as evidence and kept labelled as imported.

  • Local and pre-commit

    The open-source CLI runs locally with no account and no telemetry; fendix hook install adds a staged, diff-aware scan before each commit.

Browse every check in the check libraryRead the capabilities overview

From evidence to a decision you can explain

The same six steps sit behind every use case above.

  1. 1

    Security evidence

    Findings from Fendix analyzers and imported SARIF.

  2. 2

    Required coverage

    Did every analyzer the policy requires run and report?

  3. 3

    Finding and risk disposition

    Confidence, suppressions, accepted risk and exceptions.

  4. 4

    Release policy

    Threshold, confidence enforcement and required analyzers.

  5. 5

    Release decision

    PASS, WARN, BLOCK or INCOMPLETE, with the reasons.

  6. 6

    Decision record

    What was decided, under which policy, on which evidence.

Hosted workspaces store every decision with its rationale. Immutable, hash-verifiable Security Decision Records are part of Managed CI, currently in limited availability.

See the decision on one of your releases

In a technical walkthrough we run Fendix against a target you nominate and go through the resulting decision with you. For a longer evaluation, the managed pilot covers one repository over 14 days.

Request a technical walkthroughExplore the 14-day managed pilotSee hosted plans