Methodology
CFSE
Concepts. Flows. Scenarios. Explorations.
CFSE is a systematic methodology for finding logic-level failures in complex systems. It is not a checklist. It is not a toolchain. It is a way to model systems and test what must never break.
The canonical definition
World-model security means we write down how your system works, define the rules that must never break, and test whether they can be violated.
How CFSE works
Four phases that transform ambiguous security concerns into testable hypotheses and evidence.
Concepts
Define the system in explicit terms. Identify entities, roles, resources, and boundaries. This is your concept map.
Artifact: Concept Map
Entities, roles, resources, boundaries, and their relationships documented in structured form.
Flows
Trace how data and control move through the system. Map the paths between entities and identify where invariants apply.
Artifact: Invariant Library
Testable predicates with scope and rationale. These are the rules that must never break.
Scenarios
Derive hypotheses from invariant violations. Each scenario is a sequence of actions designed to test whether an invariant can be broken.
Artifact: Scenario Database
Attack hypotheses derived from the model, each linked to specific invariants and flows.
Explorations
Test scenarios and record evidence. Document what was tested, what happened, and what it supports or refutes.
Artifact: Exploration Log
Complete record of testing activity: what we tested, what happened, what it proves.
Why CFSE exists
Checklist testing misses logic failures
Standard checklists catch known vulnerability classes but fail to find system-specific logic errors that arise from how components interact.
Security knowledge disappears when people leave
Without explicit artifacts, system understanding lives in individual heads. When those people leave, the knowledge leaves with them.
LLMs are wasted without structure
AI tools can accelerate security work, but only if you give them structured context. CFSE provides that structure.
CFSE makes the thinking explicit. It produces artifacts your team can maintain, extend, and hand off.
How CFSE differs from traditional approaches
| Traditional Approach | CFSE |
|---|---|
| Run tools, review output | Model system, derive tests from model |
| Check against vulnerability catalogs | Define system-specific invariants |
| Findings without reasoning trail | Evidence linked to hypotheses and model |
| Knowledge in people's heads | Knowledge in maintainable artifacts |
| Point-in-time assessment | Living documentation that evolves with the system |
Where to apply CFSE
CFSE is designed for systems where logic failures matter more than known vulnerability classes.
AI Agents
Autonomous systems with tool access, multi-step reasoning, and emergent behaviors that checklists cannot anticipate.
SaaS Platforms
Multi-tenant systems with complex authorization, data isolation requirements, and cross-account interactions.
Fintech Systems
Payment flows, account hierarchies, and transaction logic where invariant violations have direct financial impact.
Robotics and CPS
Cyber-physical systems where software controls physical actuators and safety-critical invariants must hold.
Frequently asked questions
Is this just threat modeling?
Threat modeling identifies what could go wrong. CFSE turns that into testable hypotheses and evidence. Think: threat modeling + scientific method.
Is this too much overhead?
CFSE scales. Model the highest-risk flows first. Do not model everything - model what matters.
Is CFSE a replacement for OWASP/PTES?
No. OWASP/PTES are catalogs and lifecycles. CFSE is a reasoning method for your specific system. Use both.
Start here
1.Walk through a sample casefile to see CFSE in action.
2.Try it on one of your systems.
3.Get help from us if you need it.