65e95a458d
- Мульти-провайдер: 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>
184 lines
6.5 KiB
Markdown
184 lines
6.5 KiB
Markdown
# Перечень материалов для технического аудита
|
||
|
||
По ТЗ на полный технический аудит ПО. Минимально достаточный и расширенный набор без лишнего.
|
||
|
||
---
|
||
|
||
## 1. Минимально необходимый набор (без него аудит поверхностный)
|
||
|
||
### 1.1 Исходный код
|
||
|
||
- Репозиторий(и): GitHub / GitLab / Bitbucket / self-hosted
|
||
- Актуальная основная ветка
|
||
- История коммитов (не squashed snapshot)
|
||
|
||
👉 Нужно для: архитектуры, качества кода, техдолга, рисков поддержки
|
||
|
||
---
|
||
|
||
### 1.2 Описание продукта (коротко)
|
||
|
||
1–2 страницы или устно:
|
||
|
||
- назначение системы
|
||
- ключевые сценарии
|
||
- критичность для бизнеса
|
||
- предполагаемые нагрузки
|
||
- **кто основной пользователь** (роль, не 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 |
|
||
| Инциденты / метрики | ❌ | Отсутствуют формализованно, известны на уровне команды |
|