OWASP FIASSE

The Framework for Integrating Application Security into Software Engineering (FIASSE) is a vendor-neutral approach to embedding security directly into the software engineering discipline. FIASSE (pronounced /feiz/) addresses persistent challenges—such as slow progress in AppSec, friction between security and development, and the limitations of “shift left”. The framework begins by establishing First Principles, which serve as the foundation for the engineering principles and attributes defined in the Securable Software Engineering Model. These principles and attributes guide the subsequent software engineering strategies for creating securable software. This creates a development-centric approach that enables developers to excel while ensuring securable outcomes.

With the rise of AI-generated code, which introduces new security challenges, it is more important than ever to develop a framework that ensures that new software is inherently securable. We need a set of behavioral principles that can govern developers and code assistants. Best practices alone are not enough; developers must have the integrity of the timebox, and security processes must be streamlined.

FIASSE introduces the Securable Software Engineering Model (SSEM, pronounced /si:m/), which uses established engineering terms to define the core attributes of securable software, focusing on how Maintainability, Trustworthiness, and Reliability contribute to security. This model enables developers to build software that is easier to analyze, modify, and test for security. It does not require them to have years of security experience or adopt an adversarial mindset. By aligning security with the realities of software development, FIASSE helps teams create systems that are resilient and adaptable, supporting both business objectives and security concerns.

Fundamentals

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:

  • Prefer securable attributes over security controls; security controls should be expressed through requirements.
  • Prefer security participation over review - AppSec should be skilled enough to participate in product, architecture, and design processes.
  • Prefer integration over assessment - where security traditionally performs assessments, it is more timely for them to be a part of those processes.
  • Prefer alignment with business over imposing disruptive SLAs - shortening timelines for remediation is an illogical strategy.
  • Prefer actionable security intelligence over ‘Shoveling Left’ - find-and-fix is an ineffective, unsustainable strategy.

Scope

FIASSE does not intend to replace existing security assurance advice like OWASP SAMM, OWASP ASVS, etc. Instead, it aims to integrate security more deeply into the Software Engineering discipline, providing a structured approach to securing code through engineering practices. This will reduce findings and turnaround time, thereby decreasing the probability of material impact.

Road Map

  • Establishment of project governance and contribution guidelines.
  • Use feedback to refine the framework and its components.
  • Formal publication of FIASSE and SSEM specifications, including their core attributes and integration strategies.
  • Development of an SSEM Primer/Introduction Guide to help software engineers understand the model and its application.
  • Create a guide for Application Security practitioners on using and teaching FIASSE with relevant security requirements and code examples.
  • Collection of SSEM adoption use cases or patterns to illustrate practical applications and benefits.

Overview

Pentest results, CVE, CWE, and other vulnerability data often lack practical application or clarity for software engineers, making it challenging to integrate security measures effectively. FIASSE provides a framework to translate these concepts for security professionals, helping them better align with the business of software development. To maintain this alignment, FIASSE also suggests restructuring how AppSec teams interact with developers in some cases. The result for development is a set of transparent expectations, leading to the organic inclusion of security concerns in their engineering priorities. This approach ensures that security measures are seamlessly integrated into software development, preventing vulnerabilities that could lead to cyber incidents.

The project’s process is distinct because it begins with First Principles, then identifies engineering principles and attributes that inform subsequent strategies for developing securable software.

Core FIASSE Principles

  • The Securable Principle: There is no static state of “secure”.

  • First Principle Alignment: While the Security discipline works to ‘reduce the probability of material impact’, the Software Engineering discipline works to ‘resiliently add computing value’. FIASSE provides the structure and knowledge to dovetail these two efforts.

  • The Derived Integrity Principle: An application avoids implicitly adopting unmanaged context, such as data from the client, to preserve its integrity and prevent potential security breaches.

  • Actionable Security Intelligence: Instead of forcing development to decode pentest results and testing terminology, security should strategically translate results and collaborate with Software Engineering on systemic flaw reductions.

  • Securable Attributes over Security Controls: Rather than focusing on security controls, checklists, or gates, the emphasis is on building software with inherent qualities that make it easier to analyze, modify, test, and trust.

  • Participation over Assessment: Prefer active participation in the development process rather than assessment, review, or reporting. This means security participation in architecture, design and requirements in whatever form that takes. This makes assessment part of an iterative and empirical process.

  • Business Alignment: FIASSE facilitates Application Security’s understanding of business needs as given to software development. This ensures that security concerns are addressed without disrupting development workflows. Structured alignment allows security to increase their impact on the security outcomes of development.

The Model

The Securable Software Engineering Model (SSEM) is centered on providing a design language that uses established software engineering terms to define the core attributes that make software “securable”, which include:

  • Maintainability: The ease with which software can be modified to correct defects, improve performance, or adapt to a changed environment. This includes the ability to analyze, modify, and test software for security vulnerabilities without requiring developers to adopt an adversarial mindset.
  • Trustworthiness: The degree to which software can be trusted to behave as expected, particularly in the face of potential security threats. This includes the ability to ensure that software meets its security requirements and behaves predictably under various conditions.
  • Reliability: The ability of software to perform its intended functions under specified conditions for a specified period of time. This includes resilience to failures and the ability to recover from errors without compromising security.

The detail and structure of the SSEM are designed to align with the realities of software development, focusing on creating systems that are securable and adaptable to future changes. By focusing on these core attributes, the SSEM aims to enhance security, maintain developer velocity, and improve software systems’ ability to adapt to a changing security landscape while maintaining usability and performance.

Generative AI models, like human developers, can be trained to produce software that is securable. However, this requires a clear understanding of the attributes that make software securable and developers must apply these attributes in practice. The SSEM provides a framework for this understanding, enabling developers and AI models to work together to create software that is inherently securable.

SSEM Usage

FIASSE is structured in a three-pillar approach. Those pillars are:

  • Security Requirements
  • Securable Code
  • Application Security Assurance

The model has various uses beyond being standard terms to clearly define intentional attributes in software engineering. They also form the basis for a set of behavioral principles that can govern developers and code assistants. They can also ground security requirements, making them more relevant and actionable.

This framework intends to provide a general overview of requirements and assurance activities. There are standards and frameworks that generally guide these activities. High-quality sources exist for security requirements, features, and assurance guidance. FIASSE gives priority to software-engineering-level strategies and structured interactions with security teams in the context of requirements and assurance for long-term success.

For more information on the Securable Software Engineering Model (SSEM) and its usage, please refer to the FIASSE RFC. Tell us what you think!

Feedback

Please use the Github Discussions for feedback:

  • What do like?
  • What don’t you like?
  • How can we make FIASSE/SSEM easier to use?
  • How could FIASSE/SSEM be improved?

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:

  1. Join the OWASP Slack workspace to connect with the OWASP community and get help with any questions you may have.

  2. Review the OWASP Projects page to browse the list of OWASP projects and find a project that aligns with your interests and skills.

  3. Visit the project’s individual page and repository to familiarize yourself with the project goals and objectives.

  4. Fork the repository and clone it to your local machine.

  5. Make your changes and review them locally.

  6. Submit a pull request with your changes.

Pull Request Guidelines

Before submitting a pull request, please make sure:

  1. Your changes are consistent with the project’s goals and objectives: this isn’t an assurance framework.

  2. Your changes are well-documented and follow the project’s standards and styles.

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

Watch Star