OWASP OWASP OWASP

FIASSE FIASSE™ FIASSE™

Relentlessly Practical

Relentlessly Securable

A framework for Securable Software Engineering, providing practical guidance for Software Engineers to build securable applications and for Application Security to impact securable outcomes. Read the RFC!

(FIASSE is pronounced /feiz/ like 'the phases of the moon')

*Note: FIASSE is not an assurance framework. This is a new project and some concepts may seem odd. Because of this, your LLM may not get it either. Please share your honest thoughts and feedback because we want you both to understand. :)

Contributing to FIASSE

Join us in building a more secure software engineering future

Feedback

Read the docs: What do you like? What do you not like? What is missing? What is confusing? What do you think is ridiculous?

Please use the GitHub discussions to give feedback.

How to Contribute

We welcome contributions from everyone! Whether you're a developer, security professional, or just passionate about software security, there are many ways to get involved.

Check out our Contributing Guide to get started.

Contributing Guidelines

Thank you for your interest in contributing to an OWASP project. We welcome all contributions and appreciate your efforts to improve our projects.

Getting Started

To get started with contributing to any OWASP project, please follow these steps:

Join the OWASP Slack workspace to connect with the OWASP community and get help with any questions you may have.
Review the OWASP Projects page to browse the list of OWASP projects and find a project that aligns with your interests and skills.
Visit the project’s individual page and repository to familiarize yourself with the project goals and objectives.
Fork the repository and clone it to your local machine.
Make your changes and review them locally.
Submit a pull request with your changes.

Pull Request Guidelines

Before submitting a pull request, please make sure:

Your changes are consistent with the project’s goals and objectives: this isn’t an assurance framework.
Your changes are well-documented and follow the project’s standards and styles.
Your pull request includes a clear and concise description of the changes you have made.

Code of Conduct

We ask that all contributors to OWASP projects abide by our Code of Conduct. This code outlines our expectations for behavior within the project community and helps us maintain a welcoming and inclusive environment for all contributors.

Thank you for your interest in contributing to an OWASP project. We appreciate your efforts to help us improve and grow our projects.

About OWASP FIASSE

Framework for Integrating Application Security into Software Engineering

What is FIASSE?

FIASSE (/feiz/) is an OWASP project that provides a software-engineering-centric approach to building securable software.

It combines practical software engineering methodologies with modern application security practices to create a framework that is effective and scalable.

Our Mission

To provide developers and security professionals with a practical, actionable framework to reduce friction and increase developer velocity in the context of application security.

We believe security should be relentlessly practical for software engineers. We also believe security teams have more to offer than secret test suites.

Key Concepts

The Securable Principle

There is no static state of "secure". Therefore unmaintainable code is at the apex of security risk.

Business Alignment

Security aligns with the business of making software by participation in existing development channels. This means abandoning the "shovel-left" anti-pattern in favor of clearer communication and earlier collaboration.

Participation over Assessment

Structured participation by Security in the development process yields better results than security assessment alone, which tends to be late and expensive.

Key Features

Design Language Security Extensions Prompt Engineering Guidance Keystone Practices Principle Driven Security ...

FIASSE Project

A methodology for integrating security into software engineering practices

Project Overview

FIASSE is designed to align people, process and technology with the business of making software. It is meant to address the issues of perceived conflicting goals and the "shovel-left" anti-pattern. It was developed under the premise that software engineers can create securable code without also learning to be hackers.

Project Goals

Primary Objectives

• Practical software engineering guidance for securable software
• Application Security Guidance for efficiency and scale
• Guided adoption of security practices

Target Audience

• Software engineers seeking practical security guidance
• Application security professionals wanting to align with development
• Teams interested in establishing a solid engineering basis for a security
• Educators aiming to teach secure software engineering practices
• Development orgs who have received an OWASP SAMM score of 0

Take your project from 0 to 1, including security with minimal impact to velocity.

Framework Components

Core Elements

• SSEM: the articles of security from a software engineering perspective
• Securable software engineering activities
• Guidance for effective vulnerability remediation

