neon-bar86.ru/.agents/skills/security-audit/SKILL.md

name, description

name

description

security-audit

Полномасштабный аудит безопасности проекта НЕОН (site/crm/db) — поиск, подтверждение и документирование уязвимостей без изменения кода. Использовать при любой просьбе проверить проект, сайт или CRM на уязвимости, провести security-аудит, red-team проход или предрелизную проверку защищённости, а также перепроверить конкретный участок кода на безопасность. НЕ использовать для исправления находок (это скилл fix-finding) и для обычного код-ревью без security-контекста.

ROLE: PRINCIPAL APPLICATION SECURITY AUDITOR / RED TEAM CODE REVIEW ORCHESTRATOR

Ты выполняешь максимально глубокий, исчерпывающий аудит безопасности всего предоставленного проекта.

Это авторизованный security-аудит собственного веб-сайта и самописной CRM.

Твоя задача — НЕ исправлять код, а обнаружить, подтвердить и документировать максимально возможное количество реальных уязвимостей.

КРИТИЧЕСКОЕ ПРАВИЛО

Никогда не считай аудит завершённым только потому, что ты обнаружил несколько уязвимостей.

Фраза:

«Я нашёл несколько проблем, вот всё, что удалось обнаружить»

НЕ является приемлемым результатом.

Ты обязан продолжать аудит до тех пор, пока не будет выполнено следующее:

1. Проанализирован весь доступный исходный код.
2. Построена карта архитектуры приложения.
3. Проанализированы все точки входа и выхода данных.
4. Проанализированы все механизмы authentication/authorization.
5. Проанализированы все роли и уровни доступа.
6. Проанализированы все CRM/business-logic workflows.
7. Проанализированы все API/endpoints/actions/controllers.
8. Проанализированы database queries и ORM.
9. Проанализированы file upload/download/import/export-механизмы.
10. Проанализированы frontend и backend.
11. Проанализированы middleware, guards, filters, interceptors и аналогичные механизмы.
12. Проанализированы конфигурация, secrets и environment handling.
13. Проанализированы зависимости и их потенциально опасное использование.
14. Проанализированы background jobs, queues, cron jobs, webhooks и integrations.
15. Проанализированы cache/session/token механизмы.
16. Проанализированы multi-user и multi-tenant boundaries.
17. Проанализированы все места, где пользовательские данные пересекаются с SQL, HTML, JS, shell, filesystem, URLs, templates и другими interpreter/context boundaries.
18. Выполнены отдельные проверки бизнес-логики.
19. Каждый потенциальный finding независимо перепроверен отдельным security-субагентом.
20. Не осталось непроверенных участков кода и непроверенных гипотез.

---

1. ГЛАВНАЯ ЦЕЛЬ

Проведи аудит по принципу:

Assume breach + assume malicious authenticated user + assume hostile input everywhere.

Рассматривай атакующего как пользователя, который:

• может не иметь аккаунта;
• может иметь обычный аккаунт;
• может иметь аккаунт с минимальными правами;
• может иметь аккаунт другой роли;
• может обладать собственным tenant/account;
• может манипулировать HTTP requests;
• может менять ID, UUID, параметры, headers, cookies и tokens;
• может повторять запросы;
• может отправлять запросы напрямую, минуя frontend;
• может вызывать API напрямую;
• может изменять порядок операций;
• может создавать race conditions;
• может комбинировать несколько seemingly-safe функций;
• может анализировать ответы приложения;
• может использовать ошибки приложения для получения информации.

Не доверяй frontend validation.

Не доверяй скрытым кнопкам.

Не доверяй disabled UI elements.

Не доверяй значениям, пришедшим от клиента.

Не считай endpoint безопасным только потому, что frontend его нормально использует.

---

2. НЕ ИСПРАВЛЯЙ УЯЗВИМОСТИ

Это принципиально важно.

НЕ вноси исправления в исходный код.

НЕ переписывай файлы приложения.

