One repeatable security decision process across client projects.
Every client brings a different stack, risk appetite and contract. Fendix applies each client's policy through the same deterministic process, so your teams deliver to a consistent standard and can show the evidence behind every release.
- Client AFintech API: blocks HIGH and above; SAST, SCA and DAST required
- Client BRetail platform: blocks HIGH and above; SAST and SCA required
- Client CInternal tool: blocks CRITICAL; SAST required
Same deterministic decision process
A decision record and evidence package per client
Illustrative policies.
The software-house version of the problem
Delivering secure software for many clients is a consistency problem before it is a tooling problem.
Every client is different
Different stacks, risk appetites and contractual security clauses — served by the same delivery teams.
Review depends on the reviewer
Security sign-off is only as thorough as whoever happened to be on the project that sprint.
Handover without proof
At delivery the client asks what was tested and what was accepted. The answer is spread across emails and tickets.
Disputes after go-live
When an issue surfaces after handover, nobody can show what was checked before release, or who accepted the remaining risk.
Client work must stay separate
One client's findings, history and people must never sit alongside another's.
Every project starts from zero
Each new engagement rebuilds its security gate instead of starting from one you already reviewed.
How Fendix fits a multi-client practice
- A committed policy per client
- Each client repository carries its own .fendix.yaml — threshold, confidence enforcement and test-code handling — and its CI job names the evidence that client requires.
- One process for every project
- Every project runs through the same evidence, coverage, disposition and policy steps. With the engine version pinned, a PASS on one engagement is reached exactly the way it is on every other — against that client's policy.
- Separate workspaces
- Hosted workspaces keep each client's projects, members and history apart, with owner, admin, member and viewer roles.
- Reuse what you reviewed
- Start a new engagement from the policy and CI recipe of your last one, then adjust the threshold and required evidence to the client's terms.
- Accountable exceptions
- Risks a client accepts are recorded with a reason, who accepted them and an expiry, so they are revisited instead of inherited.
The evidence package you hand over
At release or at the end of an engagement, give the client the decision and the evidence behind it.
- The release decision and the reasons behind it
- Which analyzers ran, which did not, and why
- Findings with their dispositions, and accepted risks with their expiry
- Fix verification results for the issues that were remediated
- A self-contained HTML report for people, SARIF and JSON for their tools
- The policy version the decision was made under
Fendix produces technical evidence for your client's review. It does not certify compliance with any standard or regulation.
Where it fits in a delivery engagement
- 1
Kick-off
Agree the release policy and the evidence the client requires, and commit it with the project.
- 2
Every sprint
CI enforces the same decision on each pull request; developers see the reason, not a report.
- 3
Each release
One decision per release, stored with its evidence and the policy version.
- 4
Handover
The evidence package goes to the client with the release.
- 5
After go-live
Fix verification and regression tracking continue under support or maintenance terms.
Test the workflow on one client project.
Bring a repository or staging API and we'll walk through the decision and the evidence package together.