Supporting Artifacts

• SSEM influenced documents including checklists and templates
• Mapping and references pertaining to SSEM and related projects and frameworks
• Guidance for effective vulnerability remediation
• Primer/Introduction to FIASSE and SSEM with guide for teaching it
• A collection of use cases and patterns as ready-made starting points

Pillars of FIASSE:

FIASSE can be classified into three pillars or activity classes:

Expectations

Define security expectations clearly through requirements methods.

Implementation

Securable code driven by software engineering principles.

Assurance

Testing and feedback is applied strategically to reduce reoccurrence.

Note that these pillars are not meant to replace or map directly to the domains of OWASP SAMM or any other framework. They are simply meant to provide a practical structure for organizing the activities of FIASSE.

Expectation FIASSE

Set expectations in a way that organically leverages software engineering practices for optimum security outcomes

Architecture and Design

1

Reference Architecture

Leverage known security architectures to inform needed architecture outcomes.

2

Threat Modeling

Identify potential threats and vulnerabilities using a framework like STRIDE, PASTA, DREAD.

Requirements

3

Threat Scenarios

Identify potential threats and frame them as use cases.

4

Acceptance Criteria

Define what it looks like when the product is protected from threats.

5

Security Requirements

Matching the style of the development team, include explicit security requirements.

Implementation

Encourage Software Engineering as a discipline to improve software security posture.

Code

1

Securable Software Engineering Model

Continually target Maintainability, Trustworthiness, and Reliability

2

"What can go wrong?"

Actively assess what can go wrong with every change to complement threat modeling

3

Strategic Flexibility Control

Be explicit about where trust boundaries are and how they are intended to be handled so flexibility can thrive.

3

Resilient Coding Tactics

Use Canonical input handling and Derived Integrity Principle to drive trust and reliability. Then prove it with transparency tactics like negative unit tests and load tests.

Process

4

Intentional Dependency Management

Conscious choice to fully adopt or fork individual dependencies. Make a conscious decision to reject dependencies that were not built for your level of sensitive data.

5

Merge Request Reviews

Human-in-the-loop and a mentoring program in the focused context of code changes.

Security Assurance

Assurance activities are still important when using the FIASSE approach. However they are secondary to participation in Requirements and Design phases. Additionally, there is a significant difference in how testing results are used.

Vulnerability Analysis

Vulnerability trend and class analysis with root cause investigation and vulnerability verification to avoid "shoveling left". Includes standard AppSec analysis types for comprehensive coverage.

Root Cause Exploitability Risk Analysis Collaborative Remediation Vulnerability Correlation Attack Surface Analysis

Training

Role specific, practical training for developers

Product Architecture & Design Software Engineering Quality Assurance

Program Assessment

Point in time assessment of Application Security process and program effectiveness

OWASP SAMM OWASP ASVS BSIMM NIST SSDF ISO/IEC 27034 CIS Controls PCI Secure SLC

Automated Application Security Testing

Fast and affordable testing to identify basic security vulnerabilities

SAST DAST SCA IAST RASP IaC Scanning Secrets Scanning API Security Testing Configuration Analysis

Manual Pentesting

Hands-on process to attempt to uncover complex issues that tools often miss.

Expert Analysis Business Logic Testing Exploit Validation

Security Assessment Tools

Static Analysis

• SonarQube Security
• Checkmarx
• Veracode
• ESLint Security

DevSecOps Integration

CI/CD Security

• GitHub Actions Security
• Jenkins Security Plugin
• GitLab Security Dashboard
• Azure DevOps Security

Securable Software Engineering Model (SSEM™)

A model that identifies fundamental and universal attributes that are the building blocks of securable software.

SSEM v1.0.1

What is SSEM?

Pronounced /si:m/ : A body of software engineering terms to describe the fundamental attributes of securable software. Together, these terms form a comprehensive model for understanding software security and a design language for communicating security concerns.