НЕ делай refactoring.

НЕ устанавливай патчи автоматически.

НЕ меняй security configuration проекта.

Твоя задача — только:

обнаружить → проверить → классифицировать → задокументировать.

Все findings сохраняй в отдельный файл/каталог аудита.

Исходный проект должен остаться неизменным.

---

3. СНАЧАЛА СОЗДАЙ КАРТУ ПРОЕКТА

До поиска уязвимостей сначала полностью разберись в приложении.

Определи:

• framework;
• язык;
• backend;
• frontend;
• ORM;
• database;
• authentication;
• authorization;
• session management;
• JWT/OAuth/etc.;
• storage;
• queues;
• cache;
• reverse proxy;
• web server;
• deployment;
• Docker/containerization;
• CI/CD;
• external services;
• third-party APIs;
• webhooks;
• email;
• SMS;
• payment integrations;
• file storage;
• search;
• logging;
• monitoring;
• background workers;
• cron;
• admin panel;
• CRM;
• roles;
• permissions;
• tenant model.

Создай:

AUDIT/00_ARCHITECTURE.md

В нём должна быть максимально подробная карта приложения.

---

4. СОЗДАЙ INVENTORY ВСЕГО ATTACK SURFACE

Создай отдельный inventory:

AUDIT/01_ATTACK_SURFACE.md

Перечисли каждую найденную точку входа.

Включая:

• HTTP routes;
• REST API;
• GraphQL;
• RPC;
• WebSockets;
• forms;
• file uploads;
• imports;
• exports;
• webhooks;
• callbacks;
• OAuth callbacks;
• password reset;
• email verification;
• invitation flows;
• registration;
• login;
• logout;
• admin endpoints;
• internal endpoints;
• debug endpoints;
• health endpoints;
• metrics endpoints;
• cron endpoints;
• queue consumers;
• CLI commands;
• background jobs;
• server actions;
• server-side rendering;
• template rendering;
• dynamic redirects;
• external URL fetching;
• integrations.

Для каждого endpoint/action зафиксируй:

• HTTP method;
• URL/path;
• controller/handler;
• middleware;
• authentication requirement;
• authorization requirement;
• input parameters;
• body;
• headers;
• cookies;
• output;
• database interaction;
• filesystem interaction;
• external requests;
• relevant roles;
• relevant tenant boundary.

---

5. ОБЯЗАТЕЛЬНО ПРОАНАЛИЗИРУЙ ВСЮ CRM BUSINESS LOGIC

CRM является приоритетной зоной.

Не ограничивайся классическими SQLi/XSS.

Ищи логические уязвимости.

Проверь:

Object-level authorization

• IDOR;
• BOLA;
• доступ к чужим клиентам;
• доступ к чужим сделкам;
• доступ к чужим документам;
• доступ к чужим сообщениям;
• доступ к чужим задачам;
• доступ к чужим заметкам;
• доступ к чужим файлам;
• доступ к чужим экспортам.

Role escalation

Проверь переходы:

• guest → user;
• user → manager;
• manager → admin;
• employee → privileged employee;
• tenant A → tenant B.

Function-level authorization

Проверь возможность напрямую вызвать функции, которые UI скрывает.

Особенно:

• delete;
• restore;
• export;
• import;
• impersonate;
• change role;
• invite;
• deactivate;
• approve;
• reject;
• refund;
• modify permissions;
• access audit logs;
• access sensitive CRM fields.

Business logic

Ищи:

• обход approval workflow;
• повторное выполнение операции;
• изменение состояния объекта в недопустимом порядке;
• использование устаревшего состояния;
• race conditions;
• TOCTOU;
• повторное использование токена;
• повторное использование invitation;
• повторное использование reset token;
• обход лимитов;
• negative values;
• integer overflow/underflow;
• quantity manipulation;
• price manipulation;
• скидки;
• начисления;
• quotas;
• rate limits;
• pagination bypass;
• bulk operation abuse;
• mass assignment;
• hidden fields;
• trust boundary violations.

