Security release decisions, explained

What is Fendix?

Fendix is an application security decision platform. It combines security evidence — its own SAST, DAST, SCA and secrets analysis plus SARIF imported from tools you already run — with required coverage, finding and risk disposition, and your release policy, and returns an explainable release decision: PASS, WARN, BLOCK or INCOMPLETE.

The decision has four inputs: the security evidence, the coverage the policy requires, how each finding is disposed of (confidence, suppressions, accepted risk), and the release policy committed with your code. The result can be kept as a Security Decision Record, so the reasoning behind a release stays reviewable afterwards.

What is an application security decision platform?

Software whose output is a release decision rather than a list of findings. It takes security evidence from many sources, checks it against required coverage and a release policy, and explains whether a release should ship.

Scanners, aggregators and posture tools each answer part of the question: what was found, where, and how severe. A decision platform answers the last part — given all of that, does this release meet the bar? To be trusted, the answer has to be reproducible (the same evidence and policy always give the same result) and explainable (anyone can see which rule and which evidence produced it).

What is the difference between a security gate and a release decision?

A security gate usually fails a pipeline when a finding crosses a severity threshold. A release decision also asks whether the required evidence exists, whether each finding's evidence supports blocking, and which risks were knowingly accepted.

A severity-only gate can pass a release whose dependency scan never ran, and block one over an unconfirmed finding in test code. Fendix's CLI still fails the build through its exit code, but a finding at or above the threshold blocks only when its evidence supports it, and coverage gaps can fail the build on their own. The hosted workspace combines both into one decision: PASS, WARN, BLOCK or INCOMPLETE.

Should a HIGH vulnerability always block a release?

Not on severity alone. Severity describes potential impact; whether a finding should stop a release depends on whether the evidence supports it and on the policy you set.

In Fendix, a finding at or above your threshold blocks when its deterministic confidence band and its evidence support the claim. A high-confidence finding needs a supporting signal, a medium-confidence finding needs an independent one such as a confirmed route or a proven taint path, and a low-confidence finding never blocks on its own. A credential detected in production code still blocks. Every finding held at WARN states why, and switching confidence enforcement off restores a severity-only gate, labelled as an override.

What is required security coverage?

The set of analyzers that must run and report for a release decision to be valid — for example, static analysis and dependency scanning for a code change.

Every Fendix analyzer records whether it ran and, if not, why. A release with no findings but a dependency scan that never ran has not been shown to be clean; it has not been checked. The CLI can fail the build on such gaps with --require-analyzers or --fail-on-coverage-gap, and the hosted decision reports them as INCOMPLETE.

What does INCOMPLETE mean?

INCOMPLETE means the decision cannot be made because required evidence is missing: an analyzer the policy requires failed, was unavailable or never reported, or the run itself did not finish.

It is deliberately neither a pass nor a warning. If a confirmed blocker exists as well, the decision is BLOCK and the coverage gap stays on the record. INCOMPLETE is resolved by supplying the missing evidence, or by a time-limited exception approved by someone other than the requester — and an exception never re-labels the release as complete.

How should accepted security risk be handled in CI/CD?

Record it with a reason, who accepted it and an expiry, keep the finding visible, and bring it back for review when the acceptance lapses.

In the Fendix hosted workspace, accepting a risk requires a reason and a future expiry date and records who accepted it; the finding stays visible and reopens automatically when the acceptance expires. A release exception for a BLOCK, WARN or INCOMPLETE decision needs approval from a different admin, lasts at most 30 days and is invalidated if the evidence changes. Neither rewrites the original assessment. In the CLI, .fendix-ignore rules can carry an until: date so suppressions expire too.

What is a Security Decision Record?

The written result of one release decision: which release it covers, the decision and its reasons, the evidence and required coverage it rests on, and the policy version it was made under.

Hosted workspaces store each decision with its rationale. In Managed CI, currently in limited availability, each decision is stored as an immutable record whose hash can be re-verified, naming the commit, the engine build, the exact policy versions and the per-finding rationale; corrections create new revisions instead of editing history.

