Перейти к содержанию

Контур подготовки SKUARO к production

Статус: ПРИНЯТ И НЕЗАВИСИМО ПРОВЕРЕН; SKILL_CANDIDATE ДО ПЕРВОГО DRY-RUN.

Обновлено: 2026-08-26.

Назначение

Команда ПОДГОТОВИТЬ К ПРОДАКШНУ запускает отдельный полный аудит после ручного тестирования продукта владельцем в STAGE. Контур находит дефекты, организует их исправление в DEV/STAGE, повторяет затронутые проверки и выдаёт доказательный GO, NO-GO или BLOCKED.

Обычная разработка при этом остаётся быстрой: реализация → минимальная проверка → live STAGE → ручная проверка → исправление. Production gate не запускается после каждой итерации.

Команда не выполняет фактический deploy в PROD. Даже результат GO требует отдельной явной команды владельца на конкретный PROD deploy.

Роли

Роль Ответственность
production-release фиксирует candidate и scope, строит матрицу, управляет аудитом и repair loop, собирает отчёт
frontend / backend исправляют конкретные findings по отдельным task cards
tester независимо повторяет поведенческие, интеграционные, browser и recovery-проверки
reviewer независимо проверяет security, архитектуру, permissions, supply chain, infra и полноту evidence
orchestrator принимает или отклоняет handoff и фиксирует итог GO/NO-GO/BLOCKED
владелец принимает остаточный риск и отдельно разрешает либо запрещает PROD deploy

Агент, исправивший finding, не является единственным проверяющим этого исправления.

Базовые стандарты

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

Область База Цель SKUARO
Web application security OWASP ASVS 5.0.0 все применимые требования Level 2; Level 3 — по повышенному риску
Основные web-риски OWASP Top 10:2025 явное покрытие каждого риска кодом, тестом или обоснованным N/A
API security OWASP API Security Top 10:2023 object/property/function authorization, resource limits, inventory и external API safety
Secure SDLC NIST SSDF 1.1, SP 800-218 evidence по Prepare, Protect, Produce и Respond
Контейнеры и host CIS Docker Benchmark 1.8.0 применимые Level 1 controls; отклонения документируются
Supply chain SLSA 1.2 проверяемое происхождение source/build/artifact; уровень не заявляется без evidence
Доступность WCAG 2.2 Level AA для пользовательского web-интерфейса

Стандарты фиксируют техническую базу, но не заменяют юридическую, отраслевую, платёжную или внешнюю сертификацию. Если функциональность затрагивает новые регулируемые данные или отрасль, добавляется отдельная applicability-проверка. Каждый фактический отчёт записывает точную использованную версию. Перед запуском версии сверяются с официальными источниками; новая stable-версия не считается автоматически пройденной и требует обновлённой applicability matrix.

Предусловия

До полного gate должны быть подтверждены:

  • владелец завершил ручное STAGE-тестирование;
  • исходная ревизия candidate однозначно идентифицируется и не меняется; исправления создают новые ревизии только внутри управляемого repair loop;
  • STAGE соответствует candidate;
  • production target, домены, зависимости и границы релиза определены;
  • список миграций, внешних интеграций и изменений данных известен;
  • доступные permissions перечислены без значений секретов;
  • критерии блокировки и допустимый остаточный риск зафиксированы.

Отсутствие обязательного предусловия даёт BLOCKED, а не условный GO.

Проверочные области

1. Scope, архитектура и Git

  • состав candidate, diff, generated artifacts и release notes;
  • соответствие docs, code, schema, OpenAPI и runtime;
  • module/platform/integration boundaries и отсутствие циклов;
  • чистый reproducible build из candidate;
  • branch protection, review history и отсутствие случайных/крупных/секретных файлов;
  • SBOM, лицензии, lockfile и известные уязвимости зависимостей.

2. Security, Auth и данные

  • threat model и ASVS applicability matrix;
  • sign-up, email verification, login, recovery, session revoke и logout;
  • authentication, authorization, tenant isolation и fail-closed behavior;
  • object/property/function-level access, negative and replay scenarios;
  • validation, injection, XSS/CSRF/CORS/SSRF, upload/download и rate limits;
  • cryptography/TLS/cookies/headers, безопасные ошибки и redaction логов;
  • secrets только вне Git, least privilege и план ротации без раскрытия значений;
  • privacy/retention/deletion/export/audit для фактически обрабатываемых данных.

3. API, integrations и email

  • OpenAPI drift, backward compatibility, pagination и resource consumption;
  • idempotency, timeout, retry, circuit behavior и safe provider errors;
  • webhook signatures/replay protection, если webhooks существуют;
  • DNS/TLS/sender alignment/delivery для email и штатное поведение отказа;
  • отсутствие test-only mocks, bypasses и закрытых production функций.

