Как аудит приложения делает смету на ремонт обоснованной

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

Аудит должен ответить на два разных вопроса: что сломано и какие части системы служба действительно контролирует настолько, чтобы их исправить? Для проектов, созданных в Lovable, Bolt, v0, Cursor или Replit, разница существенна: видимый код может составлять лишь часть системы. Настройки аутентификации, политики базы данных, переменные окружения, учетные записи развертывания, DNS, доставка почты, правила хранилища и сторонние панели могут находиться в других местах. Хорошая смета описывает всю работающую систему, фиксирует доказательства и перечисляет оставшиеся неизвестные.

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

Смета начинается с доступов, а не с оценки часов

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

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

Именно здесь многие покупатели узнают, что не владеют продуктом, за который заплатили. Репозиторием может управлять агентство. Команда хостинга может принадлежать бывшему подрядчику. У основателя бывает доступ к базе, но нет кодов восстановления. Смета не может молча предполагать, что такие пробелы исчезнут сами.

Попросите службу вернуть реестр доступов со статусом каждого актива. В полезном примере репозиторий записан на организацию покупателя, а чтение подтверждено экраном участников. Для рабочей базы указан неизвестный владелец, отсутствие доступа аудитора и одно имя подключения в качестве доказательства. Проект хостинга находится в учетной записи подрядчика, доступен для просмотра и ожидает передачи, а домен и DNS уже администрирует покупатель.

Отсутствие доступа к базе в этом примере не мелкая административная деталь. Оно не позволяет проверить политики, ограничения, миграции, резервные копии и фактическую структуру данных. В смете связанные работы нужно пометить как условные или исключить до получения доступа. Если служба называет одну и ту же фиксированную сумму до и после такого реестра, она не оценила реальный проект.

Аутентификацию нужно проверять как единую систему

Аудитор должен проследить каждый путь идентификации от браузера до данных, доступ к которым он разрешает. Рабочая форма входа доказывает лишь то, что идеальный сценарий обменял учетные данные на сеанс. Она ничего не говорит о восстановлении пароля, подтверждении почты, истечении сеанса, смене ролей, удалении учетной записи и доступе между организациями.

Начните с матрицы пользователей и ролей. Перечислите анонимных посетителей, обычных и приглашенных пользователей, заблокированных пользователей, администраторов, сотрудников поддержки и служебные процессы. Затем проверьте, что каждый из них может читать и менять. Самые полезные проверки пересекают границу: пользователь A запрашивает запись пользователя B, заблокированный пользователь повторно применяет старый сеанс, обычный пользователь напрямую вызывает административный endpoint, а браузер после выхода повторяет прежде допустимый запрос.

OWASP Application Security Verification Standard не случайно разделяет аутентификацию, управление сеансом и контроль доступа. Команды часто смешивают эти понятия. Аутентификация подтверждает, кто предъявил учетные данные. Авторизация решает, может ли этот пользователь выполнить конкретное действие с конкретным объектом. Действующий сеанс способен отправить запрещенный запрос, поэтому клиентская защита маршрута или скрытая кнопка не защищает API.

В веб-приложении на Supabase проверяйте права в базе и политики Row Level Security, а не поведение интерфейса. Документация Supabase требует RLS для таблиц в открытых схемах. Руководство по защите API поясняет: права определяют, какие роли могут обратиться к объекту, а политики ограничивают строки, которые эти роли могут затронуть. Аудит должен перечислить таблицы, представления, функции и контейнеры хранилища, а затем проверить политики минимум с двумя настоящими тестовыми пользователями.

Короткая матрица тестов выявляет пробелы лучше, чем запись «вход работает». Нужно попытаться прочитать пользователем A закрытую строку пользователя B и сохранить запрос вместе с отказом. Следует изменить role в теле запроса и зафиксировать отказ сервера и неизмененную строку. Также нужно вызвать API с истекшим сеансом, анонимно запустить административную функцию и повторно применить токен обновления удаленного пользователя. Для каждого результата сохраните время и соответствующую запись поставщика или приложения.

