A Framework for Integrating Application Security into Software Engineering (FIASSE)

Note: This repository is an ongoing work. Contributions are welcome!

Overview

TL;DR: please read the DOC. Explore FIASSE website. Visit GitHub Discussions to contribute.

This repository contains resources and materials for the OWASP Framework for Integrating Application Security into Software Engineering (FIASSE). FIASSE (pronounced /feiz/ like 'phase') is a vendor-independent framework that promotes a developer-centric, principled approach to building securable software. It recognizes that security is a dynamic, ongoing process like development. It introduces the Securable Software Engineering Model (SSEM) as a common design language that uses established software engineering terms to integrate security into software architecture, design, and engineering by embedding security in the principles that shape the code itself. The framework enables development teams to resiliently add computing value while reducing the probability of material impact from cyber events throughout the code's lifespan.

FIASSE is a creational framework. It addresses how security is implemented in software, connecting engineering decisions directly to securable outcomes. It is not an assurance framework, a maturity model, or a replacement for control catalogs or vulnerability metrics. It complements those approaches and eases downstream pressure on assurance and compliance.

Purpose

To provide practical guidelines that empower developers to create securable software without requiring deep security expertise, and to guide security professionals in effectively integrating their security experience into software engineering. FIASSE achieves this through a Software Engineering lens, reducing cognitive load and fostering collaboration between development and security teams.

How is it Different?

While assurance focused projects like the OWASP Top 10 highlight what to avoid (a block list), OWASP FIASSE provides a set of positive attributes and practices to follow (an allow list). This approach leverages existing software engineering skills to build securable software, rather than requiring developers to learn exploit techniques or adopt a vulnerability-focused mindset. The emphasis is on enabling practical, secure coding through familiar engineering principles.

By clearly defining security's practical role within the development process, this framework ensures that business value is captured effectively. Setting explicit security expectations before code is written reduces the likelihood that security flaws will be discovered and need remediation later. Effective adoption should improve existing assurance metrics, reduce findings churn, produce more durable fixes, and shorten remediation time.

Core Values

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.

Key Principles

• The Securable Paradigm: There is no static state of "secure." A system declared secure today may be vulnerable tomorrow. FIASSE redirects the engineering goal from "is it secure?" to "is it built so that security can be maintained?" through adaptive resilience, evolutionary security, and continuous improvement.
• Resiliently Add Computing Value: The primary directive of software engineering in a business context. Software must meet functional requirements while sustaining the securable qualities that let it withstand the change, stress, and attack that follow each change.
• Security Mission: Reducing Material Impact: The mission of security is to reduce the probability of material impact of a cyber event. Complete elimination of breaches is not a practical business goal, so security strategies must align with business objectives and risk appetite.
• The Quality-Security Relationship: Security cannot exceed software quality. The qualities that make software easy to understand, change, test, and observe are the same qualities that make it possible to secure. Investment in engineering quality is a security investment.
• Developer-Centric Security: Empowering software engineers to build securable systems using familiar software engineering principles, rather than requiring them to adopt a penetration tester's mindset.
• SSEM as a Common Design Language: Utilizing established software engineering terms (e.g., Analyzability, Modifiability, Testability) to define and discuss security attributes. This makes security accessible to developers and gives security professionals a shared basis for assessment.
• Aligning Security with Development and Business Goals: Security and development are complementary, not adversarial. AppSec participates early in the SDLC, particularly during requirements gathering and feature planning, so expectations are explicit before code is written.
• The Transparency Principle: Systems are designed so authorized parties can understand internal state and behavior. Structured logging, instrumentation, and audit trails are built into the code rather than supplied by external tooling alone.
• The Principle of Least Astonishment: Systems behave in ways that are intuitive and predictable to users, developers, and administrators. Predictability aids analysis, reduces cognitive burden, and makes trust boundaries clear.
• Requirements as a First-Class Citizen in AppSec: Security Features, Threat Scenarios, and Security Acceptance Criteria are delivered through the requirements process. Vulnerabilities commonly trace to an expectation that was never specified, so that gap belongs in the requirements process.

Engineering Principles

Section 4 of the framework gives developers principles that apply directly at the code level:

• The Boundary Control Principle: 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.
• Canonical Input Handling: Canonicalize, validate, and sanitize input at the point of entry. The Canonical Parsing Principle parses external input into a canonical internal type at the boundary and fails closed when parsing does not succeed.
• The Isolated Integrity Principle: Integrity-critical values such as prices, roles, and object state are derived from authoritative server-side sources. They are never accepted directly from a client.
• Resilient Coding: Defensive coding practices enforce predictable execution. These include strong typing, input validation at trust boundaries, output encoding, comprehensive error handling, safe resource management, graceful and secure failure, and least privilege at the code level.
• Dependency Stewardship: Apply SSEM attributes when selecting, integrating, monitoring, and maintaining dependencies for the life of the relationship.