OWASP FIASSE

FIASSE is oriented by four core values (framework Section 2). Each expresses a relative preference: both sides have worth, but when choices must be made, FIASSE favors the left.

• Securable Attributes over Security Controls: prefer the engineering qualities that let a system be built and kept defensible over security controls put in after the fact to make up for weaknesses. Security controls remain valid where they belong: risk management, assurance, and external evaluation.

• Participation over Assessment: prefer structured engagement between security and development throughout the lifecycle over evaluation performed after the work is done.

• Engineering First Principles over Security Jargon: prefer grounding in established software engineering first principles over security-specific jargon or adversarial heuristics.

• Business Value over Security Activity: prefer security that sustains the organization's value creation over security pursued as an end in itself.

• The Boundary Control Principle (4.3): flexibility within a system's interior is an engineering asset to be preserved; control at every trust boundary is a security requirement to be enforced. Control here carries its software engineering sense, not the risk-and-assurance sense.

• Canonical Input Handling (4.4.1): canonicalize, validate, and sanitize input at the point of entry, applying a minimal acceptable range for each parameter.

• The Canonical Parsing Principle (4.4.1.1): parse external input into a canonical internal type at the trust boundary and fail closed when parsing does not succeed. The resulting data structure is proof that required invariants hold.

• The Isolated Integrity Principle (4.4.1.2): integrity-critical values such as prices, roles, and object state are established in a trusted context isolated from client control and derived from authoritative server-side sources. The client expresses intent; the server enforces integrity.

• Resilient Coding (4.4): defensive coding practices enforce predictable execution: strong typing, input validation at trust boundaries, output encoding, comprehensive error handling, safe resource management, graceful and secure failure, and least privilege at the code level.

• Dependency Stewardship (4.5): apply SSEM attributes when selecting, integrating, monitoring, and maintaining dependencies, for the life of the relationship.

• Requirements carry security expectations (4.1.2): Security Features, Threat Scenarios, and Security Acceptance Criteria are delivered through the requirements process. Vulnerabilities commonly trace to an expectation that was never specified; that gap belongs in the requirements process, not with developers for failing to guess.

• Guardrails, not gates (5.2): every merge produces an advisory Securability Report. Gating is a policy decision with an override path, and the override records who accepted what, and why.

• Findings as empirical intelligence (5.4.6): assurance findings and operational incidents are redrawn for the stage that could have prevented them.

• The Actionable Security Intelligence Principle (6.2): security output becomes valuable only once it has been translated into prioritized, engineering-grounded direction calibrated to the developer's context. Raw tool output, exploit-centric narratives, and unfiltered vulnerability lists are information, not yet intelligence.

Full text: framework document, v1.3.0.