OWASP FIASSE

The Securable Framework

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/ like ‘phases of the moon’) is a light weight framework that adapts to your existing software development processes. FIASSE provides a model and principles to create truly securable software by focusing on core software qualities. This makes your security efforts more effective, sustainable, and integrated with the development team.

FIASSE addresses persistent challenges such as slow progress in AppSec, friction between security and development, and the limitations of “shift left”. It flips the common AppSec model from “shoveling left” or expecting developers to “think like us”. Instead it reframes developments relationship with security in terms software engineers already understand and can execute on.

With the rise of AI-generated code, which introduces new security challenges, it is more important than ever to have a framework that ensures that new software is inherently securable. We need a set of behavioral principles that can govern developers and code assistants. Security assurance alone is not enough.

This framework identifies low friction strategies to integrate security participation into software engineering practices. It also gives development clear expectations for the involvement of the security team. This reduces the friction that can prevent security from participating in secure by design activities.

FIASSE introduces the Securable Software Engineering Model (SSEM, pronounced /si:m/), focusing on how Maintainability, Trustworthiness, and Reliability contribute to security. This model enables developers to build software that stays resilient over time. 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 to set expectations for development.

The core FIASSE tenets are:

  • The Securable Principle: No static state of “secure”
  • First Principle alignment: Resiliently add computing value while reducing the probability of material impact
  • Business alignment: in the context of development, security aligns with the business through development’s priorities
  • Participation over assessment: security actively participates in key development processes

Scope

FIASSE does not intend to replace existing security assurance advice like OWASP SAMM, OWASP ASVS, etc. Instead, it aims to complement other OWASP projects by integrating security more deeply into the Software Engineering discipline. It can do this by 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.

Core Principles

  • The Securable Principle: There is no static state of “secure”. Unmaintainable code cannot be secure over time.

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

  • The Transparency Principle: Transparency is about showing clear, contextualized visibility into how the system operates, makes decisions, and handles data. This includes clear intent in architecture reflected in the implementation.

  • The Flexibility Principle: Software engineers value flexibility in code, as it can facilitate feature implementation and bug fixing. Attackers, however, seek uncontrolled flexibility as a means to force the application to deviate from intended behavior. Trust boundaries require heightened control over data and process execution. This concept should be allowed to influence implementation best practices, such as strict input handling.

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

Core Values

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

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

  • 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

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.

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

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

    • 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 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. 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, 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 this understanding, enabling developers and AI models to work together to create software that is inherently securable.

For more information on the Securable Software Engineering Model (SSEM) and its usage, please refer to the FIASSE RFC or visit the FIASSE website.

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