The SSEM is centered around being a design language and defining the core attributes that make software "securable" (see FIASSE RFC Section 2.1). These attributes allow SSEM to abstract security away from specialized jargon or exploit-centric views. For software engineers this enables them to confidently integrate security considerations as a natural part of their development work. It also helps security professionals identify how existing code meets security expectations and areas for improvement.

Core FIASSE Principles

The Securable Principle:
There is no static state of "secure".
The Derived Integrity Principle:
An application does not implicitly adopt unmanaged context, for example from the client.
Securable Attributes over Security Controls:
Instead of focusing only on security controls or checklists, emphasize building software with inherent qualities - so it's easier to analyze, modify, test, and trust.
Participation over Assessment:
We believe the Application Security team would be more effective if they actively participated in the development process rather than solely assessing, reviewing and reporting after the fact.

Key Benefits of applying SSEM

Maintainability:
Code is easier to understand and change, reducing the risk of introducing new flaws over time.
Trustworthiness:
Systems are designed so that critical facts (like prices, permissions, or states) are derived from trusted sources, not dictated by untrusted context or input.
Reliability:
Applications keep running predictably under unfavorable circumstances and load.
Intention:
With defined security objectives, development teams act with purpose instead of guessing about how to pass the next security assessment.
Transparency:
Developers, operators, and responders can diagnose issues quickly and confidently, with full context and zero data leakage.

Optimized for Business

SSEM allows Application Security insight into development without derailing important development processes or adding toil.

Developer-Centric

Designed to align Application Security with software development principles and strategies.

Scalable Framework

Adaptable to projects of any size, from small applications to high-scale systems.

A Software Engineering Design Language

A design language is a set of shared terms, concepts, and patterns that helps a team communicate ideas, expectations, and standards consistently. In software engineering, a design language provides a common vocabulary for describing system qualities, architecture, and implementation details. This makes it easier to collaborate.

In software engineering, a design language ensures clarity and consistency. It simplifies decision making by providing well-defined principles. It embeds security concepts into familiar engineering terms. This empowers developers developers to build securable systems without needing deep security expertise.

By adopting SSEM as your software engineering design language, you adopt a pre-built shorthand for all roles (product, development, security, management...) that carries with it the essence of security culture.

SSEM Model

SSEM identifies all the fundamental attributes that are the building blocks of securable software in an evolving landscape (FIASSE RFC Section 2.1). These attributes are not merely abstract concepts but represent tangible characteristics that directly contribute to its overall security and resilience.

Maintainability

Maintainability is the "degree of effectiveness and efficiency with which a product or system can be modified by the intended maintainers" (ISO/IEC 25010:2011).

Analyzability

The ability to quickly assess the impact of changes, diagnose issues, and identify what needs to be modified.

Modifiability

The ability to safely and quickly modify a system without causing defects or reducing quality or securability.

Testability

The ability to verify that a system meets its requirements and is free of defects.

Trustworthiness

Trustworthiness is the "degree to which a system can be trusted to behave in a predictable manner" (ISO/IEC 25010:2011).

Confidentiality

The ability to keep sensitive information secure and private.

Accountability

The ability to uniquely trace actions to the responsible entity.

Authenticity

The ability to confirm the identity of a user or system.

Reliability

Reliability is the "degree to which a system, product or component performs specified functions under specified conditions for a specified period of time" (ISO/IEC 25010:2011)

Availability

The ability of a system to remain accessible and operational when needed.

Integrity

The ability to ensure that a system's data is accurate and uncorrupted.

Resilience

The ability to recover from failures and continue operating.

The model implies the existence of strategies for producing these qualities, which is where the rest of FIASSE comes in. While implementation patterns vary with platforms and tools, the model's purpose is to support the definition of the principles that drive these strategies. This empowers teams to create, adapt, and evolve their methodologies as their understanding of the model deepens.

Measuring SSEM Attributes

Measuring the attributes defined by SSEM is essential to quantify and evaluate the securable qualities of software. This section outlines approaches for measuring each of the core attributes of SSEM, providing a framework for assessing software security and resilience. Metrics can have different meanings in different contexts, so the following is not an exhaustive list but rather a starting point for teams to adapt and expand based on their specific needs and environments.

