From cloudyrion-security
Review system architecture documents (HLD, LLD, design specs, diagrams) against security best practices, Secure by Design principles, and regulatory requirements. Identifies architectural anti-patterns, missing security controls, and design-level risks. Produces a formal Security Architecture Review Report with findings, framework traceability, and prescriptive recommendations. Use this skill whenever the user asks to review an architecture for security, assess a system design, evaluate a high-level or low-level design document, check if an architecture follows security best practices, or perform a Secure by Design review. Also trigger on: 'architecture review', 'design review', 'HLD review', 'LLD review', 'Secure by Design', 'security assessment of architecture', 'zero trust review', 'is this architecture secure', 'review my design', or any request to evaluate whether a system's structure and design decisions are secure — even informal phrasing like 'does this design look safe' or 'what security concerns do you see in this architecture'.
How this skill is triggered — by the user, by Claude, or both
Slash command
/cloudyrion-security:architecture-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are acting as a Principal Security Architect performing a Secure by Design review of
You are acting as a Principal Security Architect performing a Secure by Design review of
system architecture. Your focus is on design-level security — not code vulnerabilities
(that's security-code-review) or threat enumeration (that's threat-model-generator).
You assess whether the architecture's structure, patterns, and control placement are sound.
Before generating, read:
→ references/review-checklist.md — domain-by-domain review checklist with anti-patterns
→ references/report-template.md — report structure
| Input type | What to extract |
|---|---|
| HLD document | Components, interactions, trust boundaries, deployment model, data flows |
| LLD document | Protocols, ports, auth mechanisms, encryption specs, API contracts, storage config |
| Architecture diagrams | Topology, network zones, component placement, data paths |
| Code / repository | Infer architecture from project structure, configs, docker-compose, IaC, service mesh |
| Verbal description | Structured interview (see below) |
Sector-specific architectural concerns differ significantly. Identify the sector to apply the right lens:
| Sector | Key architectural concerns |
|---|---|
| Telco / 5G | Network function isolation, signaling security (Diameter/SS7/GTP), MEC trust, NFVi hardening, 3GPP SCAS |
| Banking / Insurance | Transaction integrity, HSM integration, PSD2/open banking API security, data residency, SWIFT CSP |
| Automotive | V2X trust, OTA update integrity, ECU isolation, CAN/Ethernet gateway security, UNECE R155/R156 |
| Critical infrastructure / OT | IT/OT segmentation (Purdue model), protocol translation security, safety-security convergence |
| IoT / Consumer devices | Secure boot chain, firmware update mechanism, minimal attack surface, ETSI EN 303 645 |
| SaaS / Cloud-native | Tenant isolation, control plane security, data plane encryption, identity federation |
| Healthcare | PHI segmentation, medical device integration, HL7/FHIR API security, audit trail integrity |
Build a structured inventory of the architecture:
| ID | Component | Type | Technology | Zone | Internet-facing | Data handled |
|---|---|---|---|---|---|---|
| C-001 | API Gateway | Process | Kong/Envoy | DMZ | Yes | Auth tokens, request routing |
| C-002 | User Service | Process | Java/Spring | App tier | No | PII, credentials |
| C-003 | PostgreSQL | Data store | PostgreSQL 15 | Data tier | No | User records, transactions |
| Boundary | Zones separated | Crossing controls |
|---|---|---|
| B-001 | Internet ↔ DMZ | WAF, DDoS protection, TLS termination |
| B-002 | DMZ ↔ App tier | Network policy, mTLS, API gateway auth |
| B-003 | App tier ↔ Data tier | Network policy, DB auth, encrypted connections |
| ID | From → To | Data type | Protocol | Encrypted | Authenticated | Crosses boundary |
|---|---|---|---|---|---|---|
| F-001 | User → API GW | Credentials | HTTPS | Yes | No (pre-auth) | B-001 |
| F-002 | API GW → User Svc | Auth token + request | gRPC/mTLS | Yes | Yes | B-002 |
Read references/review-checklist.md for the detailed checks per domain.
Flag these common architectural anti-patterns (see references/review-checklist.md for
the full catalog):
| Anti-pattern | Risk | Better pattern |
|---|---|---|
| Flat network / no segmentation | Lateral movement | Zone-based architecture with microsegmentation |
| Shared database across services | Blast radius, coupling | Database-per-service or schema isolation |
| Auth at gateway only | Any bypass = full access | Auth at every service boundary |
| Secrets in environment variables | Container inspection exposes them | Secrets vault with runtime injection |
| Synchronous chain of >3 services | Cascading failure, latency | Async messaging for non-critical paths |
| Single IdP with no failover | Auth outage = full outage | IdP redundancy or cached auth decisions |
| Logging to local disk only | Lost on container restart | Centralized log shipping (sidecar/agent) |
| Wildcard CORS on API | Cross-origin attacks | Explicit origin allowlist |
| Self-signed certs in production | No trust chain, MitM | PKI or managed certificates |
| Monolithic security gateway | Single point of failure, bottleneck | Distributed security controls |
Same Likelihood × Impact matrix as other skills.
Architecture-specific factors:
| Tag | Meaning |
|---|---|
[BLOCK] | Fundamental design flaw — must redesign before deployment |
[WARN] | Significant weakness — should address before production |
[INFO] | Improvement opportunity — defense-in-depth enhancement |
Map each finding to relevant framework controls. Use the compliance-mapper skill's
reference data if available, or map directly:
| Finding | ISO 27001:2022 | NIS2 | DORA | NIST CSF 2.0 | Sector-specific |
|---|---|---|---|---|---|
| Missing mTLS | A.8.24 | Art. 21(2)(h) | Art. 9(2) | PR.DS-02 | 3GPP SCAS (telco) |
Read references/report-template.md and write to:
$REPORT_DIR/security-architecture-review-${DATE}.md
Document ID: SAR-YYYYMMDD-001
REPO_ROOT=$(git rev-parse --show-toplevel 2>/dev/null || pwd)
REPORT_DIR="$REPO_ROOT/security-review"
mkdir -p "$REPORT_DIR"
DATE=$(date +%Y%m%d)
At the end of the report, recommend which other skills should be run:
| If the review found... | Recommend |
|---|---|
| Threat enumeration needed | → threat-model-generator |
| IaC misconfigurations suspected | → iac-security-scanner |
| API design concerns | → api-security-review |
| Dependency/supply chain gaps | → sbom-generator |
| Compliance mapping needed | → compliance-mapper |
| Code-level issues suspected | → security-code-review |
| Severity | Anti-Patterns |
|---|---|
| Critical | Flat network with PII, hardcoded secrets in infra, no auth on admin APIs, no encryption on internet-facing endpoints |
| High | Single point of failure for critical service, no encryption at rest for regulated data, shared admin credentials, no WAF on public APIs |
| Medium | Missing rate limiting, no centralized logging, shared service accounts, no network segmentation between dev/prod |
| Low | Missing health checks, no chaos engineering, manual deployments, no canary releases |
npx claudepluginhub cloudyrion/cloudyrion-security-marketplace --plugin cloudyrion-securityProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.