Аудитор также проверяет списки разрешенных перенаправлений, адреса возврата OAuth, атрибуты cookie, хранение токенов, ограничения частоты в сценариях восстановления и подтверждения, а также утечку сведений о зарегистрированных учетных записях через ошибки. Если аутентификация находится в сгенерированном клиентском коде, а привилегированные записи выполняются со служебными учетными данными, в смету нужно включить перенос этой границы доверия в компонент под контролем сервера.

Для каждого секрета нужны местоположение и решение о замене

Служба должна найти учетные данные в текущем дереве, полной истории Git, настройках сборки, переменных хостинга, локальных примерах, журналах и готовых пакетах. Поиск только в последних файлах пропустит удаленные .env и ключи, добавленные в репозиторий три недели назад. Удаление учетных данных из текущей ветки не возвращает им секретность.

В реестре нужно отличать публикуемые идентификаторы от привилегированных учетных данных. Например, Supabase разрешает размещать публикуемые ключи в общедоступных компонентах, если данные защищены RLS. Секретные и старые ключи service_role должны находиться только на сервере, поскольку имеют повышенные права и могут обходить RLS. Если считать утечкой любой видимый ключ, отчет утонет в шуме. Если считать все ключи безобидными, произойдет инцидент.

Аудитор может начать с воспроизводимых поисковых команд:

git log -p -G '(api[_-]?key|secret|token|password)'
git grep -nE '(BEGIN (RSA|OPENSSH) PRIVATE KEY|service_role|sk_live_)'

Первая команда должна вернуть подходящие коммиты и изменения. Вторая возвращает строки текущего отслеживаемого дерева в формате путь:строка:совпадение. Такие поиски не доказывают безопасность: учетные данные могут иметь незнакомый формат, находиться в двоичных файлах или существовать только в панели платформы. Зато они создают проверяемые доказательства и показывают, входит ли очистка истории в исходную смету.

Документация GitHub о защите отправки описывает блокировку распознанных секретов до их попадания в репозиторий. Мера поможет будущим коммитам, но не заменит уже раскрытые учетные данные. Для каждой находки в отчете нужно указать владельца, права, доступные среды, последнее известное применение, способ замены и риск поломки другого сервиса. В объем ремонта входят замена и зависимые изменения настроек, а не одно удаление строки.

После рабочей сборки также проверьте браузерные пакеты и сетевые вызовы. Переменная только для сервера может стать публичной из-за неверного префикса сборки, сериализации в данные страницы или сгенерированного клиента API. Если аудитор не получил доступ к панели нужного поставщика, в отчете следует написать «утечка не проверена», а не «открытых секретов нет».

Бизнес-логике нужны примеры с деньгами и состояниями

Аудитор должен восстановить правила продукта независимо от текущего кода. Сгенерированные приложения часто точно повторяют экраны, но распределяют бизнес-правила между обработчиками кнопок, триггерами базы, бессерверными функциями и условиями из промпта. Построчный просмотр не покажет соответствие правил бизнесу, пока кто-нибудь не опишет ожидаемое поведение.

Выберите сценарии, создающие необратимое или финансово значимое состояние: регистрацию и приглашение, оплату, изменение подписки, расход кредитов, согласование, возврат денег, удаление записей, экспорт и административные исключения. Для каждого сценария запишите предварительные условия, уполномоченного участника, переход состояния, побочные эффекты, поведение при повторе и результат сбоя. Затем сравните модель с кодом и рабочими данными.

Предположим, покупка кредитов проходит так:

1. Браузер создает ожидающий заказ.
2. Платежный провайдер отправляет подписанное событие об успешной оплате.
3. Серверная функция проверяет подпись и помечает событие обработанным.
4. Одна транзакция базы записывает платеж и добавляет кредиты.
5. Повторное событие возвращает успех, но не добавляет кредиты снова.

Если текущее приложение начисляет кредиты после перенаправления в браузере, пользователь сможет повторить запрос. Если webhook обновляет заказ до кредитов, а вторая запись завершается ошибкой, деньги и право на услугу расходятся. Если повторная попытка начисляет кредиты дважды, обычный повтор от провайдера создает неверный баланс. Аудитор должен дважды выполнить одно событие, по возможности прервать сценарий между записями и сохранить строки до и после.

