Introduction

What is CFSE?#

Concept Flow Scenarios Explorations (CFSE) is a structured methodology for building an explicit world model of a system and then validating security hypotheses against it through evidence-backed experiments.

CFSE decomposes a target into Concepts, Interactions, and Flows, then expresses hypotheses as Scenarios and validates them with Explorations (baseline vs attack) so that conclusions are tied to traceable evidence.

CFSE is designed to work well for human teams and for tool-assisted workflows (including LLM-assisted analysis), without turning “tool output” into authority.

Problem Statement#

Security analysis of complex systems faces several challenges:

1. Complexity - Modern systems have many components with intricate relationships
2. Implicit assumptions - Security rules often exist only in developers' heads
3. Ad-hoc testing - Vulnerability discovery lacks systematic coverage
4. Knowledge loss - Findings don't feed back into reusable patterns
5. Tool collaboration - No common structure for human + tooling workflows (including AI-assisted workflows)

Design Goals#

CFSE addresses these challenges through:

Non-Goals#

CFSE does NOT aim to:

• Replace implementation-level security tools (SAST, DAST)
• Provide automated exploitation
• Guarantee complete vulnerability coverage
• Work without human judgment and expertise

Audience#

This specification is designed for:

Specification Structure#

Optional: Exposure Modeling (EP + PRJ)#

Entry Points (EP-*) are a core CFSE artifact for inventorying tangible system surfaces. Some corpora additionally use optional exposure modeling to make “who can see what, where” more explicit:

• tangible_locations[] and exposes[] on EP-* (viewer-agnostic inventory)
• Projections (PRJ-*) to describe viewer-context-specific slices across one or more entry points

These are optional in CFSE core (unless a conformance profile or extension requires them).

See the canonical artifact specs:

• spec/artifacts/supporting/entry_point/entry_point.md
• spec/artifacts/supporting/prj/prj.md

Potential Inspirations#

CFSE has not been built in a void. It stands on the shoulder of giants - inspired by the work done by some amazing people - in the fields of Formal Logic, Scientific Exploration, Proof Checking, and Software Architecture, Engineering and Design.

• Daniel Jackson — Alloy: small-model thinking; making structure explicit and checkable.
• Leslie Lamport — TLA+: invariants, state transitions, and “spec first” reasoning about behavior.
• Frederick P. Brooks — The Mythical Man-Month, No Silver Bullet: respect for complexity; focus on communication and conceptual integrity rather than tooling optimism.
• Edsger W. Dijkstra / C. A. R. Hoare: correctness as a discipline; clarity of reasoning and contracts.
• David Parnas: modular decomposition and stable interfaces (helpful for world-model boundaries).
• Model checking / formal methods (broadly): properties stated precisely; counterexamples treated as first-class learning artifacts.
• Model-based & property-based testing (broadly): systematic hypothesis generation and oracle-driven validation.
• The scientific method: claims tied to experiments, deltas, and traceable evidence.

Related Traditions (Neighborhood)#

CFSE lives in the intersection of security engineering, formal modeling, and experimental validation. Related traditions include:

Formal specification & model checking#

Formal methods focus on stating a system model plus invariants, then proving properties or finding counterexamples.

CFSE complements this by providing:

• a practical artifact pipeline for building the system model incrementally (Concept → Interaction → Flow),
• explicit security invariants as first-class artifacts, and
• an experimentation discipline (Exploration) for validating properties against real implementations.

CFSE can be used alongside formal methods: use design-time reasoning where it helps, and use CFSE to keep implementation-time hypotheses, experiments, and evidence traceable.

Protocol and adversary-model verification#

Security protocol verification typically introduces an explicit attacker model and attempts to prove secrecy/authentication properties.

CFSE is compatible with this style of work, but is broader in scope (beyond protocols) and emphasizes:

• a shared “world model” vocabulary across stakeholders,
• traceability from hypothesis to evidence to remediation.

Model-based testing & property-based testing#

These approaches generate many test sequences from a behavioral model and check a property (oracle).

CFSE’s Scenario Generators and Explorations are the security-oriented variant of this idea:

• Scenario generators propose hypothesis families systematically,
• Explorations record baseline vs attack runs and their deltas,
• Findings and Patches feed new generator patterns back into the library.

Safety-style constraint analysis (security constraints)#

In safety engineering, analysis often centers on system constraints and how violations can occur.

CFSE adopts the “constraint-first” mindset (invariants) and binds it to:

• concrete entry points,
• structured experiments,
• and evidence/traceability rules.

Taxonomies, checklists, and attack catalogs#

Taxonomies and catalogs (threat categories, attack patterns, weakness types) are useful for coverage and classification.

CFSE uses them as inputs and labeling systems, but is not itself a taxonomy; CFSE is an artifact protocol + workflow for:

• modeling system behavior,
• stating security contracts (invariants),
• generating hypotheses (scenarios),
• validating with experiments (explorations),
• and extracting reusable patterns (generators).

Positioning Summary#

CFSE is not a scanner, checklist, or testing framework. It is a formal methodology for security epistemology—a disciplined approach to knowing whether a system is secure, not guessing or hoping.

Depth, Not Surface#

The Epistemological Stack#

CFSE answers the question: "How do we know this system is secure?"

┌─────────────────────────────────────────────────────────────┐
│  CLAIM: "The system satisfies INV-AUTH-REQUIRED"            │
├─────────────────────────────────────────────────────────────┤
│  EVIDENCE: Trace artifacts T-* with steps, correlation,     │
│            sources, and integrity hashes                    │
├─────────────────────────────────────────────────────────────┤
│  METHOD: Exploration E-* with baseline vs attack paths,     │
│          evaluated against formal invariant                 │
├─────────────────────────────────────────────────────────────┤
│  FOUNDATION: World model (Concepts, Interactions, Flows)    │
│              defining what the system *is*                  │
└─────────────────────────────────────────────────────────────┘

This is the difference between "we tested it" and "here is the formal structure of our knowledge."

Integration with Existing Practices#

If you already use threat modeling, checklists, or red teaming, CFSE fits as the "deep structure" layer:

• Threat modeling helps enumerate concerns; CFSE turns concerns into structured hypotheses grounded in a world model.
• Security testing finds issues; CFSE turns results into traceable findings and reusable generators.
• Formal methods can prove properties; CFSE provides an on-ramp to formalization via explicit artifacts and invariants, and a bridge back to real-world validation via explorations.
• Tool-assisted analysis (including AI) benefits from structure; CFSE provides an ontology and artifact schemas that make reasoning and automation more systematic.