/securability-engineering-review

name: securability-engineering-review
description: Score a codebase, file, or merge request against the FIASSE v1.0.4 SSEM model — 0-10 per attribute, equal-weighted pillars, evidence-backed strengths and weaknesses, prioritized recommendations, 50-item checklist appendix. Trigger on "review/score/audit securability", "SSEM scorecard", "FIASSE/SSEM compliance", "where would I start hardening this?", "is this audit-ready?", "security posture baseline" — including phrasings that don't say SSEM explicitly. For requirements use prd-securability-enhancement; for new code use securability-engineering.
license: CC-BY-4.0

SSEM Evaluation (Scoring and Reporting)

Analyze code for securable engineering qualities and produce a structured SSEM scorecard. This file is **authoritative** for the rubric, weights, severity classification, and report shape. The play at [plays/securability-engineering-review.md](../../plays/securability-engineering-review.md) is the step-by-step runbook; consult it for *when* to do each step, not for *what* the rubric says.

Aligned with [FIASSE v1.0.4](https://github.com/OWASP/FIASSE/blob/v1.0.4/docs/securable_framework.md). Per-attribute measurement guidance in `data/fiasse/SA.*.md` (Appendix A).

When to Invoke

Trigger this skill when the user asks to:

• Assess, audit, score, rate, or evaluate the **securability** of code
• Produce an **SSEM scorecard** or SSEM evaluation report
• Review a merge request / pull request through a **securable engineering** lens
• Establish a **security posture baseline** for a project
• Identify **engineering quality** issues that affect security (not vulnerability-centric)
• Answer "where would I start hardening this codebase?"
• Check **FIASSE/SSEM compliance**

Adjacent phrasings: "rate this code for security", "is this audit-ready?", "what's the security health of X?", "how securable is this?", "do a sec-engineering review", "give me a posture report".

Scoring Framework

Each attribute is scored **0-10**. Pillar scores are simple averages of their attribute scores. The overall SSEM score is the simple average of the three pillar scores.

Pillars and Attributes (FIASSE v1.0.4 — 10 attributes, equal weights)

| Pillar | Pillar Weight | Attributes | Per-Attribute Weight | |--------|---------------|------------|----------------------| | **Maintainability** | 1/3 | Analyzability, Modifiability, Testability, Observability | 1/4 each | | **Trustworthiness** | 1/3 | Confidentiality, Accountability, Authenticity | 1/3 each | | **Reliability** | 1/3 | Availability, Integrity, Resilience | 1/3 each |

**Pillar score** = average of its attribute scores. **Overall SSEM score** = (Maintainability + Trustworthiness + Reliability) / 3.

Equal weighting reflects FIASSE v1.0.4's stance that no SSEM attribute is intrinsically more important than another — context-specific severity is captured in *findings*, not in the rubric.

Scoring Rubric (Anchor Points)

| Score | Anchor | |-------|--------| | **10** | Exemplary implementation | | **8** | Strong implementation with minor issues | | **6** | Adequate implementation with notable gaps | | **4** | Weak implementation with significant issues | | **2** | Minimal or poor implementation |

Interpolation between anchors is allowed when justified by evidence. Stay consistent with the rubric language.

Attribute Inventory (the 10 scored items)

Every report MUST produce a numeric 0-10 score for each of these:

**Maintainability** 1. **Analyzability** (FIASSE v1.0.4 S3.2.1.1) — clarity, complexity, naming, structure 2. **Modifiability** (FIASSE v1.0.4 S3.2.1.2) — coupling, cohesion, separation of concerns 3. **Testability** (FIASSE v1.0.4 S3.2.1.3) — coverage, mockability, independence 4. **Observability** (FIASSE v1.0.4 S3.2.1.4) — log coverage, instrumentation, failure-path visibility

**Trustworthiness** 5. **Confidentiality** (FIASSE v1.0.4 S3.2.2.1) — sensitive-data handling, least privilege, encryption 6. **Accountability** (FIASSE v1.0.4 S3.2.2.2) — audit trails, action traceability 7. **Authenticity** (FIASSE v1.0.4 S3.2.2.3) — identity verification, token integrity, non-repudiation

**Reliability** 8. **Availability** (FIASSE v1.0.4 S3.2.3.1) — resource limits, timeouts, graceful degradation 9. **Integrity** (FIASSE v1.0.4 S3.2.3.2) — input handling, parameterized queries, derived state 10. **Resilience** (FIASSE v1.0.4 S3.2.3.3) — error handling, recovery, defensive coding

Grading Scale

| Score Range | Grade | Description | |-------------|-------|-------------| | 9.0–10.0 | **Excellent** | Exemplary implementation, minimal improvement needed | | 8.0–8.9 | **Good** | Strong implementation, minor improvements beneficial | | 7.0–7.9 | **Adequate** | Functional but notable improvement opportunities exist | | 6.0–6.9 | **Fair** | Basic requirements met, significant improvements needed | | < 6.0 | **Poor** | Critical deficiencies requiring immediate attention |

Severity Classification (for individual findings)

Severity is an **engineering-impact** judgment, not a CVSS or CWE score. FIASSE does not borrow assurance-tool severity scales. Classify each finding by its effect on SSEM scores and on the system's ability to remain securable.

| Severity | Criteria | |----------|----------| | **CRITICAL** | A pillar score is held ≤4 because of this finding *alone*; or an attribute scores ≤2 due to systemic absence (e.g., no input validation anywhere, no audit trail, ambient client-trust). Remediation requires architectural change. | | **HIGH** | A single attribute scores ≤4 due to this finding; or the finding reduces a pillar score by ≥1.5 points. Localized but pervasive (e.g., string-built SQL across one service). | | **MEDIUM** | Reduces a single attribute by ~1 point; specific module or pattern. Remediation contained to one module. | | **LOW** | Localized engineering improvement; ≤0.5 score impact. | | **INFO** | Best-practice observation; no measurable score impact.