How is Fendix different from a vulnerability scanner?

A scanner reports what it found. Fendix runs scanners too — DAST, SAST, SCA and secrets analysis — but treats their output as evidence for a decision, alongside SARIF from the tools you already use.

The categories overlap, so it helps to compare them by the question each one answers.

How does Fendix use SAST, DAST and SCA together?

As evidence for the same decision. Each analyzer contributes findings; agreement between them is one corroborating signal among several, not a requirement.

Static analysis sees code that may never run; dynamic testing sees behaviour but not its cause; dependency analysis sees components but not whether they are used. When a live test and the code analysis observe the same issue, that corroboration can support blocking. A single strong signal — a credential in production code, a payload-confirmed probe — can be enough on its own.

Does AI decide whether a release ships?

No. Fendix's release decision is deterministic: no AI model takes part in detecting findings, scoring confidence or deciding PASS, WARN, BLOCK or INCOMPLETE.

The same evidence and policy always produce the same decision, and every reason traces back to a rule. The hosted workspace includes an optional assistant, Fenn, that explains findings and drafts remediation guidance when someone asks; it cannot change a decision or your code.

Can Fendix run locally?

Yes. The open-source CLI (MIT license) runs on Linux and macOS, locally or in your CI, with no account and no telemetry.

Source code is analysed on your machines and is not uploaded. Dependency checks send package names and versions to public vulnerability and module services. The hosted workspace adds history, the four-state release decision, risk acceptance and team workflows; Enterprise customer-hosted runners keep scanning inside your network.

Offline behaviour depends on the analyzers a scan enables. --offline checks native PyPI and npm dependencies against a local snapshot and skips govulncheck, but in v3.7.0 the Python dependency check that a code scan enables does not receive the flag and may run networked tools unless you add --python-engine=false or --checks auth,injection. Out-of-tree plugins you install can make their own connections; --no-plugins skips them.

Does Fendix send source code to an AI provider?

The CLI makes no AI calls. In the hosted workspace, the optional assistant Fenn contacts the configured third-party language-model provider only when a user asks it something, sending the user's message, the recent conversation and, for a scan, its findings with short evidence excerpts that can quote the matched source line. Known secret patterns are redacted from the scan context first; that redaction is pattern-based. The repository itself is never sent.

Messages users type are sent as written, so do not paste credentials into them. Release decisions never involve the assistant.

Does Fendix offer a public API?

No public HTTP API. You automate Fendix through the CLI, its exit codes, its JSON and SARIF reports, the CI/CD integrations, and integration credentials that publish CI scans to your workspace.

The hosted workspace's backend HTTP interface is a private service contract: it changes with the product and is not documented as a developer API. The stable contracts are the CLI and its flags, .fendix.yaml, process exit codes, JSON report schema 2 and SARIF.

Can Fendix help with Saudi security evidence?

Yes, as evidence: Fendix records application-security testing, vulnerability management, release decisions and accepted risks, which your own security and compliance reviews can draw on.

Each scan keeps its evidence, coverage and decision; accepted risks and release exceptions keep who approved them and until when. The interface and HTML reports are in Arabic and English (JSON, SARIF and PDF stay in English). Whether a record satisfies a particular control is for your own assessment to decide.

Does Fendix guarantee compliance?

No. Fendix holds no third-party certification such as SOC 2 or ISO 27001, and it does not certify that you comply with any standard or regulation, including NCA or SAMA requirements.

A PASS means the evidence you required met the release policy you set. It is not a guarantee of security, a compliance attestation or a human approval.

What does the current Fendix benchmark show?

That the current engine catches every vulnerable case in its own synthetic SAST regression corpus and flags none of the safe ones. It is a check on a controlled dataset, not a measure of production accuracy.

Engine v3.6.3: 38 true positives, 0 false positives, 0 false negatives and 18 true negatives on 56 labelled cases, identical in 4 runs of the release tag's own harness. It says nothing about DAST or dependency scanning, and the same corpus gates the engine's CI, so a perfect score is the expected state. The real-world observations on the accuracy page come from engine v0.11.0 and are labelled historical.