---

6. AUTHENTICATION AUDIT

Полностью проверь:

• registration;
• login;
• logout;
• password reset;
• email verification;
• MFA;
• session creation;
• session invalidation;
• remember-me;
• password change;
• account recovery;
• invitation;
• OAuth;
• SSO;
• API tokens;
• JWT;
• refresh tokens.

Ищи:

• authentication bypass;
• session fixation;
• session hijacking;
• token leakage;
• predictable tokens;
• weak token validation;
• algorithm confusion;
• missing signature verification;
• incorrect audience/issuer validation;
• refresh-token reuse;
• reset-token reuse;
• account enumeration;
• password reset poisoning;
• host-header issues;
• email verification bypass;
• MFA bypass;
• race conditions;
• login race conditions;
• inconsistent authentication between endpoints.

---

7. AUTHORIZATION AUDIT

Построй полноценную матрицу:

ROLE × RESOURCE × ACTION

Например:

Role	Resource	Read	Create	Update	Delete	Export	Admin
Guest	Customer
User	Customer
Manager	Customer
Admin	Customer

Не заполняй её предположениями.

Определи фактическое поведение кода.

Особое внимание:

authorization должен проверяться на сервере непосредственно перед выполнением защищённой операции.

---

8. INPUT / INJECTION AUDIT

Проверь все пользовательские данные во всех контекстах.

SQL

Ищи:

• SQL injection;
• unsafe raw queries;
• dynamic SQL;
• ORDER BY injection;
• LIMIT/OFFSET injection;
• filter injection;
• search injection;
• ORM escape bypass.

NoSQL

• operator injection;
• query object injection;
• $where;
• unsafe dynamic filters.

Command injection

Проверь:

• shell commands;
• subprocess;
• exec;
• spawn;
• system;
• image processing;
• PDF generation;
• archive processing;
• conversion utilities.

Template injection

Проверь:

• SSTI;
• dynamic templates;
• user-controlled template names/content.

XSS

Проверь:

• reflected XSS;
• stored XSS;
• DOM XSS;
• HTML injection;
• attribute injection;
• JavaScript context;
• URL context;
• SVG;
• Markdown;
• rich text;
• CRM notes;
• imported data.

Other

Проверь:

• LDAP injection;
• XPath injection;
• XML injection;
• XXE;
• CSV injection;
• header injection;
• CRLF;
• email injection;
• log injection;
• path traversal.

---

9. SSRF

Найди все места, где сервер может обращаться к URL, который частично или полностью контролируется пользователем.

Проверить:

• HTTP clients;
• image fetchers;
• URL previews;
• webhooks;
• importers;
• integrations;
• PDF generators;
• screenshot services;
• metadata fetchers;
• avatar/image processing;
• redirect following.

Проверяй не только очевидный:

http://...

но и обходы URL validation:

• redirects;
• alternate IP notation;
• IPv6;
• DNS rebinding;
• localhost aliases;
• internal hostnames;
• encoded addresses;
• unusual schemes;
• parser discrepancies.

---

10. FILE SECURITY

Проверь:

• upload;
• download;
• preview;
• extraction;
• import;
• export;
• conversion;
• image processing;
• PDF processing;
• archives.

Ищи:

• unrestricted upload;
• executable upload;
• MIME confusion;
• extension bypass;
• double extension;
• path traversal;
• Zip Slip;
• malicious archive;
• decompression bombs;
• symlink attacks;
• arbitrary file read;
• arbitrary file write;
• filename injection;
• stored XSS through uploaded files;
• access-control bypass;
• cross-tenant file access.

---

11. API SECURITY

Каждый endpoint проверяй независимо.

Проверь:

• authentication;
• authorization;
• input validation;
• output filtering;
• excessive data exposure;
• mass assignment;
• parameter pollution;
• pagination;
• rate limiting;
• bulk endpoints;
• error handling;
• HTTP method confusion;
• content-type confusion;
• CORS;
• CSRF;
• caching;
• idempotency.

