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.
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:
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 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.