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 and promoting fundamental Software Engineering capabilities. This makes your security efforts more effective, sustainable, and integrated with the development team.

It reframes developments relationship with security in terms software engineers already understand and can execute on. This gives development clear expectations for the involvement of the security team, reducing the aggravation that comes from last-minute security demands.

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: There is no static state of “secure”. Software engineers need to understand what is needed to create securable code without the years of extra training and experience it would take to understand the security practice.
  • Business alignment: Security must align with development’s reason for existing to engage with them. This means abandoning the “shovel-left” anti-pattern in favor of clearer communication and earlier collaboration.
  • Participation over assessment: Structured participation by the security team in the development process yields better results than security assessment alone, which tends to be late and expensive.

Scope

FIASSE does not intend to replace existing security assurance advice like OWASP PSCF, OWASP SAMM, OWASP ASVS, etc. Instead, it aims to complement other projects by providing a developer-centric framework. It does this by providing a structured approach to securing code through engineering practices.

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

  • The Derived Integrity Principle: The Derived Integrity Principle 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.

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

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

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