Skip to content
Fendix logo
v1.1.0 — real-world precision: false positives cut sharply on real code (~90 → 5 on a live Django app), full scans from ~50 min to 9 s, and scanner coverage now visible in-app

APPLICATION SECURITY DECISION PLATFORM

Everyreleaseneedsasecuritydecision—notanotherscan.

Fendix connects code, APIs, runtime behavior, ownership, and fix verification to give every release an evidence-backed security decision—and enforce the policies your team approves.

See a release decision
Book a technical walkthrough
  • 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

One recommendation per release: PASS, WARN, BLOCK, or INCOMPLETE — with its reasons.

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

Recommendation

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.

  • PASS
  • WARN
  • BLOCK
  • INCOMPLETE
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.

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
08Get Started

Give your next release a security decision.

See how Fendix turns code and runtime evidence into a decision your engineering and security teams can understand, review, and act on.

See a release decision
Book a technical walkthrough