Упражнение уточняет различие, которое пропускают слабые аудиты: сломанная функция дает заметное поведение, а сломанный инвариант допускает невозможное состояние. Ремонт кнопки способен восстановить идеальный сценарий, но оставить в базе дублированные балансы, потерянные связи или запрещенные переходы. Если рабочие записи уже могли нарушить правило, смета должна включать ремонт кода и сверку данных.

Покупателям стоит предоставить примеры простыми словами, включая неудобные исключения. Кто может отменить согласование? Может ли пользователь состоять в двух организациях? Что происходит с общими записями после ухода владельца? Отмена действует сразу или после оплаченного периода? Если ответа нет, служба должна оценить работу по принятию решения, а не маскировать решение о продукте под инженерную задачу.

Целостность базы не сводится к работающим запросам

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

Начните со структуры: таблиц, столбцов, типов, значений по умолчанию, первичных и внешних ключей, ограничений уникальности и проверок, индексов, представлений, функций, триггеров и политик RLS. Убедитесь, что миграции создают текущую схему из пустой базы. Затем сравните состояние миграций с рабочей средой. Ручные изменения в панели, которые не попали в систему версий, входят в объем исправления, потому что следующее развертывание может удалить их или вступить с ними в конфликт.

Выполните целевые запросы целостности с учетом бизнес-модели. Для приложения с несколькими организациями можно начать так:

select id from projects where organization_id is null;
select external_id, count(*) from payments group by external_id having count(*) > 1;
select m.id from memberships m
left join organizations o on o.id = m.organization_id
where o.id is null;
select status, count(*) from orders group by status order by status;

Первые три проверки должны вернуть пустой набор строк, а последняя должна показать проверенный набор допустимых значений. Непустые результаты нельзя считать одной уборкой. Они показывают инвариант, который не обеспечила схема, и участок кода, способный по-прежнему создавать неверные строки.

Проверьте пути доступа к данным на инъекции и случайные массовые обновления. Параметризованные клиентские библиотеки помогают только при правильном применении. Динамический SQL в функциях, фильтры из склеенных строк, помощники для необработанных запросов и административные инструменты тоже требуют проверки. Ищите обновления или удаления без ограничения по организации, функции с повышенными правами и представления, которые раскрывают столбцы, скрытые в основном интерфейсе.

Одного наличия резервной копии недостаточно. Аудит должен определить срок хранения, учетную запись с правом восстановления, последнюю успешную копию и факт тестового восстановления в отдельную среду. Для опасных изменений схемы в смете нужен план возврата и проверки данных. Иначе «ремонт базы» означает эксперименты с единственной важной копией.

Зависимости раскрывают долг сопровождения и риск выполнения

Аудитор должен доказать, что проект устанавливается и собирается из чистой копии с сохраненным файлом блокировки. Работающее развертывание, созданное несколько месяцев назад, не показывает, сможет ли новый инженер повторить его. Сгенерированные проекты часто накапливают дублирующиеся библиотеки интерфейса, заброшенные обертки, неиспользуемые SDK и зафиксированные версии, добавленные ради подавления одной ошибки сборки.

Запишите версию среды выполнения, менеджер пакетов, состояние файла блокировки, команды установки и сборки, а также полученные предупреждения. Запустите инструмент проверки зависимостей, но интерпретируйте его вывод. По документации npm команда npm audit сообщает об известных уязвимостях в настроенных зависимостях. Она не найдет ошибку авторизации в собственном коде, а предупреждение в пакете только для разработки не дает такой же риск, как доступный серверный код.

Для проекта JavaScript полезно сохранить такой набор:

node -v
npm -v
npm ci
npm run build
npm audit

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

