S0.0.0.md

A Framework for Integrating Application Security into Software Engineering (FIASSE)

Abstract

This document outlines the Framework for Integrating Application Security into Software Engineering (FIASSE), a vendor-independent framework. FIASSE centers on a design language rooted in established software engineering terminology, provided by the Securable Software Engineering Model (SSEM). SSEM attributes define the inherent security characteristics of securable software. The accompanying principles help software engineers reason about architecture and implementation for securable outcomes. Building on the model and principles, FIASSE also includes feedback flow guidance so security findings have the highest impact. This enables development teams to resiliently add computing value while reducing the probability of material impact from cyber events throughout the code's lifespan.

To be clear about scope, FIASSE is not an assurance framework, maturity model, or replacement for control catalogs or vulnerability metrics. Its purpose is to address how security is implemented in software, connecting engineering decisions directly to securable outcomes and easing downstream pressure on assurance and compliance.

---

Table of Contents

• A Framework for Integrating Application Security into Software Engineering (FIASSE)
  • Abstract
  • Table of Contents
  • 1. Introduction
    • 1.1. The Application Security Challenge
    • 1.2. Document Purpose and Scope
  • 2. Foundational Principles
    • 2.1. The Securable Paradigm: No Static Secure State
    • 2.2. Resiliently Add Computing Value
    • 2.3. Security Mission: Reducing Material Impact
    • 2.4. The Quality-Security Relationship
    • 2.5. Aligning Security with Development
    • 2.6. The Transparency Principle
      • 2.6.1. Transparency and Maintainability
      • 2.6.2. Transparency and Trustworthiness
      • 2.6.3. Transparency Tactics
    • 2.7. The Principle of Least Astonishment
  • 3. The Securable Software Engineering Model (SSEM)
    • 3.1. Model Overview and Design Language
    • 3.2. Core Securable Attributes
      • 3.2.1. Maintainability
        • 3.2.1.1. Analyzability
        • 3.2.1.2. Modifiability
        • 3.2.1.3. Testability
        • 3.2.1.4. Observability
      • 3.2.2. Trustworthiness
        • 3.2.2.1. Confidentiality
        • 3.2.2.2. Accountability
        • 3.2.2.3. Authenticity
      • 3.2.3. Reliability
        • 3.2.3.1. Availability
        • 3.2.3.2. Integrity
        • 3.2.3.3. Resilience
  • 4. Practical Guidance for Securable Software Development
    • 4.1. Establishing Clear Expectations
      • 4.1.1. Proactive Communication
      • 4.1.2. Integrating Security into Requirements
    • 4.2. Threat Modeling
      • 4.2.1. Code-Level Threat Awareness
      • 4.2.2. Threat Modeling Solution Framework
    • 4.3. The Boundary Control Principle
    • 4.4. Resilient Coding
      • 4.4.1. Canonical Input Handling
        • 4.4.1.1. The Canonical Parsing Principle
        • 4.4.1.2. The Isolated Integrity Principle
    • 4.5. Dependency Stewardship
  • 5. Integrating Security into Development Processes
    • 5.1. Natively Extending Development Processes
    • 5.2. The Role of Merge Reviews
      • 5.2.1. The Securability Report
      • 5.2.2. The Advisory Default
      • 5.2.3. Gating as a Policy Decision
      • 5.2.4. The Audit Trail
      • 5.2.5. Posture over Pass Rates
    • 5.3. Early Integration: Planning and Requirements
    • 5.4. Phases and Empirical Intelligence
      • 5.4.1. Requirements and Design
      • 5.4.2. Build
      • 5.4.3. Merge
      • 5.4.4. Validation
      • 5.4.5. Production Operation and Incident Response
      • 5.4.6. Findings as Empirical Intelligence
  • 6. Common AppSec Anti-Patterns
    • 6.1. Security Controls in the Code Creation Process
      • 6.1.1. The Control-as-Requirement Fallacy
      • 6.1.2. The Control-as-Protection Fallacy
      • 6.1.3. The Requirements Process as the Corrective
    • 6.2. The "Shoveling Left" Phenomenon
      • 6.2.1. Ineffective Vulnerability Reporting
      • 6.2.2. Pitfalls of Exploit-First Training
    • 6.3. Strategic Use of Security Output
  • 7. Roles and Responsibilities
    • 7.1. The Role of the Security Team
      • 7.1.1. The Strategic Case for the Shift
      • 7.1.2. Capacity Relief Through Agentic AppSec
      • 7.1.3. Transition, Not Switchover
      • 7.1.4. Business-Leadership Alignment Is a Precondition
      • 7.1.5. Staffing Implications
    • 7.2. Senior Software Engineers
    • 7.3. Developing Software Engineers
    • 7.4. Product Owners and Managers
  • 8. Organizational Adoption of FIASSE
    • 8.1. Degraded-Mode Adoption
      • 8.1.1. Compensate with Agentic Assistance
      • 8.1.2. Invest in the Prerequisite First
      • 8.1.3. Adopt Partially with Named Gaps
    • 8.2. Indicators of Adoption Effectiveness
      • 8.2.1. Leading Indicators
      • 8.2.2. Lagging Indicators
      • 8.2.3. Distinguishing Framework Failure from Adoption Failure
  • 9. Conclusion
  • 10. References
  • Appendix A: Measuring SSEM Attributes
    • A.1. Measuring Maintainability
      • A.1.1. Analyzability
      • A.1.2. Modifiability
      • A.1.3. Testability
      • A.1.4. Observability
    • A.2. Measuring Trustworthiness
      • A.2.1. Confidentiality
      • A.2.2. Accountability
      • A.2.3. Authenticity
    • A.3. Measuring Reliability
      • A.3.1. Availability
      • A.3.2. Integrity
      • A.3.3. Resilience
    • A.4. Scoring and Enhancement Suggestions

---