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.
How this skill is triggered — by the user, by Claude, or both
Slash command
/securable-claude-plugin:securability-engineering-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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/code-analysis/securability-engineering-review.md](../../plays/code-analysis/securability-engineering-review.md) is the step-by-step runbook; consult it for *when* to do each step, not for *...
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/code-analysis/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. Per-attribute measurement guidance in data/fiasse/SA.*.md (Appendix A).
Trigger this skill when the user asks to:
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".
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.
| 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.
| 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.
Every report MUST produce a numeric 0-10 score for each of these:
Maintainability
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
| 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 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. |
If the repository or input is incomplete, ask for these before scoring:
If essential context is missing, score conservatively and state the limitation explicitly. Do not invent coverage, architecture, or operational controls.
Full read-through is impossible at scale. Sample deliberately and declare what was sampled. The report's credibility rests on the sampling discipline, not on claimed totality.
Inspection priority order:
For each sampled area, mark the report with the file paths actually inspected. For un-sampled areas, score conservatively (cap at 6) and call out the gap in the assessment line. Do not extrapolate from sampled to un-sampled with confidence.
For very large repos, scope the review to a single service / package / module and say so in the scope statement. A focused scorecard is worth more than a vague one covering everything.
The full step-by-step runbook lives in plays/code-analysis/securability-engineering-review.md. The high-level shape:
The report must contain exactly these three parts in order. Do not skip parts even on small reviews.
A compact summary block. The exact ASCII shape can flex (Markdown tables are also acceptable when the review is short), but it must include:
Per pillar, write:
1. **[Title]** (Severity: CRITICAL/HIGH/MEDIUM/LOW/INFO)
- Issue: [Specific problem]
- Impact: [Effect on the pillar score and on the system]
- Solution: [Actionable steps]
- Expected Improvement: +[X.X] points
For per-finding format, use templates/finding.md. For full-report scaffold, use templates/report.md.
The official checklist:
Mark each [x] (passing) or [ ] (failing) with a brief inline note when failing.
End with a checklist summary:
Snippet under review (Python, ~12 lines):
@app.post("/notes/{note_id}")
def update_note(note_id, body):
sql = f"UPDATE notes SET body = '{body}' WHERE id = {note_id}"
db.execute(sql)
print("note updated " + note_id)
return {"ok": True}
Analyzability — 4/10 (weak). Single-purpose handler but unsafe string formatting; no input typing; no early returns; conflates parsing, persistence, and response shaping.
Evidence: f"UPDATE notes SET body = '{body}' WHERE id = {note_id}".
Observability — 2/10 (minimal). print(...) is not structured output. No correlation ID, no actor, no outcome field. Failure paths are silent.
Evidence: print("note updated " + note_id).
Integrity — 2/10 (minimal). SQL injection via string interpolation; no parameterized queries; no ownership check (any caller can update any note ID — Derived Integrity violation per FIASSE v1.0.4 S4.4.1.2).
Evidence: same line as above; no current_user derivation.
Accountability — 3/10 (weak). print is not an audit log; missing actor, action verb, target ID type-tagged, and outcome.
Evidence: print("note updated " + note_id).
Recommendation (HIGH) — Replace the f-string with a parameterized query that scopes by owner, and emit a structured note.update log with {actor, note_id, outcome}. Expected improvement: Integrity +5, Accountability +3, Observability +4, Analyzability +2.
This is the level of specificity the report should hit at scale — every score paired with a code-anchored observation, every weakness with a remediation that names the change.
When you find one of these patterns, tag the finding with the FIASSE/SSEM principle it violates. Specific named tagging is what makes a report actionable — saying "the code mishandles auth" is weak; saying "this is a Derived Integrity violation (FIASSE v1.0.4 S4.4.1.2) — the server's authorization decision rests on a client-asserted JWT claim" is strong.
| Pattern observed in code | Principle / attribute violated | Tag in finding |
|---|---|---|
Server decides who-can-do-what based on a client-asserted claim (req.user.email, request.body.user_id, X-Tenant-ID header) | Integrity — Derived Integrity Principle (FIASSE v1.0.4 S4.4.1.2) | "Derived Integrity violation" |
Spread of req.body / **kwargs directly into a database update or model field-set | Integrity — Request Surface Minimization (FIASSE v1.0.4 S4.4.1.1) | "Request Surface Minimization violation; mass assignment" |
| String-built SQL or shell commands; format strings with user input | Integrity — input handling at trust boundary (FIASSE v1.0.4 S4.4.1, S4.3) | "Trust boundary input handling" |
Path joined with user-controlled segment without ../separator validation | Integrity — trust boundary; canonicalize → sanitize → validate (FIASSE v1.0.4 S4.4.1) | "Path canonicalization gap" |
jwt.verify with no pinned algorithms / no audience / no issuer; or using a default-allow algorithm list | Authenticity (token integrity) | "Token verification under-specified" |
console.log / print / fmt.Println standing in for an audit trail; missing actor, target, outcome, request id | Accountability + Observability (FIASSE v1.0.4 S2.5, S3.2.1.4) | "Unstructured audit trail" |
Bare except: / catch (e) returning raw exception text to the client | Resilience (graceful degradation); Confidentiality (info leakage) | "Specific exception handling missing" |
| Module-level globals (DB connection, app, config) created at import time | Modifiability (loose coupling); Testability (mockability) | "Import-time side effects" |
ioutil.ReadAll(r.Body) / unlimited request body buffer | Availability + Resilience (resource limits) | "Unbounded resource consumption" |
Pervasive any typing on the trust-boundary surface (TypeScript / dynamic langs) | Analyzability; Integrity (validation) | "Trust-boundary type erasure" |
Silent try { … } catch {} / failure paths that emit no log or metric | Observability (failure-path visibility) (FIASSE v1.0.4 S3.2.1.4) | "Silent failure" |
| Health/metrics endpoints absent; readiness/liveness derived from external probes only | Observability (instrumentation built into code, not bolted on externally) (FIASSE v1.0.4 S3.2.1.4) | "External-only instrumentation" |
You don't need this whole table inline in every report. But when one of these patterns is present, the finding should name the principle by tag — not just describe the symptom.
except: at app/handlers.py:42 with except (ValidationError, NotFound) as e:" is.Always:
When invoked:
data/fiasse/SA.*.mddata/asvs/Provides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.
npx claudepluginhub securability-engineering/securable-claude-plugin --plugin securable-claude-plugin