Application security decision platform

Know whether this release is safe to ship, and why.

Fendix combines DAST, SAST, and SCA, correlates supported evidence from APIs, code, and dependencies, and applies your release policy with clear reasons and coverage gaps.

Book a technical walkthrough View a Security Decision Record

Works withGitHub ActionsGitLab CICircleCIJira

Latest engine release: v3.4.1: engine images now build with and ship Go 1.27, raising govulncheck's module ceiling from 1.25

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?

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.

1.000Synthetic F1 across seven detection categories

147Findings in a 17-second real-world scan

12Vulnerability classes covered on PyGoat

One defensible security decision for every release.

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

Security decision record

Illustrative example — fictional data, not a customer record.

Release: payments-api
Version: 2.14.0
Commit: 9f3c1ab
Decided: 2026-07-24 09:12 UTC
Policy: .fendix.yaml v1, blocks at CRITICAL

Release decision

INCOMPLETE

Highest finding status

WARN

Decision reasons

HIGH findings warn under this illustrative policy, which blocks at CRITICAL. Severity alone is not the release recommendation.
Dependency scan did not complete, so part of the release is undecided.
1 accepted risk expires in 11 days and has no fix in progress.

Tests and scanners

Static analysiscompleted
Secret scanningcompleted
API probingcompleted
Dependency scanfailed
Infrastructure confignot configured

Coverage gaps

Dependency scan failed — lockfile could not be resolved. Re-run before relying on this decision. Affects coverage.
Infrastructure config scanning is not configured for this repository. Not required by this policy.

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

BLOCKPolicy violation at or above the blocking threshold.
WARNActionable risk below the blocking threshold.
INFOInformational finding below the actionable range.

The record, inside the product.

Every scan ends in the same place: a decision with its reasons, its coverage and its owners, in a workspace your whole team can read.

The Fendix dashboard: a summary strip of scans and findings, charts of findings per day and by category, and recent scans

Live screenshots of the demo workspace. No sign-up needed to open it.

Open the live demo

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

A finding is evidence to assess. Fendix links supported observations to application routes and code, and makes the limits of each conclusion explicit.

Illustrative example

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

API endpoint
POST /api/v2/payments/refund
Runtime behavior
401 without a token, 200 with a member token
Application route
payments.urls → refund_view
Code handler
payments/views.py:88
Data flow
request.data["account"] → build_query() → cursor.execute()
Risk
HIGH, SQL injection, CWE-89
Owner
@payments-team, due 2026-07-29
Verified fix
Re-checked after the fix: resolved

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.

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

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
Select one repository and, where applicable, one staging API.
2
Agree the release policy and success criteria.
3
Configure and run Fendix together.
4
Review decisions, coverage gaps, and supporting evidence.
5
Re-test selected critical fixes where supported.
6
Finish with a pilot outcome and next-step recommendation.

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 inside your network. Hosted runners upload reports; advisory queries and configured integrations may transmit metadata.

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.

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

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.

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 View a Security Decision Record