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.

Informations de source

Dépôt
Hack23/blacktrigram
Dernière activité de la source
31 janvier 2026 à 15:41
Langue détectée de SKILL.md
anglais
Étoiles
8
Forks
7

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

Affichage de SKILL.md

SKILL.md
Instructions source · Aperçu en lecture seule
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_
Voir sur GitHub