4. Database, migrations и recovery

  • migration up на production-like copy и проверка инвариантов;
  • план backward/forward compatibility при rolling replacement;
  • план обязательного production backup до изменения и проверяемые требования к его шифрованному хранению; создание реального production backup остаётся частью отдельно разрешённого deploy;
  • фактический restore drill только на изолированной production-like копии в DEV/STAGE с проверкой читаемости и бизнес-инвариантов;
  • документированные RPO/RTO, rollback и критерии abort;
  • запрет разрушительной миграции без отдельного разрешения и recovery evidence.

Readiness-команда не разрешает читать production data/secret values и не выполняет реальные production backup/restore. Если для доказательства нужен такой доступ, критерий получает BLOCKED до отдельного разрешения владельца.

5. Runtime, infrastructure и supply chain

  • pinned и воспроизводимые images, provenance/digest и SBOM;
  • non-root/least privilege, read-only там, где применимо, limits и healthchecks;
  • Docker/host hardening по применимому CIS baseline;
  • открытые порты, firewall, TLS, DNS, isolation и отсутствие лишних сервисов;
  • конфигурация без debug/default credentials и без секретов в image/logs;
  • rollback на предыдущий исправный artifact без пересборки на месте.

6. Quality, UX и accessibility

  • lint, typecheck, unit, integration, contract, migration, E2E и visual suites;
  • критические пользовательские сценарии на desktop/mobile и поддерживаемых browsers;
  • WCAG 2.2 AA: keyboard, focus, semantics, contrast, zoom/reflow, errors, authentication и reduced motion;
  • отсутствие console errors, broken routes, data loss и ложного success state;
  • согласованные performance budgets и нагрузка на критические endpoints.

7. Operations

  • readiness/liveness, structured logs, metrics, traces по применимости;
  • alerts на availability, errors, queues, database, storage, certificate и email;
  • dashboards, on-call/contacts, incident and rollback runbooks;
  • capacity, disk/memory/connection/queue limits и безопасная деградация;
  • post-deploy smoke, наблюдаемое окно, abort criteria и owner communication;
  • актуальные user/developer docs, release record и support/troubleshooting.

Ревизии candidate и repair loop

Gate не смешивает evidence разных состояний. Исходная ревизия фиксируется как C1. Finding и исправление не изменяют C1, а создают новую однозначную ревизию C2, затем при необходимости C3 и далее. Новая ревизия размещается в STAGE, после чего impact analysis аннулирует всё затронутое evidence прежней ревизии и определяет повторяемые проверки. Незатронутое evidence можно перенести только с явным обоснованием по diff/scope.

Перед независимыми tester/reviewer финальная ревизия замораживается. Любое новое изменение после freeze создаёт следующую ревизию и возвращает gate к impact analysis; внешний незапланированный drift даёт BLOCKED.

Каждый finding получает severity, owner, затронутый criterion, воспроизведение и конкретный expected result. Исправление выполняется в DEV/STAGE, после чего повторяются сам finding, все зависимые проверки и regression scope.

Запрещено получать зелёный статус через снижение threshold, отключение функции, test-only bypass, удаление проверки или необоснованный N/A. Если исправление требует установки/обновления зависимости, DNS/provider mutation, secret rotation, удаления или изменения production-данных, сначала требуется отдельное разрешение.

Итоговые статусы

  • GO — все блокирующие применимые критерии финальной замороженной ревизии имеют актуальное evidence, независимые tester/reviewer дали VERIFIED, recovery проверяем и остаточные риски перечислены.
  • NO-GO — подтверждён дефект или неприемлемый риск, исправимый в проекте.
  • BLOCKED — отсутствует обязательный вход, доступ, разрешение или внешнее условие.

GO не означает «абсолютно безопасно» и не является сертификатом. Это доказательное решение о готовности конкретного candidate в известном scope.

Формат расширенного отчёта

Каждый фактический запуск сохраняет один отчёт в docs/production-readiness/<final-candidate>-report.md; каталог создаётся только при первом запуске и не заводится заранее пустым. Последний итог дополнительно отражается в docs/STATUS.md, а история файлов остаётся в Git.

# Production Readiness Report

Итог: GO | NO-GO | BLOCKED
Initial candidate revision:
Final frozen candidate revision:
Production target:
Дата и проверяющие:

## 1. Результат, контекст и границы
## 2. Изменённые файлы и существенные изменения
## 3. Выполненные и пропущенные проверки с причинами
## 4. Security: findings, secrets, permissions и данные
## 5. Revision ledger: ошибки, исправления и повторные проверки
revision -> change/finding -> STAGE deploy -> invalidated evidence -> reused evidence with scope reason -> repeated checks
## 6. Standards applicability matrix
## 7. Git, dependencies, SBOM, artifacts и размеры
## 8. Database, backup, restore, rollback и RPO/RTO
## 9. Runtime, performance, observability и operations
## 10. Решения и последствия
## 11. Риски, блокеры и отложенные вопросы
## 12. Evidence matrix: criterion -> evidence -> result
## 13. Независимые tester/reviewer verdicts
## 14. Конкретный следующий шаг

В отчёте не публикуются значения секретов, персональные данные, recovery codes или полный терминальный вывод.