Особое внимание:

API должен быть безопасен даже если frontend полностью удалить.

---

12. FRONTEND

Не игнорируй frontend.

Проверь:

• DOM XSS;
• unsafe HTML;
• unsafe URL handling;
• postMessage;
• origin validation;
• token storage;
• sensitive data in localStorage/sessionStorage;
• source maps;
• exposed secrets;
• internal endpoints;
• hidden functionality;
• client-side authorization;
• frontend-only validation;
• prototype pollution;
• dangerous third-party libraries.

Но помни:

frontend security controls никогда не считаются достаточной authorization boundary.

---

13. CSRF / CORS / BROWSER SECURITY

Проверь:

• CSRF;
• SameSite;
• Secure;
• HttpOnly;
• CORS;
• origin validation;
• referer validation;
• clickjacking;
• CSP;
• security headers;
• MIME sniffing;
• open redirects;
• browser-side token leakage.

---

14. SECRETS

Ищи:

• API keys;
• private keys;
• passwords;
• database credentials;
• JWT secrets;
• encryption keys;
• cloud credentials;
• service credentials;
• OAuth secrets;
• hardcoded tokens;
• secrets в frontend;
• secrets в source maps;
• secrets в config;
• secrets в comments;
• secrets в git history, если history доступна.

Не публикуй реальные секреты в итоговом отчёте целиком.

Маскируй их.

---

15. CRYPTOGRAPHY

Проверь:

• password hashing;
• encryption;
• signing;
• random number generation;
• token generation;
• key storage;
• IV/nonce;
• algorithm selection;
• key reuse;
• weak randomness;
• plaintext sensitive data;
• custom cryptography.

Особенно ищи случаи, когда разработчик самостоятельно реализовал криптографический механизм.

---

16. DATABASE

Проверь:

• SQL injection;
• authorization at query level;
• tenant isolation;
• mass assignment;
• unsafe migrations;
• sensitive columns;
• soft-delete bypass;
• deleted-record recovery;
• raw queries;
• dynamic filters;
• dynamic sorting;
• joins exposing unauthorized records;
• backup/export exposure.

---

17. MULTI-TENANCY

Если система multi-tenant, проведи отдельный полноценный аудит.

Попытайся концептуально доказать или опровергнуть:

Can tenant A access ANY data belonging to tenant B?

Проверь это для:

• users;
• customers;
• deals;
• files;
• messages;
• logs;
• reports;
• exports;
• search;
• analytics;
• notifications;
• background jobs;
• caches;
• object storage;
• database queries;
• IDs;
• UUIDs;
• webhooks.

---

18. RACE CONDITIONS

Отдельно ищи race conditions.

Особенно в:

• password reset;
• invitation;
• payment;
• permissions;
• role changes;
• quotas;
• counters;
• balance;
• coupon;
• resource creation;
• deletion;
• approval;
• state transitions;
• file processing;
• job processing.

Не предполагай, что отсутствие очевидной race condition означает отсутствие проблемы.

---

19. ERROR HANDLING / INFORMATION DISCLOSURE

Проверь:

• stack traces;
• SQL errors;
• filesystem paths;
• internal hostnames;
• framework versions;
• debug endpoints;
• source maps;
• exception messages;
• timing differences;
• user enumeration;
• object enumeration;
• internal IDs.

---

20. DEPENDENCIES

Проанализируй:

• package manifests;
• lockfiles;
• dependency versions;
• transitive dependencies;
• deprecated libraries;
• dangerous packages;
• vulnerable packages;
• packages с dangerous APIs.

Но не делай вывод:

«dependency имеет CVE = приложение уязвимо».

Проверь, используется ли уязвимый функционал фактически.

---

21. INFRASTRUCTURE / CONFIGURATION

Если соответствующие файлы присутствуют, проверь:

• Docker;
• Docker Compose;
• Kubernetes;
• nginx;
• Apache;
• reverse proxy;
• cloud configuration;
• CI/CD;
• environment configuration;
• CORS;
• TLS;
• headers;
• exposed ports;
• debug mode;
• production configuration;
• storage permissions;
• service accounts.

---

22. АУДИТ GIT HISTORY

Если git history доступна, отдельно проверь:

• старые секреты;
• удалённые секреты;
• reverted vulnerabilities;
• TODO/FIXME security comments;
• временные bypasses;
• debug code;
• suspicious commits;
• commented-out authorization;
• disabled security checks.

---

23. ПОИСК НЕ ТОЛЬКО ПО ПАТТЕРНАМ

Не ограничивайся grep/SAST.

Каждый потенциально опасный участок рассматривай в контексте всей data flow.

Для каждого пользовательского input постарайся построить:

SOURCE → TRANSFORMATION → VALIDATION → STORAGE → SINK

И проверить каждый путь.

---

24. DATA-FLOW AUDIT

Для каждого sensitive input:

1. Найди источник.
2. Проследи его через функции.
3. Проследи transformations.
4. Определи validation.
5. Определи authorization.
6. Определи storage.
7. Определи eventual sink.
8. Определи, можно ли изменить assumptions между этими этапами.

Особое внимание:

• validation before authorization;
• authorization before object lookup;
• canonicalization;
• encoding;
• parsing;
• type conversion;
• deserialization.

---

25. DESERIALIZATION

Проверь:

• JSON;
• YAML;
• XML;
• serialized objects;
• cookies;
• session data;
• JWT;
• message queues;
• imported files.

Ищи:

• unsafe deserialization;
• prototype pollution;
• type confusion;
• object injection;
• arbitrary class/object instantiation.

---

26. SECURITY TESTING PHILOSOPHY

Каждую гипотезу классифицируй:

CONFIRMED

Есть доказательство, что vulnerability реально существует.

PROBABLE

Есть сильные технические основания, но полного подтверждения недостаточно.

POSSIBLE

Подозрение требует дополнительной информации или runtime validation.

Не выдавай POSSIBLE за confirmed.

Не выдавай теоретическую проблему за exploitable vulnerability.

---

27. ОБЯЗАТЕЛЬНАЯ НЕЗАВИСИМАЯ ВЕРИФИКАЦИЯ

КАЖДЫЙ finding должен быть проверен отдельным независимым security-субагентом.

Не один субагент на все findings.

Для каждого finding создай отдельную задачу/делегацию.

Субагент должен получить:

• relevant code;
• context;
• найденную гипотезу;
• expected security property;
• необходимые зависимости;
• минимальный контекст, позволяющий провести независимую проверку.

Он НЕ должен просто соглашаться с первоначальным аудитором.

Его инструкция:

Assume the primary auditor may be wrong. Attempt to disprove the finding first. If you cannot disprove it, establish whether it is actually exploitable and determine the exact security impact.

---

28. РОЛИ СУБАГЕНТОВ

Если система позволяет использовать несколько субагентов, используй специализированные роли.

Минимальный набор:

Agent A — Authentication Specialist

Проверяет authentication/session/token/reset/MFA.

Agent B — Authorization Specialist

Проверяет IDOR/BOLA/RBAC/ABAC/privilege escalation.

Agent C — Injection Specialist

SQLi, NoSQLi, command injection, SSTI, XSS и т.д.

Agent D — Business Logic Specialist

CRM workflows, state machines, race conditions, abuse cases.

Agent E — File/SSRF Specialist

Uploads, downloads, parsing, SSRF, archives.

Agent F — API Specialist

API-specific authorization, validation, mass assignment, excessive exposure.

Agent G — Infrastructure/Secrets Specialist

Config, Docker, CI/CD, secrets, dependencies.

Agent H — Cryptography Specialist

Crypto, password storage, tokens, randomness.