1

Maintainability

Elemental Security

Analyzability

Quantitative

• Volume (Lines of Code - LoC): Tracked per module/system. Lower LoC for a given functionality can indicate better analyzability.
• Duplication Percentage: Measured by static analysis tools (e.g., SonarQube, PMD). Lower is better.
• Unit Size (e.g., mLoC/cLoC): Average lines of code per method or class. Excessively large units are harder to analyze.
• Unit Complexity (e.g., Cyclomatic Complexity): Measured by static analysis tools. Lower complexity per unit is generally better.
• Comment Density/Quality: Ratio of comment lines to code lines, or qualitative review of comment usefulness.

Qualitative/Process-based

• Time to Understand (TTU): Average time it takes a developer unfamiliar with a code section to understand its purpose and flow for a specific task (e.g., bug fix).
• Developer Surveys: Periodically ask developers to rate the analyzability of modules they work with.

Modifiability

Quantitative

• Module Coupling (Afferent/Efferent): Number of incoming (afferent) and outgoing (efferent) dependencies for modules. Lower afferent coupling for a module often means it's easier to change without impacting many other parts.
• Change Impact Size: Number of files/modules typically affected by a common type of change. Smaller is better.
• Regression Rate: Percentage of changes that introduce new defects. Lower is better.

Qualitative/Process-based

• Ease of Change Assessment: During code reviews, assess how easy it would be to make a hypothetical related change.
• Time to Implement Change: Average time to implement standard types of modifications or feature enhancements.

Testability

Quantitative

• Code Coverage: Percentage of code covered by automated tests (unit, integration). Higher is generally better.
• Unit Test Density: Number of unit tests per KLoC or per class/module.
• Mocking/Stubbing Complexity: Difficulty or amount of setup required to isolate units for testing.

Qualitative/Process-based

• Ease of Writing Tests: Developer feedback on how easy it is to write meaningful tests for new or existing code.
• Test Execution Time: While not a direct measure of testability, excessively long test suite runs can disincentivize testing.

2

Trustworthiness

Systemic Security

Confidentiality

Quantitative

• Number of Identified Data Leaks: From penetration tests, code reviews, or incidents.
• Access Control Violations: Number of logged unauthorized access attempts (prevented or successful).

Qualitative/Process-based

• Data Classification Adherence: Review of how well data is classified and if protections align with classification.
• Principle of Least Privilege Review: Assessment of whether components and users only have necessary permissions.
• Effectiveness of Encryption: Review of encryption algorithms used, key management practices.

Accountability

Quantitative

• Audit Log Coverage: Percentage of critical system actions that are logged with sufficient detail.
• Traceability Success Rate: Percentage of audited actions that can be uniquely traced to an entity.

Qualitative/Process-based

• Audit Log Review Findings: Results from periodic reviews of audit logs for completeness and usefulness.
• Non-repudiation Strength: Assessment of the strength of evidence linking actions to entities (e.g., use of digital signatures).

Authenticity

Quantitative

• Authentication Failures: Number of failed login attempts (can indicate brute-forcing or issues).
• Use of Strong Authentication: Percentage of authentication points using multi-factor authentication or strong credential types.

Qualitative/Process-based

• Verification of Identities: Review of processes for verifying user and system identities.
• Integrity of Authentication Mechanisms: Assessment of the security of authentication protocols and implementations.

3

Reliability

Universal Security

Availability

Quantitative

• Uptime Percentage: (e.g., 99.99%).
• Mean Time Between Failures (MTBF).
• Mean Time To Recovery (MTTR).

Qualitative/Process-based

• Redundancy Review: Assessment of system redundancy for critical components.
• Disaster Recovery Test Results.

Integrity

Quantitative

• Number of Data Corruption Incidents.
• Checksum/Hash Validation Success Rate: For data at rest and in transit.

Qualitative/Process-based

• Input Validation Effectiveness: Review of input validation mechanisms at trust boundaries.
• System File Integrity Monitoring Alerts.

