Skip to content
Fendix logo

RELEASE SECURITY DECISIONS, BACKED BY EVIDENCE

Knowwhetherthisreleaseissafetoship—andwhy.

Fendix connects code findings to reachable application behavior, correlates dependency and API evidence, then applies your release policy to return a decision your team can act on.

  • Code + API + Runtime Evidence
  • Policy-Based Decisions
  • Verified Fixes
  • Continuous Audit Trail
Latest release decisionIllustrative example

Release

payments-api · 2.14.0 · commit 9f3c1ab

Recommendation

WARN

Because: 1 reachable HIGH finding · dependency scan incomplete

Read the full record
01The Problem

More security alerts don't create better release decisions.

Engineering teams already receive findings from code scanners, dependency tools, API tests, and penetration tests. The hard part is knowing what is reachable, what violates policy, who owns the fix, and whether the release can move forward.

What you already have

  • Code scanners
  • Dependency tools
  • API tests
  • Penetration tests

What nobody can answer

Which of these is actually reachable?
Which of these violates our policy?
Who owns the fix, and by when?
Can this release move forward?
02How It Works

From signals to a decision you can defend.

Scanning is one source of signals. The decision is the product.

Stage 1

Signals

Static analysis, dependency resolution, live API probing, and imported third-party results.

One input among several — not the product.

Stage 2

Evidence Graph

Findings are linked to the route, handler, data flow, and runtime behavior behind them.

Stage 3

Policy Evaluation

Your committed policy decides what blocks, what warns, and what is informational.

Stage 4

Release Decision

Each finalized finding receives BLOCK, WARN, or INFO under the configured severity threshold; the report summarizes those statuses and scanner coverage.

Stage 5

Ownership

Each remaining risk gets an owner, a status, and a remediation deadline.

Stage 6

Fix Verification

Re-run the exact check that found it and record whether the fix held.

03Security Decision Record

One defensible security decision for every release.

See what changed, what was tested, which policies were triggered, and why the release received its decision.

Illustrative example — fictional data, not a customer record.Decided:

Release

payments-api · 2.14.0 · commit 9f3c1ab

Policy: .fendix.yaml v1 — blocks at CRITICAL

Highest finding status

WARN

Decision reasons

  1. 011 HIGH finding reachable from an authenticated route — warns, does not block, under your policy.
  2. 02Dependency scan did not complete, so part of the release is undecided.
  3. 031 accepted risk expires in 6 days and has no fix in progress.

Tests and scanners

  • Static analysis· completed
  • Secret scanning· completed
  • API probing· completed
  • Dependency scan· failed
  • Infrastructure config· not configured

Coverage gaps

  • Dependency scan failed — lockfile could not be resolved. Re-run before relying on this decision.
  • Infrastructure config scanning is not configured for this repository.

Since previous release

  • 2 new
  • 1 fixed
  • 11 persisting

Accepted risks

Wildcard CORS origin on /public/status

Accepted by Security Lead · expires 2026-08-04

Assigned owners

  • SQL injection in refund handler

    @payments-team · due 2026-07-29

  • Missing rate limit on /api/v2/login

    @platform-security · due 2026-08-07

Fix verification

  • 1 verified resolved
  • 1 still present
  • 1 queued

Human accountability

Awaiting sign-off. The accountable owner can approve this recommendation, override it with a documented reason, accept a risk for a defined period, or request verification after a fix.

Audit trail · 4 recorded events — policy evaluated, decision recorded, risk accepted, owner assigned.

  • BLOCK
  • WARN
  • INFO
04Evidence Graph

Evidence that connects runtime risk to the code that owns it.

A finding on its own is a guess. Fendix links what it observed at runtime to the route, the handler, and the data flow behind it — then to the person accountable for fixing it.

Illustrative example

  1. API endpoint

    POST /api/v2/payments/refund

  2. Runtime behavior

    401 without a token · 200 with a member token

  3. Application route

    payments.urls → refund_view

  4. Code handler

    payments/views.py:88

  5. Data flow

    request.data["account"] → build_query() → cursor.execute()

  6. Risk

    HIGH · SQL injection · CWE-89

  7. Owner

    @payments-team · due 2026-07-29

  8. Verified fix

    Re-checked after the fix — resolved

When evidence is available. Not every finding has a complete chain — Fendix shows the links it can support and marks the rest as unverified.

05Value By Role

One record. Four different jobs.

The same decision, read the way each team needs to read it.

Engineering

Know what to fix, why it matters, and how to verify the fix.

Security

Define policy, review exceptions, and track risk to closure.

CTO and leadership

Understand whether a release can move forward and what risk remains.

Audit and compliance

Access a documented history of testing, decisions, exceptions, and remediation.

06Built for your release model

One decision layer. Two ways teams ship.

Start with the operating model closest to yours.

For SaaS teams

Ship quickly without blindly accepting application risk.

  • Prioritize reachable, confirmed risks
  • Add release decisions to CI/CD
  • Verify critical fixes before shipping
Explore Fendix for SaaS

For software houses

Apply a repeatable security gate across client projects.

  • Use consistent policy across repositories
  • Share defensible evidence with clients
  • Reduce repeated manual release review
