OWASP FIASSE

OWASP FIASSE (Framework for Integrating Application Security into Software Engineering, pronounced /feiz/) is a vendor-independent framework for building securable software. "Secure" names a condition that is either achieved or not. "Securable" names software built to remain defensible: structured so that it can be understood, changed, tested, and hardened as the world around it changes.

FIASSE centers on a design language rooted in established software engineering terminology, provided by the Securable Software Engineering Model (SSEM). SSEM attributes define the inherent security characteristics of securable software. The accompanying principles help software engineers reason about architecture and implementation for securable outcomes. 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.

Current release: v1.3.0. Read the framework document, or browse it one section per file.

FIASSE is oriented by four core values. Each expresses a relative preference: both sides have worth, but when choices must be made, FIASSE favors the left.

• Securable Attributes over Security Controls: prefer the engineering qualities that let a system be built and kept defensible over security controls put in after the fact to make up for weaknesses.

• Participation over Assessment: prefer structured engagement between security and development throughout the lifecycle over evaluation performed after the work is done.

• Engineering First Principles over Security Jargon: prefer grounding in established software engineering first principles over security-specific jargon or adversarial heuristics.

• Business Value over Security Activity: prefer security that sustains the organization's value creation over security pursued as an end in itself.

• The Securable Paradigm (2.1): there is no static state of "secure". The engineering question shifts from "is it secure?" to "is it built so that security can be maintained?"

• The Quality-Security Relationship (2.4): security cannot exceed software quality. Investment in engineering quality is a security investment.

• The Transparency Principle (2.6): systems are designed so authorized parties can understand internal state and behavior, through structured logging, instrumentation, and audit trails built into the code.

• The Principle of Least Astonishment (2.7): systems behave in ways that are intuitive and predictable to users, developers, and administrators.

• The Boundary Control Principle (4.3): flexibility within a system's interior is an engineering asset to be preserved; control at every trust boundary is a security requirement to be enforced.

• The Canonical Parsing Principle (4.4.1.1): parse external input into a canonical internal type at the trust boundary, and fail closed when parsing does not succeed.

• The Isolated Integrity Principle (4.4.1.2): integrity-critical facts such as prices, roles, and object state are derived from authoritative server-side sources. They are never accepted directly from a client.

• The Actionable Security Intelligence Principle (6.2): security output becomes valuable only once it is translated into prioritized, engineering-grounded direction that developers can act on within their normal workflow.

Every merge produces an informational Securability Report that combines scan results, changeset-scoped securability signals, and reviewer assessment in SSEM terms (Section 5.2). The report blocks nothing by default. Gating is a policy decision made by the team with its product owner and security partnership, and every gate has an override path that records who accepted what, and why. The resulting audit trail is timestamped, attributable, and reviewable, and can support downstream attestation as a by-product of ordinary work. What the organization manages is security posture over time, not the pass rate of individual merges.

Section 6 names the patterns and gives the corrective for each.

• The Control-as-Requirement Fallacy: treating a catalog control as a specification the programmer should already know to build. A control describes a protection; a requirement specifies behavior.

• The Control-as-Protection Fallacy: reading the documented existence of a control as a property of the software.

• Shoveling Left: supplying impractical information to developers (raw scanner output, exploit-first training) and leaving them to make sense of it.

Current release: v1.3.0 (October 2026). Release notes

Completed

• ☑ Project governance and contribution guidelines

• ☑ Published FIASSE and SSEM specifications with core attributes and integration strategies

• ☑ Securability merge review, Canonical Parsing, and Isolated Integrity (v1.1)

• ☑ Dependency Stewardship consolidation, SSEM attribute code examples, per-section framework files, and skills for AI coding agents (v1.2.0)

• ☑ Lifecycle stage placement and findings as empirical intelligence, Section 5.4 (v1.3.0)

• ☑ AGENTS.md style plugin for performing securable development (GitHub)

Next

• ☐ SSEM Primer and Introduction Guide (in progress; reviewers wanted)

• ☐ AppSec practitioner guide on using and teaching FIASSE (in progress; reviewers wanted)

• ☐ Static securability scoring tooling (ssem-score)

• ☐ Founding Adopter program: pilot teams measuring securability outcomes (recruiting)

• ☐ Co-leader onboarding, target of two to three named leaders (recruiting)

• ☐ Talks and chapter outreach

Future

• ☐ Early evidence report from Founding Adopter pilots

• ☐ Framework revision driven by public feedback

• ☐ Incubator to Lab