/securability-engineering

name: securability-engineering
description: Generate, scaffold, or refactor code so it embodies FIASSE v1.0.4 SSEM qualities by default — 10 attributes, Transparency and Least-Astonishment principles, ASVS-aligned controls, defensive boundary handling. Trigger on "secure/securable/FIASSE-compliant code", "harden", "secure-by-default", "audit-ready", or security-sensitive components (auth, file upload, password reset, input validation, API endpoints, queries) — even when those words are not explicit. For requirements use prd-securability-enhancement; for review use securability-engineering-review. The full PRD→generate→review→enhance loop is opt-in via "--full-loop" or "end-to-end securable".
license: CC-BY-4.0

Securability Engineering — Code Generation Wrapper

This skill augments the built-in code generation capability by applying FIASSE v1.0.4 SSEM principles as engineering constraints. It does **not** perform full SSEM scoring (use `securability-engineering-review` for that).

The end-to-end PRD-enhance → generate → review → enhance → report loop is **opt-in**, not the default. See "Full Loop Mode" below.

Reference data: `data/fiasse/` (especially S2.1–S2.6 foundational principles, S3.2.1–S3.2.3 SSEM attributes including S3.2.1.4 Observability, S2.5 Transparency, S4.3 Boundary Control, S4.4 Resilient Coding, S4.4.1 Canonical Input Handling, S4.6 Dependency Stewardship) and `data/asvs/` for feature-level requirements.

When to Invoke

Trigger this skill when the user asks to:

• Generate new code (functions, modules, services, APIs, scripts)
• Scaffold a project, feature, or component
• Refactor existing code for security or maintainability
• Implement security-sensitive functionality: authentication, authorization, input handling, file upload/download, data access, cryptography, logging, error handling, session management
• Write code that crosses a trust boundary (any user/external input, any storage I/O, any network egress, any cross-service call)

Watch for adjacent phrasings: "make this safe", "harden this endpoint", "I'm exposing this to the internet, can you...", "write the production version of...", "audit-ready", "production-grade".

Modes of Operation

Default Mode (single-shot generation)

Produce securable code from the user's request directly, applying SSEM constraints. Most invocations land here. The output is code + a Securability Notes block.

Full Loop Mode (opt-in, end-to-end)

Run the full PRD-enhance → generate → review → enhance → report workflow. **Activate only when** the user:

• Passes the `--full-loop` flag or argument
• Says "end-to-end securable" or "full securability loop"
• Explicitly references the play (e.g., "follow the securable-generation play")

Otherwise stay in Default Mode. Do not invent a PRD for a small one-shot generation request.

When Full Loop Mode is active, follow [plays/securable-generation.md](../../plays/securable-generation.md). When Default Mode is active, follow this file alone.

Foundational Constraints

Before generating any code, apply these FIASSE v1.0.4 principles:

1. **The Securable Paradigm** (FIASSE v1.0.4 S2.1) — There is no static "secure" state. Generate code with qualities that let it adapt to evolving threats, not code that is merely "secure right now". 2. **Resiliently Add Computing Value** (FIASSE v1.0.4 S2.2) — Code must withstand change, stress, and attack while delivering business value. Security qualities are engineering requirements, not afterthoughts. 3. **Reducing Material Impact** (FIASSE v1.0.4 S2.3) — Favor pragmatic controls aligned with the code's context and exposure, not theoretical completeness. 4. **Derived Integrity** (FIASSE v1.0.4 S4.4.1.2) — Never implicitly trust client-supplied values for server-owned state. Explicitly extract only expected values from requests. 5. **Transparency & Observability** (FIASSE v1.0.4 S2.5, S3.2.1.4) — Code must be observable from its own outputs: meaningful naming, structured logging at trust boundaries, audit trails, and instrumentation built in — not bolted on externally. 6. **Least Astonishment** (FIASSE v1.0.4 S2.6) — Behavior and side-effects must match what the name and signature suggest. No hidden mutation, no implicit network/filesystem effects, no surprising error paths. 7. **Boundary Control** (FIASSE v1.0.4 S4.3) — Flexibility belongs in the interior; control belongs at every trust boundary. Treat boundaries as the hard shell; keep the interior loose enough to evolve. 8. **Dependency Hygiene & Stewardship** (FIASSE v1.0.4 S4.5, S4.6) — Default to the latest stable release compatible with the runtime. Prefer packages with low CVE/CWE exposure, active maintenance, and strong release signals. Treat each dependency as an ongoing relationship. 9. **Canonical Input Handling** (FIASSE v1.0.4 S4.4.1) — Apply canonicalize → sanitize → validate at every trust boundary. Prefer specific types and constrained enums. Apply Request Surface Minimization (FIASSE v1.0.4 S4.4.1.1) — process only the specific named values you expect.

SSEM Attribute Enforcement

Every code generation output must satisfy these ten attributes. Read `data/fiasse/` sections for definitions when context is needed.

Maintainability

| Attribute | Enforcement | |-----------|-------------| | **Analyzability** (FIASSE v1.0.4 S3.2.1.1) | Methods ≤ 30 LoC. Cyclomatic complexity < 10. Clear, descriptive naming. No dead code. Comments only at trust boundaries and complex logic, explaining *why* — not *what*. | | **Modifiability** (FIASSE v1.0.4 S3.2.1.2) | Loose coupling via interfaces / dependency injection. No static mutable state. Security-sensitive logic (auth, crypto, validation) centralized in dedicated modules, not scattered across call sites. Configuration externalized. | | **Testability** (FIASSE v1.0.4 S3.2.1.3) | All public interfaces testable without modifying code under test. Dependencies injectable / mockable. Security controls isolated for dedicated test s