| name | security-architecture-validation |
| description | Validates that all code changes follow Hack23 ISMS security architecture principles,
ensures SECURITY_ARCHITECTURE.md and FUTURE_SECURITY_ARCHITECTURE.md are maintained,
and enforces security-by-design practices across the codebase.
|
| license | MIT |
Security Architecture Validation Skill
Purpose
This skill ensures that all code changes in Black Trigram comply with Hack23 AB's Information Security Management System (ISMS) and maintain the required security architecture documentation.
When to Apply
Automatically trigger this skill when:
- Creating or modifying security-related code
- Adding new features that handle user data
- Implementing authentication or authorization
- Working with external APIs or third-party integrations
- Updating security documentation
- Reviewing pull requests with security implications
Core Principles
1. Security by Design
ALWAYS apply these principles:
✅ Defense in Depth
- Implement multiple layers of security controls
- Never rely on a single security mechanism
- Assume each layer may fail and prepare accordingly
✅ Least Privilege
- Grant minimum necessary permissions
- Use role-based access control (RBAC)
- Review and minimize access regularly
✅ Secure by Default
- Default configurations must be secure
- Opt-in for permissive settings
- Fail securely on errors
✅ Separation of Concerns
- Isolate security-critical code
- Separate authentication from business logic
- Use clear security boundaries
2. Required Security Documentation
ALL security-related changes MUST update:
SECURITY_ARCHITECTURE.md
Document the current state of:
- Authentication and authorization mechanisms
- Data protection controls (encryption, access control)
- Network security topology
- Security testing approach
- Implemented security controls
FUTURE_SECURITY_ARCHITECTURE.md
Document planned improvements for:
- Security roadmap and timeline
- Planned security enhancements
- Risk mitigation strategies
- Compliance improvements
- Technical debt related to security
3. ISMS Policy References
Always reference applicable ISMS policies:
4. Security Validation Checklist
Before approving any security-related change:
5. Common Security Anti-Patterns to REJECT
Immediately flag and reject these patterns:
❌ Hard-coded Secrets
const API_KEY = "sk-1234567890abcdef";
❌ Weak Cryptography
crypto.createHash('md5').update(password).digest('hex');
❌ SQL Injection Risk
const query = `SELECT * FROM users WHERE id = ${userId}`;
❌ XSS Vulnerability
element.innerHTML = userContent;
❌ Insecure Randomness
const token = Math.random().toString(36);
6. Required Security Patterns
Enforce these secure patterns:
✅ Environment Variables for Secrets
const apiKey = process.env.VITE_API_KEY;
if (!apiKey) throw new Error('API key not configured');
✅ Strong Cryptography
import { webcrypto } from 'crypto';
const hash = await webcrypto.subtle.digest('SHA-256', data);
✅ Parameterized Queries
const result = await db.query(
'SELECT * FROM users WHERE id = ?',
[userId]
);
✅ Context-Aware Output Encoding
import DOMPurify from 'dompurify';
const clean = DOMPurify.sanitize(userContent);
✅ Cryptographically Secure Random
import { randomBytes } from 'crypto';
const token = randomBytes(32).toString('hex');
Enforcement Rules
Rule 1: No Security Changes Without Documentation
IF (code change affects security)
THEN (SECURITY_ARCHITECTURE.md MUST be updated)
ELSE (reject the change)
Rule 2: All Secrets Must Use Secret Management
IF (new secret or credential is needed)
THEN (use environment variable OR secret management service)
ELSE (reject the hard-coded secret)
Rule 3: Security Testing Required
IF (security control added or modified)
THEN (security tests MUST be added or updated)
ELSE (change is incomplete)
Rule 4: ISMS Policy Reference Required
IF (security-related change)
THEN (reference applicable ISMS policy in PR description)
ELSE (add policy reference before approval)
ISO 27001 Alignment
This skill enforces controls from:
- A.8.1 - Inventory of Assets
- A.8.2 - Information Classification
- A.8.3 - Media Handling
- A.9.1 - Access Control Policy
- A.9.2 - User Access Management
- A.9.3 - User Responsibilities
- A.9.4 - System and Application Access Control
- A.10.1 - Cryptographic Controls
- A.14.1 - Security Requirements of Information Systems
- A.14.2 - Security in Development and Support Processes
NIST CSF 2.0 Alignment
- GV.SC-03: Security requirements are integrated into organizational planning
- ID.AM-01: Physical devices and systems are inventoried
- ID.AM-02: Software platforms and applications are inventoried
- PR.DS-01: Data-at-rest is protected
- PR.DS-02: Data-in-transit is protected
- PR.DS-05: Protections against data leaks are implemented
- PR.AC-01: Identities and credentials are issued, managed, verified, revoked
- DE.AE-02: Detected events are analyzed to understand attack targets and methods
CIS Controls v8.1 Alignment
- Control 3: Data Protection
- Control 4: Secure Configuration of Enterprise Assets and Software
- Control 6: Access Control Management
- Control 14: Security Awareness and Skills Training
- Control 16: Application Software Security
Remember
Security is not optional. Every line of code must be secure by design.
When in doubt about security implications:
- ASK - Clarify security requirements
- DOCUMENT - Update security architecture docs
- TEST - Add security tests
- REFERENCE - Link to ISMS policies
- REVIEW - Get security specialist approval
흑괘의 보안을 지켜라 - Protect the Security of the Black Trigram