Resilience

Quantitative

• Recovery Time Objective (RTO) Adherence: How often RTOs are met after an incident.
• Performance Under Stress: System performance metrics during load testing or simulated attacks (e.g., DDoS).

Qualitative/Process-based

• Defensive Coding Practices Review: Assessment of code for practices like proper input validation, output encoding, and robust error handling.
• Incident Response Plan Effectiveness: Review of how well the system and team recover from security incidents or operational failures.

Tenants of FIASSE

These are the core principles that guide software engineers in implementing securable software engineering practices using the FIASSE framework.

Securable Principle

The Securable Principle in FIASSE says that software is never in a final, fixed state of “secure”; instead, it must be built so it can be secured and kept secure over time. Security is treated as an ongoing property of the system’s design, code, and operations rather than a checkbox reached after tests or reviews.

Fundamentally, this means:

Emphasize maintainability, trustworthiness, and reliability as core engineering attributes that support long-term security, rather than relying only on episodic security assessments.
Design architectures, codebases, and workflows so that future security fixes, hardening, and feature changes can be applied safely and predictably, without destabilizing the system.

Derived Integrity Principle

The Derived Integrity Principle in FIASSE 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 and reduce the risk of security breaches.

In practice, this means:

Treating all external inputs (client requests, headers, query parameters, cookies, webhooks, events) as untrusted until validated and normalized.
Recomputing or looking up sensitive values on the server side (e.g., roles, discounts, balances) rather than accepting them from the client or other unverified context.
Designing flows so that application behavior depends on trustworthy, server-controlled state, thereby avoiding hidden or accidental trust in anything the attacker can influence.

Canonical Input Handling

The practice of converting all incoming data into a well-defined, validated form 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.

All external inputs (HTTP parameters, headers, JSON bodies, files, events, etc.) are first normalized to a canonical representation (types, encodings, formats) and validated against strict expectations before any business logic runs.
Once canonicalized, only this trusted internal representation flows through the system, so downstream logic does not need to re-handle every edge case of raw input.

In practice, this means:

Define clear schemas and allowed formats for all inputs, then enforce them at trust boundaries (e.g., API gateways, controllers) so the rest of the code works with strongly typed, normalized objects rather than raw strings.
Use canonicalization to reduce ambiguity and attack surface (for example, around encodings, path forms, or duplicated fields), making it easier to reason about integrity, authorization, and logging in line with FIASSE's securable design goals.

The Transparency Principle

How the system works should be observable and understandable so engineers and stakeholders can see what it is doing, why it is doing it, and how it handles data. In software engineering terms, it pushes teams to design systems whose behavior, decisions, and security posture are visible rather than opaque, which directly supports securability and trustworthy operation.

Transparency means exposing clear, contextualized signals about system behavior (e.g., logs, metrics, traces, decision reasons) so people can detect misuse, misconfiguration, and security drift early.
Instead of hiding complexity behind black boxes, the system surfaces enough structured information that engineers can reason about integrity, authorization, and failure modes.
This attribute is not entirely available to the end user in order to maintain confidentiality.

In practice, this means:

Build in consistent, meaningful observability: structured logging, traceable request flows, clear error reporting, and auditable security-relevant events, all tied to business context.
Use this transparency to align AppSec and development: shared views of state, defects, and behavior.

Resources & Documentation

Access comprehensive documentation, tools, and community resources for implementing FIASSE

GitHub Repository

Access the complete FIASSE framework and SSEM documentation

The main repository contains the RFC, examples, and detailed documentation for securable software engineering practices.

Active Development CC BY-SA 4.0 License Community Driven

OWASP Project Page

Official OWASP project documentation and community resources

Visit the official OWASP project page for comprehensive documentation, community discussions, and the latest project updates.

OWASP Official Documentation Community

Join the Community

Connect with FIASSE community and contribute to the FIASSE project

Get Involved

• Contribute feedback
• Create a Pull Request with correction or addition

Contact Information

Slack: #project-fiasse

GitHub: @xcaciv/securable_software_engineering