Skip to main content

security-architecture-validation

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.

Datos de origen

Repositorio
Hack23/blacktrigram
Última actividad en el origen
31 de enero de 2026 a las 15:41
Idioma detectado de SKILL.md
inglés
Estrellas
8
Forks
7

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
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:** | Policy | When to Reference | |--------|------------------| | [Information Security Policy](https://github.com/Hack23/ISMS-PUBLIC/blob/main/Information_Security_Policy.md) | All security-related changes | | [Secure Development Policy](https://github.com/Hack23/ISMS-PUBLIC/blob/main/Secure_Development_Policy.md) | Code development and review | | [Vulnerability Management](https://github.com/Hack23/ISMS-PUBLIC/blob/main/Vulnerability_Management.md) | Security vulnerabilities | | [Access Control Policy](https://github.com/Hack23/ISMS-PUBLIC/blob/main/Access_Control_Policy.md) | Authentication/authorization | | [Cryptography Policy](https://github.com/Hack23/ISMS-PUBLIC/blob/main/Cryptography_Policy.md) | Encryption and key management | ### 4. Security Validation Checklist **Before approving any security-related change:** - [ ] **Input Validation**: All user inputs are validated and sanitized - [ ] **Output Encoding**: All outputs are properly encoded for context - [ ] **Authentication**: Strong authentication mechanisms in place - [ ] **Authorization**: Proper access controls enforced - [ ] **Encryption**: Sensitive data encrypted at rest and in transit - [ ] **Error Handling**: Errors don't leak sensitive information - [ ] **Logging**: Security events properly logged - [ ] **Testing**: Security tests cover the changes - [ ] **Documentation**: SECURITY_ARCHITECTURE.md updated - [ ] **Compliance**: ISMS policies referenced and followed ### 5. Common Security Anti-Patterns to REJECT **Immediately flag and reject these patterns:** ❌ **Hard-coded Secrets** ```typescript // BAD: Never commit secrets const API_KEY = "sk-1234567890abcdef"; ``` ❌ **Weak Cryptography** ```typescript // BAD: Don't use weak algorithms crypto.createHash('md5').update(password).digest('hex'); ``` ❌ **SQL Injection Risk** ```typescript // BAD: Never concatenate user input in queries const query = `SELECT * FROM users WHERE id = ${userId}`; ``` ❌ **XSS Vulnerability** ```typescript // BAD: Never insert unescaped user content element.innerHTML = userContent; ``` ❌ **Insecure Randomness** ```typescript // BAD: Don't use Math.random() for security const token = Math.random().toString(36); ``` ### 6. Required Security Patterns **Enforce these secure patterns:** ✅ **Environment Variables for Secrets** ```typescript // GOOD: Use environment variables const apiKey = process.env.VITE_API_KEY; if (!apiKey) throw new Error('API key not configured'); ``` ✅ **Strong Cryptography** ```typescript // GOOD: Use modern, strong algorithms import { webcrypto } from 'crypto'; const hash = await webcrypto.subtle.digest('SHA-256', data); ``` ✅ **Parameterized Queries** ```typescript // GOOD: Use parameterized queries const result = await db.query( 'SELECT * FROM users WHERE id = ?', [userId] ); ``` ✅ **Context-Aware Output Encoding** ```typescript // GOOD: Escape based on context import DOMPurify from 'dompurify'; const clean = DOMPurify.sanitize(userContent); ``` ✅ **Cryptographically Secure Random** ```typescript // GOOD: Use crypto for security-critical randomness 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: 1. **ASK** - Clarify security requirements 2. **DOCUMENT** - Update security architecture docs 3. **TEST** - Add security tests 4. **REFERENCE** - Link to ISMS policies 5. **REVIEW** - Get security specialist approval **흑괘의 보안을 지켜라** - _Protect the Security of the Black Trigram_
Ver en GitHub