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!

*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 Issues 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 that security has more to offer than secret test suites.

Key Concepts

Business Alignment

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

Beyond Best Practices

Disciplined software engineering is fundamental to securable code. However, a complete approach accepts AppSec's role in requirements, acceptance and assurance.

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
• Guide adoption

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

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: Requirements, Implementation: Securable Code, Assurance: Testing and Feedback.

Expectation FIASSE

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

Requirements

1

Security Requirements

Create a comprehensive definition of security features (security is not implicit)

2

Threat Modeling

Identify potential threats and vulnerabilities using a framework like STRIDE

3

Threat Scenarios

Identify potential threats and frame them as use cases

Planning

4

Acceptance Criteria

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

5

Negative Unit Tests

Check boundaries and invalid input for expected failures

Implementation

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

Architecture & Design

1

Securable Software Engineering Model

Address SSEM attributes to the applicable degree

2

"What can go wrong?"

Actively assess what can go wrong with every change

3

Strategic Control

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

Code

1

Securable Software Engineering

Actively resilient software driven by software engineering principles

2

Intentional Dependency Management

Conscious choice to fully adopt or fork individual dependencies

3

Merge Request Reviews

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

Resilience:
Securable software can be quickly updated to fix vulnerabilities or adapt to new threats.
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.
Intention:
Development is better equipped to act with a securable goal instead of guessing about how to pass the next security assessment.

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 several fundamental and universal 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.

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 security professionals and contribute to the FIASSE project

Get Involved

• Contribute feedback
• TODO

Contact Information

Slack: #project-fiasse

GitHub: @xcaciv/securable_software_engineering