Explore Fendix for Software Houses

14-Day Managed Pilot

Prove the decision on a release that matters.

Work directly with the Fendix team on one repository and, where applicable, one staging API. Leave with a reviewed decision record and a clear next-step recommendation.

Apply for a 14-Day Pilot
  1. 01

    Select one repository and, where applicable, one staging API.

  2. 02

    Agree the release policy and success criteria.

  3. 03

    Configure and run Fendix together.

  4. 04

    Review decisions, coverage gaps, and supporting evidence.

  5. 05

    Re-test selected critical fixes where supported.

  6. 06

    Finish with a pilot outcome and next-step recommendation.

06Saudi-Ready, Global By Design

Built for Saudi security requirements. Designed for global engineering teams.

Arabic is a first-class experience, not a translation layer — and the same deployment and evidence controls apply wherever your team runs.

English and Arabic

Both languages are complete product experiences, not partial translations.

Proper RTL

Right-to-left layout, mirrored navigation, and Arabic type shaping throughout.

Self-hosted runners

Run scans on your own infrastructure so target traffic and source never leave it.

Audit events

Append-only records of security-relevant actions, exportable as CSV.

Technical and executive reporting

HTML and SARIF outputs for engineers; decision summaries for leadership.

CI/CD integration

One binary in your pipeline, a pre-commit hook, or a GitHub Actions step.

Data control

No telemetry in the engine, and deployment options that keep scan data in your environment.

07Trust And Proof

Every claim on this page is checkable.

If we can't show you how to verify it, it isn't here.

Signed releases

Every tagged release is signed with cosign keyless (Sigstore) and ships an SBOM. Unsigned tags fail the release pipeline.

See releases

No telemetry

The engine has no phone-home code. Confirm it yourself with tcpdump, or read the source.

Privacy and data handling

Reproducible benchmarks

Accuracy and performance numbers are published with the version, date, run count, and the command to reproduce them.

Accuracy methodology

Visible scanner coverage

Each scanner reports completed, skipped, or failed per run — so a partial scan reads as INCOMPLETE instead of green.

Capabilities

Policy in source control

Enforcement rules live in a committed .fendix.yaml, reviewed like any other change. No hidden server-side thresholds.

CLI reference

Self-hosted execution

A single static binary with no agents to install, runnable entirely inside your own network.

Architecture

Transparent methodology

The full check library, each check's technique, and its known limits are documented in public.

Check library

Readable source

The engine is MIT-licensed. Audit how a decision is reached instead of taking our word for it.

License
09FAQ

Questions engineering leaders ask first.

Direct answers about fit, workflow, and evidence.

Is Fendix another vulnerability scanner?

No. Scanners provide signals. Fendix correlates supported code, dependency, and API evidence, applies release policy, and produces a release decision with its reasons and coverage gaps.

Which languages and frameworks are supported?

The initial focus is Python, Django, FastAPI, supported Node.js analysis, APIs, and backend-heavy products. The walkthrough confirms fit against your repository before a pilot.

Does Fendix replace our current security tools?

Not necessarily. Fendix can collect its own supported signals and import supported third-party results; its role is to turn evidence into a consistent release decision.

What causes Fendix to block a release?

A finalized finding is BLOCK when its severity meets or exceeds the fail_on threshold in your committed policy AND its deterministic confidence band supports the claim: a HIGH band blocks, MEDIUM blocks only with at least one corroborating signal, and LOW warns instead. Correlation is still not required — a single-source finding can block on its own evidence, since a directly observed missing header and a deterministic pattern match in production code each reach the HIGH band alone. What changed in v2.0 is that confidence is now required rather than merely explanatory, so a finding the scan could not corroborate warns instead of failing the build; --enforce-confidence=false restores the previous severity-only rule byte-for-byte. Since v3.2.0 the report names which of these justified the block, so you do not have to infer it: independent corroboration (a second, distinct observation agreed), a reachable taint path (user-controlled input was proved to reach the dangerous call), or a self-evident deterministic match (a pattern whose observation substantially is the claim, such as a provider-issued credential in production code). A build blocked only because --enforce-confidence=false switched the requirement off is marked as a relaxed-policy override, so it can never be mistaken for an evidence-backed block. The same rationale appears in the native JSON and in SARIF. Scanner failures and coverage gaps are reported separately.

Can we use it in CI/CD?

Yes. Fendix supports command-line and GitHub Actions workflows, with policy stored in .fendix.yaml.

What data leaves our environment?

The engine has no telemetry. Self-hosted execution can keep target traffic and source inside your infrastructure; deployment details are confirmed for your chosen workflow.

How does the 14-day pilot work?

We scope one repository and an applicable staging API, agree policy and success criteria, run Fendix with you, review the decision, and verify selected fixes where supported.

Is it suitable for multiple client projects?

Yes. Software houses can apply a repeatable policy and decision workflow across repositories while preserving per-project evidence and accountability.

08Get Started

Make your next release decision with evidence.

Bring a repository or staging API. We'll walk through how Fendix reaches a release decision using real evidence.

Book a Technical Walkthrough
See a Sample Decision