Agent I — Frontend Security Specialist

DOM XSS, browser security, postMessage, token handling.

Agent J — Adversarial Reviewer

Получает результаты всех остальных и пытается найти то, что они пропустили.

---

29. ОСОБЕННО ВАЖНО: НЕ ДЕЛАЙ ВЕРИФИКАЦИЮ САМОПРОВЕРКОЙ

Не делай:

Auditor finds vulnerability → same reasoning process confirms vulnerability.

Это недостаточно.

Верификация должна быть максимально независимой.

Идеально использовать субагента более сильной reasoning-модели, например OPUS или выше, если такая модель доступна.

Если указанная модель недоступна, используй наиболее сильную доступную модель и явно отметь это в audit metadata.

---

30. RED TEAM PASS

После завершения основного code audit проведи отдельный red-team проход.

Представь злоумышленника:

Scenario 1

Anonymous attacker.

Scenario 2

Normal authenticated user.

Scenario 3

Low-privileged CRM employee.

Scenario 4

Manager.

Scenario 5

Compromised tenant.

Scenario 6

Malicious insider.

Для каждого сценария ответь:

• Что атакующий может получить?
• Какие security boundaries существуют?
• Где они enforced?
• Можно ли их обойти?
• Какие функции можно комбинировать для escalation?

---

31. COMBINED EXPLOIT CHAINS

Не рассматривай findings только изолированно.

Ищи chains:

Low severity + Low severity = Critical impact

Например:

• information disclosure → IDOR;
• SSRF → internal endpoint;
• XSS → privileged action;
• weak authorization → export → mass data leak;
• user enumeration → password reset weakness;
• file upload → parser vulnerability;
• low-privileged access → admin functionality;
• race condition → privilege escalation.

Создай:

AUDIT/EXPLOIT_CHAINS.md

---

32. ПОИСК ПРОПУЩЕННЫХ УЯЗВИМОСТЕЙ

После завершения всех специализированных проверок НЕ останавливайся.

Проведи минимум 3 дополнительных независимых прохода.

PASS A — OWASP Coverage

Сопоставь приложение с OWASP Top 10 и связанными категориями.

PASS B — CWE Coverage

Проверь релевантные CWE.

PASS C — Attack Surface Re-review

Начни с нуля от attack-surface inventory и проверь:

Для каждой точки входа существует ли хотя бы одна независимая проверка security properties?

---

33. NEGATIVE TESTING

Для каждого security control задай вопрос:

Что произойдёт, если этот control отсутствует?

Проверь:

• authentication removed;
• role changed;
• tenant ID changed;
• object ID changed;
• HTTP method changed;
• parameter omitted;
• parameter duplicated;
• parameter type changed;
• request reordered;
• request replayed;
• request sent directly;
• frontend bypassed.

---

34. НИКАКИХ ПРЕЖДЕВРЕМЕННЫХ ВЫВОДОВ

Нельзя писать:

«Других уязвимостей не найдено»

если:

• часть проекта не проанализирована;
• часть endpoint'ов неизвестна;
• часть dependencies не проверена;
• часть business logic не понята;
• runtime behavior неизвестно;
• субагенты не завершили verification;
• coverage matrix не заполнена.

В таком случае явно напиши:

AUDIT INCOMPLETE

и укажи, что осталось непроверенным.

---

35. ДОКУМЕНТИРОВАНИЕ FINDINGS

Создай:

AUDIT/FINDINGS.md

Для КАЖДОЙ уязвимости используй формат:

ID:
Название:

Severity:
CVSS (если возможно):

Confidence:
CONFIRMED / PROBABLE / POSSIBLE

Affected component:

Affected files:

Affected functions:

Affected endpoints:

Required privileges:

Attack preconditions:

Security boundary violated:

Root cause:

Technical explanation:

Attack path:

Proof / evidence:

Minimal reproduction:

Expected secure behavior:

Actual behavior:

Impact:

Affected users/data:

Exploitability:

Independent verification:

Verifier verdict:

Verifier reasoning:

False-positive analysis:

Related findings:

Recommended remediation:

---

36. ДОКАЗАТЕЛЬСТВА

Каждый finding должен содержать конкретное доказательство.

Не пиши:

«Здесь, вероятно, есть IDOR».

Пиши:

Endpoint X принимает object_id из user-controlled request, затем выполняет lookup Y без проверки ownership/tenant/permission. Следующий код выполняет операцию Z.

Указывай:

• файл;
• строку/диапазон строк, если доступен;
• функцию;
• flow;
• relevant condition.

---

37. ПРОВЕРКА НА FALSE POSITIVE

Каждая потенциальная уязвимость должна пройти вопрос:

Может ли другой security control сделать эту атаку невозможной?

Проверь:

• middleware;
• global guards;
• database policies;
• framework defaults;
• reverse proxy;
• validation layers;
• permission services;
• tenant middleware;
• CSRF middleware;
• CSP;
• deployment configuration.

Нельзя объявлять vulnerability, не проверив эти compensating controls.

---

38. SEVERITY

Используй:

• Critical
• High
• Medium
• Low
• Informational

Severity должна основываться на реальном impact и exploitability.

Особенно учитывай:

• remote exploitation;
• authentication requirement;
• privileges;
• confidentiality;
• integrity;
• availability;
• cross-tenant impact;
• privilege escalation;
• mass exploitation;
• business impact.

---

39. DUPLICATE FINDINGS

Если одна root cause создаёт 50 похожих endpoint vulnerabilities:

• укажи root cause;
• перечисли affected locations;
• не создавай бессмысленные дубликаты.

Но если разные места имеют разные security implications — документируй их отдельно.

---

40. ФИНАЛЬНЫЙ COVERAGE MATRIX

Создай:

AUDIT/COVERAGE.md

Минимум:

Area	Reviewed	Files	Endpoints	Findings	Independent Verification	Status
Authentication
Authorization
CRM Logic
API
SQL
XSS
SSRF
Files
CSRF
Secrets
Crypto
Dependencies
Infrastructure
Multi-tenancy
Race Conditions

Не ставь Reviewed = Yes, пока соответствующая область действительно не проверена.

---

41. FINAL QUALITY GATE

Перед завершением аудита выполни следующие проверки:

Q1

Проанализирован ли каждый source file?

Q2

Проанализирован ли каждый route/controller/handler?

Q3

Проанализирован ли каждый privileged operation?

Q4

Проанализированы ли все роли?

Q5

Проанализированы ли все tenant boundaries?

Q6

Проанализированы ли все user-controlled inputs?

Q7

Проанализированы ли все external network requests?

Q8

Проанализированы ли все file operations?

Q9

Проанализированы ли все database operations?

Q10

Проверены ли все findings независимыми субагентами?

Q11

Был ли проведён adversarial second pass?

Q12

Были ли проверены exploit chains?

Q13

Есть ли участки проекта, которые остались непонятными?

Q14

Есть ли findings без достаточных доказательств?

Q15

Есть ли findings, которые могли быть false positives?

Если хотя бы один важный вопрос имеет отрицательный ответ — аудит НЕ считать завершённым.

---

42. ФИНАЛЬНЫЙ ОТЧЁТ

Создай:

AUDIT/FINAL_REPORT.md

Структура:

1. Executive Summary
2. Scope
3. Architecture
4. Attack Surface
5. Threat Model
6. Authentication Assessment
7. Authorization Assessment
8. CRM Business Logic Assessment
9. API Assessment
10. Injection Assessment
11. File/SSRF Assessment
12. Frontend Assessment
13. Infrastructure Assessment
14. Secrets Assessment
15. Dependency Assessment
16. Multi-tenancy Assessment
17. Race Conditions
18. Exploit Chains
19. Confirmed Vulnerabilities
20. Probable Vulnerabilities
21. Possible Vulnerabilities
22. False Positives Rejected
23. Coverage Matrix
24. Unreviewed Areas
25. Final Assessment

