papayu/docs/AUDIT_MATERIALS_CHECKLIST.md
Yuriy 65e95a458d feat: мульти-провайдер LLM, тренды дизайна, Snyk/Documatic sync, личная автоматизация
- Мульти-провайдер: PAPAYU_LLM_PROVIDERS — сбор планов от нескольких ИИ (Claude, OpenAI), агрегация
- Тренды дизайна и иконок: вкладка в модалке, поиск по безопасным доменам (Tavily include_domains)
- Snyk Code: PAPAYU_SNYK_SYNC, REST API issues → snyk_findings в agent-sync
- Documatic: architecture_summary из .papa-yu/architecture.md в agent-sync
- Личная автоматизация: capability personal-automation (терминал git/npm/cargo, открытие URL)
- agent_sync расширен: snyk_findings, architecture_summary; analyze_project_cmd и run_batch пишут sync
- Документация: SNYK_AND_DOCUMATIC_SYNC.md, SECURITY_AND_PERSONAL_AUTOMATION.md, обновлён CLAUDE_AND_AGENT_SYNC

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-02-10 15:05:39 +03:00

6.5 KiB
Raw Blame History

Перечень материалов для технического аудита

По ТЗ на полный технический аудит ПО. Минимально достаточный и расширенный набор без лишнего.


1. Минимально необходимый набор (без него аудит поверхностный)

1.1 Исходный код

  • Репозиторий(и): GitHub / GitLab / Bitbucket / self-hosted
  • Актуальная основная ветка
  • История коммитов (не squashed snapshot)

👉 Нужно для: архитектуры, качества кода, техдолга, рисков поддержки


1.2 Описание продукта (коротко)

12 страницы или устно:

  • назначение системы
  • ключевые сценарии
  • критичность для бизнеса
  • предполагаемые нагрузки
  • кто основной пользователь (роль, не persona)
  • что считается критическим отказом

👉 Нужно для: корректной бизнес-интерпретации рисков и классификации Critical / High


1.3 Стек и окружение

  • Языки, фреймворки
  • БД, брокеры, кеши
  • Среды: prod / stage / dev
  • Где и как хостится

👉 Нужно для: оценки масштабируемости и эксплуатационных рисков


1.4 Процессы сборки и деплоя

  • CI/CD (скрипты, YAML)
  • Как выпускаются релизы
  • Как откатываются

👉 Нужно для: оценки операционных рисков


2. Очень желательно (резко повышает ценность аудита)

2.1 Архитектурные материалы

  • Диаграммы (если есть)
  • ADR (Architecture Decision Records)
  • Объяснение «почему сделано так»

👉 Позволяет отличить осознанное решение от техдолга


2.2 Документация

  • README
  • инструкции запуска
  • API-контракты
  • онбординг для разработчиков

👉 Нужно для оценки bus-factor и рисков передачи проекта


2.3 Тесты

  • Наличие / типы
  • Отчёты о покрытии (если есть)

2.4 Зависимости и лицензии

  • lock-файлы
  • private / forked зависимости

👉 Нужно для юридических и эксплуатационных рисков


3. По безопасности (если допустимо)

⚠️ Без доступа к прод-секретам

Ограничение: Аудит безопасности проводится на уровне дизайна и кода, без penetration testing и активных атак. (Защищает от завышенных ожиданий.)

  • способ хранения секретов
  • auth / roles / permissions
  • работа с персональными данными
  • результаты прошлых security-аудитов (если были)

4. Эксплуатация и реальность

4.1 Инциденты

  • известные падения
  • «больные места»
  • что боитесь трогать

👉 Очень ценно: показывает реальные риски, а не теоретические


4.2 Метрики (если есть)

  • latency
  • error rate
  • нагрузка
  • cost drivers

4.3 Ручные операционные процедуры

  • наличие runbooks, чек-листов, ручных шагов (если есть)
  • ответ «нет» — тоже полезный сигнал

5. Границы аудита (обязательно зафиксировать заранее)

Нужно явно:

  • что не проверять
  • на чём не фокусироваться
  • критические зоны (если есть)

Это защищает обе стороны.


6. Что НЕ нужно

  • доступ к продакшену
  • права на изменение кода
  • идеальная документация
  • «всё переписать» как цель

7. Итог

Для оценки программы нужен доступ к коду, понимание назначения продукта, стека и процессов доставки, плюс любые материалы, которые объясняют почему система устроена именно так. Всё остальное — усиливает точность, но не является обязательным.


8. Следующие шаги

  • Составить чеклист передачи материалов аудитору
  • Оценить объём и сроки аудита по продукту
  • Сформулировать NDA / scope для внешнего исполнителя

Вопрос: Аудит предполагается внутренний или внешний?


Приложение: готовность papa-yu

Материал Статус Где
Репозиторий Локально / при публикации
Основная ветка + история main
Описание продукта README.md, docs/
Стек package.json, Cargo.toml, tauri.conf.json
CI/CD .github/workflows/
Документация docs/, IMPLEMENTATION_STATUS_ABC.md
Тесты cargo test, golden traces
Зависимости Cargo.lock, package-lock.json
Безопасность (без секретов) ⚠️ docs/ — частично, SSRF/fetch
Инциденты / метрики Отсутствуют формализованно, известны на уровне команды