Архитектуру нужно рассматривать вместе с зависимостями, потому что обе части влияют на одну оценку. Нанесите на схему точки входа, серверные функции, общее состояние, клиенты данных и повторяющиеся бизнес-правила. Считайте сгенерированные копии только тогда, когда их число меняет объем работы. Один компонент на 900 строк, управляющий маршрутами, загрузкой данных, проверкой и окнами, может потребовать разделения до безопасного ремонта. Десять аккуратных компонентов не требуют рефакторинга автоматически.

Популярный совет «переписать все начисто» часто неверен. Командам нравятся переписывания, потому что смета кажется простой и не нужно разбираться с неудобным кодом. При переписывании также теряются рабочие пограничные случаи, знания о миграциях и поведение рабочей системы, от которого уже зависят пользователи. Аудит должен рекомендовать полную пересборку только тогда, когда нынешняя основа блокирует проверку или ремонт, и прямо называть препятствие.

Тесты должны защищать исправленную границу

Аудит должен определить, находят ли тесты сбои, которые обещает устранить смета. Значок, число тестов или зеленая команда почти ничего не значат, если набор имитирует все границы и никогда не проверяет авторизацию, сохранение данных или повторные попытки.

Сначала запустите существующие команды из чистой копии и запишите, что проходит, падает, зависает или требует недокументированных переменных окружения. Разделите тесты по охвату: чистые функции, компоненты, обработчики API, политики базы и полные пользовательские сценарии. Затем свяжите каждую опасную находку с тестом, который падает до ремонта и проходит после него.

Для аутентификации используйте двух пользователей и проверьте отказ в перекрестном доступе. Для платежного события повторите один идентификатор и убедитесь, что баланс меняется один раз. Для удаления проверьте ожидаемое каскадное действие и записи, которые обязаны остаться. Для миграции примените ее к копии, похожей на рабочую, и выполните запросы целостности. Такие тесты доказывают ремонт границы, а не дают один процент покрытия.

В смете нужно указать, какие тесты добавит служба и где они выполняются. Там же следует отметить ручные проверки. Доставка почты, настройка сторонних учетных записей, поведение мобильных браузеров и переключение DNS иногда требуют сценария приемки вместо стабильного автоматического теста. Попытка поместить каждый риск в сквозной набор увеличивает стоимость и создает хрупкие тесты.

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

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

Аудитор должен проследить, как проверенный коммит становится рабочим приложением и кто разрешает каждый этап. Исходный код может быть правильным, а действующий сайт при этом указывает на другую ветку, хранит старые переменные, запускает устаревшую функцию или развертывается из недоступной покупателю учетной записи.

Запишите рабочую ветку, команду сборки, каталог результата, среду выполнения, имена переменных окружения, триггер развертывания, привязку домена, управление TLS, этап миграции базы и способ возврата. Сравните настройки локальной, предварительной, тестовой и рабочей сред. Значения могут отличаться, но их назначение и владелец должны быть понятны.

Затем проверьте происхождение сборки. Выберите безвредный идентификатор, поместите его в согласованное диагностическое место, разверните приложение по документированному пути и убедитесь, что рабочая среда показывает тот же идентификатор. Так обнаруживаются ручные загрузки, параллельные проекты и путаница веток. После проверки удалите идентификатор, если он не нужен для эксплуатации.

Владение не менее важно, чем настройки. Покупатель должен контролировать учетные записи организации, оплату, способы восстановления, домены и рабочие учетные данные. Службе исправления может временно понадобиться административный доступ, но после передачи должны остаться названные владельцы под контролем покупателя, а доступ прежних участников нужно отозвать. Общий пароль не заменяет план передачи.

Аудит также должен затронуть простой и возврат. Если миграцию базы и выпуск приложения необходимо выполнить одновременно, объясните, как команда помешает старому коду неверно читать новую схему. Если возврат не отменит преобразование данных, используйте последующее исправление и контрольную резервную копию. Общее обещание «откатиться при необходимости» не охватывает разрушительные миграции.

FixMyMess предлагает бесплатный аудит кода с диагностикой до принятия обязательств. Он может предоставить такие доказательства покупателям, которые не умеют самостоятельно проверить проект, созданный ИИ. Полезный результат все равно состоит из находки, ее доказательства, предложенного ремонта и владельца, который нужен для завершения работы.