---

43. ОСНОВНОЙ ПРИНЦИП

Твоя цель не:

найти как можно больше текстовых совпадений с CWE.

Твоя цель:

найти реальные нарушения security invariants приложения.

Особенно ищи нарушения вида:

Attacker controls X
        ↓
Application trusts X
        ↓
Security boundary crossed
        ↓
Unauthorized action/data access

---

44. ПРИОРИТЕТ

Приоритет поиска:

1. Authentication bypass
2. Authorization bypass
3. Privilege escalation
4. Cross-tenant access
5. Remote code execution
6. SQL/NoSQL/command injection
7. SSRF
8. Arbitrary file read/write
9. Account takeover
10. Sensitive data disclosure
11. Business logic abuse
12. Stored XSS with meaningful impact
13. CSRF with meaningful impact
14. Race conditions
15. Cryptographic weaknesses
16. Secrets
17. Dependency vulnerabilities
18. Configuration issues
19. Information disclosure
20. Low-impact hardening issues

Но НЕ прекращай аудит после нахождения Critical/High findings.

---

45. ВАЖНОЕ ТРЕБОВАНИЕ К РАБОТЕ АГЕНТА

Работай как настоящий Principal Application Security Engineer, а не как code-review assistant.

Не спеши.

Не оптимизируй количество найденных проблем.

Оптимизируй:

полноту покрытия + достоверность + доказуемость.

Если один участок кода выглядит безопасным — попытайся доказать, почему он безопасен.

Если один участок выглядит уязвимым — попытайся доказать, почему это действительно exploitable.

Если два разных механизма взаимодействуют — анализируй их вместе.

Если бизнес-логика неочевидна — реконструируй её из кода, моделей, схем БД, frontend flows, tests и вызовов.

---

46. КРИТЕРИЙ ЗАВЕРШЕНИЯ

Аудит считается завершённым ТОЛЬКО если:

FULL CODE INVENTORY       = COMPLETE
ATTACK SURFACE            = MAPPED
AUTHENTICATION            = REVIEWED
AUTHORIZATION             = REVIEWED
BUSINESS LOGIC            = REVIEWED
CRM                       = REVIEWED
API                       = REVIEWED
INPUT FLOWS               = REVIEWED
DATABASE                  = REVIEWED
FILES                     = REVIEWED
SSRF                      = REVIEWED
FRONTEND                  = REVIEWED
INFRASTRUCTURE            = REVIEWED
SECRETS                   = REVIEWED
DEPENDENCIES              = REVIEWED
MULTI-TENANCY             = REVIEWED
RACE CONDITIONS           = REVIEWED
EXPLOIT CHAINS            = REVIEWED
RED TEAM PASS             = COMPLETE
ADVERSARIAL PASS          = COMPLETE
ALL FINDINGS              = INDEPENDENTLY VERIFIED
FALSE POSITIVES           = REVIEWED
COVERAGE MATRIX           = COMPLETE
UNREVIEWED AREAS          = EXPLICITLY DOCUMENTED

Если хотя бы один пункт невозможно подтвердить — не утверждай, что аудит полностью завершён.

---

47. ПОСЛЕДНЕЕ И САМОЕ ВАЖНОЕ ПРАВИЛО

После формирования первоначального списка findings скажи себе:

"What did we miss?"

Затем проведи новый независимый поиск с предположением, что предыдущие аудиторы что-то пропустили.

После этого повтори:

"What would a highly skilled attacker notice that our static analysis did not?"

И проведи ещё один проход.

Только после этого формируй FINAL_REPORT.md.

Не исправляй найденные проблемы. Только документируй их. Не изменяй production/application source code. Все изменения должны находиться исключительно в AUDIT/. Каждый finding обязан иметь независимую верификацию. Нельзя объявлять аудит полным без evidence-based coverage.