🇺🇸 English | 🇷🇺 Русский

🛡️ Security Policy

Welcome to the official security policy for the best-practise project. Our goal is to ensure the maximum security and reliability of meta-instructions (Vibe Coding) for AI agents (Cursor, Windsurf, Copilot, Antigravity, Aider).

Since this repository serves as an "AI Knowledge Base," our security model differs from traditional software development projects.

We actively support and update only the latest major versions of our architectural and technological rules.

Version / Branch	Security Support	Support Status
main (Current)	✅ Supported
v1.x	❌ Unsupported
Legacy Branches / PRs	❌ Unsupported

Please DO NOT create public issues if you discover a critical vulnerability or potentially dangerous AI instructions in the repository (e.g., instructions that open backdoors via agents).

Secure Reporting Process:

1. Navigate to the Security Advisories tab or contact the maintainers directly.
2. Describe the issue in detail: specify the exact .md file containing the vulnerability.
3. Explain how an AI agent might incorrectly or destructively interpret the instruction.
4. Attach a Proof of Concept (PoC prompt) if possible, demonstrating the exploitation of the "flawed" rule in Cursor or Windsurf.

We are committed to acknowledging your report within 48 hours and providing a remediation plan.

This project focuses on Context Injection. Therefore, we classify threats specifically for LLMs and agentic IDEs:

• Prompt Injections: Hidden or "poisonous" instructions in rule files that force the agent to write malicious code or ignore other project security policies.
• Insecure Architectural Patterns: Instructions recommending the use of vulnerable dependencies, disabling CORS in production-ready examples, or exposing APIs without proper authentication.
• Data Leaks: Code examples or AI configuration rules that encourage agents (or developers) to leave API keys and tokens in the codebase.

Below is a visual flowchart of our standard process for handling discovered threats in meta-instructions:

graph TD
    A(["User finds dangerous rule"]) --> B{"Is it critical?"}
    B -->|"Yes (P0, P1)"| C["Submit private Security Advisory"]
    B -->|"No (P2, P3)"| D["Open standard Issue / Pull Request"]
    
    C --> E["Threat analysis by maintainers"]
    E --> F["Vulnerability isolation, disable rule"]
    F --> G["Patch MD file and update instructions"]
    G --> H["Publish Security Release & Notify"]
    H --> I(["Vulnerability resolved"])
    
    D --> G
    
    classDef critical fill:#ffebeb,stroke:#ff0000,stroke-width:2px;
    classDef safe fill:#ebffeb,stroke:#00aa00,stroke-width:2px;
    class C critical;
    class D safe;
    %% Added Design Token Styles for Mermaid Diagrams
    classDef default fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px,color:#000;
    classDef component fill:#e8f5e9,stroke:#4caf50,stroke-width:2px,color:#000;
    classDef layout fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px,color:#000;

    class E component;
    class F component;
    class G component;
    class H component;
    class I component;
    class B component;

If you propose new instructions or architectural standards (via PR), strictly adhere to the security rules:

• No Binary Files: Never add executable scripts if their code cannot be verified directly.
• Security Annotations: Any code examples for authentication or configuration must be accompanied by // SECURE: comments or explanations of why this approach is standard and secure.
• Path Restrictions: Absolute paths and hardcoded test secrets are strictly forbidden in rules (e.g., inside backend/nestjs/security.md). Always use placeholders like <YOUR_SECRET_KEY>.

🛡️ Security Policy

Добро пожаловать в официальную политику безопасности репозитория best-practise. Наша задача — гарантировать максимальную безопасность и стабильность мета-инструкций (Vibe Coding) для ИИ-агентов (Cursor, Windsurf, Copilot, Antigravity, Aider).

Поскольку данный репозиторий выступает «Базой знаний ИИ» (AI Knowledge Base), наша модель безопасности имеет существенные отличия от классических проектов разработки программного обеспечения.

Мы осуществляем поддержку и апдейт исключительно последних мажорных версий архитектурных и технологических стандартов.

Version / Branch	Security Support	Support Status
main (Current)	✅ Поддерживается
v1.x	❌ Не поддерживается
Legacy Branches / PRs	❌ Не поддерживается

ЗАПРЕЩАЕТСЯ создавать публичные Issue при обнаружении критической уязвимости или деструктивных инструкций для ИИ (например, инструкций, провоцирующих внедрение бэкдоров силами агентов).

Протокол безопасного репортинга:

1. Перейдите в раздел Security Advisories или свяжитесь с мейнтейнерами напрямую.
2. Подробно задокументируйте проблему: укажите конкретный .md файл, содержащий уязвимый паттерн.
3. Опишите вектор потенциальной некорректной или деструктивной интерпретации инструкции ИИ-агентом.
4. Предоставьте Proof of Concept (PoC prompt), демонстрирующий эксплуатацию дефектного правила в Cursor или Windsurf.

Мы обязуемся подтвердить получение репорта в течение 48 часов с предоставлением плана митигации.

Ядром проекта является AI Context Injection. В связи с этим классификация угроз адаптирована под специфику LLM и агентных IDE:

• Prompt Injections: Скрытые или «отравленные» инструкции в файлах правил, инициирующие генерацию вредоносного кода или обход других политик безопасности проекта.
• Insecure Architectural Patterns: Инструкции, легитимизирующие использование уязвимых зависимостей, отключение CORS в production-ready примерах или публикацию API без надлежащей аутентификации.
• Data Leaks: Примеры кода или конфигурации ИИ, провоцирующие агентов (или разработчиков) на публикацию API-ключей и токенов в кодовую базу.

Формализованный процесс обработки обнаруженных угроз в мета-инструкциях представлен на схеме:

graph TD
    A(["Пользователь обнаружил опасное правило"]) --> B{"Оно критично?"}
    B -->|"Да (P0, P1)"| C["Отправить частное Security Advisory"]
    B -->|"Нет (P2, P3)"| D["Открыть стандартный Issue / Pull Request"]
    
    C --> E["Анализ угроз мейнтейнерами"]
    E --> F["Изоляция уязвимости, отключение правила"]
    F --> G["Исправление MD файла и обновление инструкций"]
    G --> H["Публикация Security Release & Уведомление"]
    H --> I(["Уязвимость устранена"])
    
    D --> G
    
    classDef critical fill:#ffebeb,stroke:#ff0000,stroke-width:2px;
    classDef safe fill:#ebffeb,stroke:#00aa00,stroke-width:2px;
    class C critical;
    class D safe;
    %% Added Design Token Styles for Mermaid Diagrams
    classDef default fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px,color:#000;
    classDef component fill:#e8f5e9,stroke:#4caf50,stroke-width:2px,color:#000;
    classDef layout fill:#f3e5f5,stroke:#9c27b0,stroke-width:2px,color:#000;

    class E component;
    class F component;
    class G component;
    class H component;
    class I component;
    class B component;

При контрибьюции новых инструкций или архитектурных стандартов (через Pull Request) требуется неукоснительное следование правилам безопасности:

• No Binary Files: Запрет на коммит бинарных и исполняемых скриптов, не поддающихся прямому аудиту исходного кода.
• Security Annotations: Архитектурные паттерны аутентификации и конфигурации надлежит размечать комментариями // SECURE: с инженерным обоснованием надежности используемого подхода.
• Path Restrictions: Абсолютные пути и захардкоженные тестовые секреты строго запрещены в правилах (например, внутри backend/nestjs/security.md). Обязательно использование плейсхолдеров, таких как <YOUR_SECRET_KEY>.