OWASP FIASSE

The Securable Software Framework: an attribute model with principles and processes to guide agentic software development (or manual software engineering) to secure outcomes.

About OWASP FIASSE

“The Securable Framework”

OWASP FIASSE (Framework for Integrating Application Security into Software Engineering) centers on a design language rooted in established software engineering terminology, provided by the Securable Software Engineering Model (SSEM). This model defines the inherent security characteristics of securable software. The accompanying principles help software engineers reason about architecture and implementation for securable outcomes. Building on the model and principles, FIASSE also includes feedback flow guidance, so security findings have the highest impact. This enables development teams to resiliently add computing value while reducing the probability of material impact from cyber events throughout the code's lifespan.

Fundamentals

While this framework attempts to give structure to the relationship between security and software engineering, the primary audience is Software Engineers. Therefore, the fundamentals are framed from that perspective to set expectations for development. The core FIASSE tenets are:

Scope

FIASSE is not an assurance framework, maturity model, or replacement for control catalogs or vulnerability metrics. Its purpose is to address how security is implemented in software, connecting engineering decisions directly to securable outcomes and easing downstream pressure on assurance and compliance.

While this framework attempts to give structure to the relationship between security and software engineering, the primary audience is Software Engineers. Therefore, the fundamentals are framed from that perspective to set expectations for development.

The Core FIASSE Tenets

  • The Securable Principle: There is no static state of "secure". Software engineers need to understand what is needed to create securable code without the years of extra training and experience it would take to understand the security practice.

  • Derived Integrity Principle: The Derived Integrity Principle states that an application must not implicitly trust or adopt unmanaged external context, such as client-supplied data or other untrusted inputs, when making critical decisions. Instead, it should derive important facts (like identity, permissions, pricing, and state) from authoritative, controlled sources to preserve integrity.

  • Canonical Input Handling: The practice of converting all incoming data into a validated and well-defined state before it is used anywhere in the system. This supports the Securable and Derived Integrity principles by making sure that every decision is based on normalized, predictable input instead of raw, inconsistent, or attacker-shaped data.

  • The Transparency Principle: How the system works should be perceptible so engineers and stakeholders can see what it is doing, why it is doing it, and how. In software engineering terms, it pushes teams to design systems whose behavior is visible.

Project Leaders

Alton Crossley

LinkedIn

Project Information

Incubator Project
Classification
Standards
Latest Version
v1.0.6
OWASP Logo
OWASP is a nonprofit foundation improving software security through open-source projects, global communities, and education. All resources are free and open to everyone.
OWASP, the OWASP logo, and Global AppSec are registered trademarks and AppSec Days, AppSec California, AppSec Cali, SnowFROC, OWASP Boston Application Security Conference, and LASCON are trademarks of the OWASP Foundation, Inc.
© 2026, OWASP Foundation Inc. All rights reserved.