Защищаемая смета отделяет факты от допущений

Итоговая смета должна связывать цену и сроки с реестром находок, подтвержденных доказательствами. Для каждой строки нужны симптом, первопричина или текущая гипотеза, затронутый компонент, серьезность, действие по ремонту, способ проверки, зависимость и статус объема. «Исправить аутентификацию» не описывает задачу. «Перенести назначение ролей на сервер, ограничить обновление профиля и добавить тесты политик между пользователями» описывает.

Разделите работу на три группы. Подтвержденные задачи имеют доказательства и допускают фиксированную цену. Условные задачи запускаются понятным событием, например получением доступа к базе или обнаружением неверных рабочих строк. Исключенные задачи находятся вне контроля службы или текущего решения покупателя. Такое деление позволяет сравнивать сметы без притворства, будто вся неопределенность исчезла.

Серьезность и уверенность в оценке должны оставаться разными показателями. Критический обход авторизации может легко воспроизводиться и дешево исправляться. Несоответствие данных средней серьезности способно потребовать нескольких дней анализа, потому что никто не знает число затронутых строк. Один показатель описывает последствия, другой отражает понимание работы службой. Их объединение ведет к завышенной цене заметных дефектов и недооценке неясных.

У каждой находки должна быть ссылка на доказательство, доступное покупателю. Для чтения между организациями подойдут очищенные запрос и ответ, идентификаторы пользователей и разрешившая запрос политика. Для неудачной сборки сохраните коммит чистой копии, версию среды, команду, код завершения и первую относящуюся к делу ошибку. Снимки экрана помогают с настройками панели, но текстовые выгрузки проще сравнивать после ремонта. Скройте личные данные и значения учетных данных, сохранив достаточно контекста для повтора.

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

В графике должны быть контрольные условия, а не одни даты начала и передачи. Практическая последовательность может требовать доступа к учетным записям до проверки политик, решения покупателя по спорным бизнес-правилам до ремонта логики, резервной точки до миграции и приемочных тестов до выпуска. Если условие зависит от третьей стороны, назовите зависимость и объясните, какая работа продолжится во время блокировки.

Условия приемки должны описывать наблюдаемый результат. Формулировку «обычный пользователь получает отказ при запросе счета другой организации» можно проверить. Фразу «авторизация безопасна» проверить нельзя. «Приложение устанавливается из чистой копии, а рабочая сборка успешно завершается в записанной среде» лучше, чем «код стабилен». То же правило действует для ремонта данных: укажите запрос целостности и ожидаемый пустой результат.

Покупателям стоит спросить, как служба обрабатывает изменившуюся после начала работ находку. Разумный процесс показывает новые доказательства, объясняет, почему исходный аудит не мог их выявить, указывает влияние на цену и срок и ждет согласования, если немедленное действие не предотвращает ущерб. Так защищены обе стороны. Кроме того, слабый аудит становится заметен: обычные находки, которые должны были появиться при проверке, нельзя переименовать в сюрпризы.

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

Попросите приложить к смете:

• Реестр активов и владельцев с пробелами в доступе.
• Реестр находок с доказательствами и границами ремонта.
• План тестирования и приемки каждого изменения высокого риска.
• План развертывания, миграции, возврата и передачи.
• Допущения, исключения, тарифы или правила согласования условной работы.

Служба также должна обозначить решения покупателя. Инженеры могут показать конфликт двух вариантов отмены, но не могут без полномочий выбрать коммерческое правило. Поставьте решение в график, назначьте ответственного и срок, чтобы оно не превратилось в невидимую задержку.

Отказывайтесь от оценок, построенных на прилагательных. «Небольшая уборка», «готово к рабочей среде» и «стандартное усиление безопасности» нельзя принять или проверить. Хорошая смета позволяет другому компетентному специалисту изучить те же доказательства и понять причину работы. Если доступ по-прежнему отсутствует, честной оценкой будет ограниченный этап исследования с последующим уточнением объема. Точность, придуманная до проверки, относится к театру продаж, а в унаследованных приложениях и так достаточно вымысла.