Технический аудит сайта и приложения
Проверяем архитектуру, код, безопасность, данные и процесс релизов действующего продукта в согласованном объёме. Результат — отчёт с доказательствами: резюме для владельца, находки для команды, приоритеты и roadmap. Работать по отчёту может ваша команда или любой подрядчик. Работаем из Алматы с бизнесом по всему Казахстану.
- Код-ревью
- Архитектура
- План
Что такое технический аудит сайта или приложения?
Технический аудит — это плановая проверка архитектуры, кода, безопасности, данных и процесса релизов в согласованном объёме. Каждая находка подтверждена ссылкой на код, конфигурацию или воспроизводимую проверку, оценена по серьёзности и по уверенности и снабжена рекомендацией. Аудит — не тест на проникновение и не сертификация: он показывает реальные риски и порядок работы с ними, а то, что не проверялось, названо в отчёте открыто.
Кому нужен аудит
Действующий продукт перед ростом
Впереди новые функции, рост нагрузки или интеграции. Аудит до масштабирования дешевле разбора инцидентов после: технический долг проявляется в самый неудобный момент.
MVP перед запуском или раундом
Первая версия работает, но её собирали быстро. Нужно понять, что исправить до первых платящих клиентов, а что спокойно подождёт.
Legacy-система
Система работает годами, но менять её страшно: устаревший стек, нет тестов, знания — в головах конкретных людей. Аудит показывает, что развивать, что изолировать и что заменять поэтапно.
Смена подрядчика
Прошлая команда ушла, документации нет. Аудит восстанавливает картину для новой команды: как устроена система, где риски и с чего начинать.
Техническая проверка перед сделкой
Независимая оценка кода, инфраструктуры и процессов разработки перед покупкой продукта или инвестициями. Юридическую и финансовую проверку она не заменяет.
Молодая команда без техлида
Независимый взгляд на решения команды: что уже сделано хорошо, что исправить, пока это дёшево, и какие практики добавить в первую очередь.
Какие задачи решает
Насколько безопасен существующий продукт?
Security review в рамках аудита проверяет аутентификацию и роли, доступ к чужим данным, хранение секретов и уязвимые зависимости — в согласованном объёме. Итог — находки по степени серьёзности, с доказательствами и планом исправления. Это обзорная проверка кода и конфигурации, а не тест на проникновение.
Почему сайт или приложение работает медленно?
Ищем узкие места: тяжёлые запросы к базе данных, отсутствие кэширования, неоптимальный frontend. По каждому — рекомендация и способ проверить эффект после исправления. Нагрузочные выводы делаем только при согласованном профиле нагрузки и подходящей среде.
Стоит ли переписывать legacy-систему с нуля?
Чаще всего — нет. Architecture review показывает, какие части системы можно развивать, какие — изолировать, а какие действительно требуют замены. Поэтапный план обычно дешевле и безопаснее полного переписывания.
Как оценить работу текущего подрядчика или команды?
Независимый code review даёт аргументированную оценку: читаемость, тестируемость, устойчивость к изменениям, процесс релизов. Это ответ на вопрос, за что вы платите и какие риски накапливаются в проекте, — с примерами из кода, а не впечатлениями.
Типы аудита: из чего собирается объём
пунктов
- Architecture review — модули и их границы, зависимости, узкие места масштабирования
- Code quality — читаемость, дублирование логики, тестируемость, воспроизводимость сборки
- Security review — аутентификация и роли, доступ к чужим объектам, секреты, уязвимые зависимости
- Performance — запросы к базе, кэширование, frontend-метрики; нагрузка — только с согласованным профилем
- Database — схема, целостность данных, миграции, бэкапы и восстановление
- CI/CD — процесс релиза, разделение окружений, откат
- Product readiness — логи, мониторинг, обработка ошибок, операционная готовность
- UX — критические пользовательские сценарии и доступность, если включены в объём
- Integrations — платежи, 1С, CRM, внешние API: контракты и обработка сбоев
Уровни проверки
Обзорный аудит, проверка безопасности и тест на проникновение — разные работы с разными правилами. Мы называем уровень заранее, чтобы ожидания совпадали с результатом.
| Уровень | Что означает | Чего не означает | У InterLAB |
|---|---|---|---|
| L0 Discovery | Короткий бриф и сортировка задачи | Не code review и не аудит | Бесплатный первый разговор |
| L1 Express | Ручной обзор конкретной зоны в ограниченном объёме | Не полное покрытие и не pentest | Express-аудит |
| L2 Full Review | Плановый обзор кода и архитектуры по доменам, с доказательствами | Не гарантия безопасности и не соответствие стандарту | Полный технический аудит |
| L3 Security | Специализированные проверки безопасности по письменно согласованным методам | Не запускается одной заявкой с сайта | Только после отдельного согласования методов и полномочий |
| L4 Pentest | Отдельная проверка с правилами взаимодействия, ограниченная по объёму и времени | Не входит в обычный аудит | Сейчас не предлагаем |
Ориентиры для доменов проверки — OWASP ASVS 5.0.0 (веб), MASVS 2.1.0 (мобильные приложения), API Security Top 10 — 2023. Это сверка с чек-листами, а не сертификация: «не проверялось» не значит «пройдено».
Границы аудита
Входит
- Письменно согласованный объём: системы, домены, окружения
- Ручной обзор кода и архитектуры, инструменты — как вспомогательные
- Проверка ролей и доступа к чужим данным в пределах объёма
- Секреты, зависимости и конфигурация окружений
- База данных, миграции, бэкапы
- Тесты критических сценариев, CI/CD и откат
- Отчёт в двух уровнях: для владельца и для команды
- Приоритеты и roadmap исправлений
Не входит без отдельного соглашения
- Тест на проникновение и эксплуатация уязвимостей
- Сертификация и заключение о соответствии стандарту
- Обещание, что уязвимостей больше нет
- Постоянный мониторинг продукта
- Исправление найденного и всего технического долга
- Нагрузочные и активные проверки production
- Юридическая и финансовая оценка сделки
Исправления — отдельный договор с InterLAB или работа любой другой команды по отчёту.
Как безопасно передать доступ
Форма на сайте собирает только описание задачи. Всё остальное — после NDA и согласования объёма.
- 01
Через форму — только бриф
Не присылайте исходный код, пароли, ключи и токены через форму сайта или мессенджер. Опишите продукт и что беспокоит — этого достаточно для первой оценки.
- 02
NDA и объём до доступа
NDA — по вашему шаблону или шаблону InterLAB. До доступа фиксируем объём проверки, роль InterLAB и контакт для связи с вашей стороны.
- 03
Отдельный доступ только на чтение
Пригласите отдельную учётную запись с правами только на чтение репозитория, по возможности временную. Общие логины и пароли не нужны.
- 04
Без данных реальных клиентов
Для аудита достаточно схемы базы, тестового стенда или обезличенной копии. Активные проверки работающей системы — только с письменного согласия и в оговорённом объёме.
- 05
Отчёт без секретов
Ключи, приватные адреса и персональные данные вычищаются из доказательств. Отчёт передаём по согласованному каналу, без публичных ссылок.
- 06
Отзыв доступа
После передачи отчёта вы отзываете выданные права, и мы сверяем это вместе.
Конкретный способ передачи и срок хранения материалов определяются договором.
Пример результата: отчёт в двух уровнях
Сверху — резюме для владельца: что важно для бизнеса и в каком порядке. Ниже — технические находки для команды; каждую можно раскрыть. Продукт вымышленный.
Резюме для владельца
- Объект: вымышленный веб-сервис B2B-заказов — Next.js, Node.js API, PostgreSQL. Объём: API, роли, база данных, сборка и релиз; мобильное приложение и инфраструктура хостинга — вне объёма.
- Главный риск: клиент одной компании может открыть заказы другой, подставив номер заказа в запрос (F-01). Исправление точечное — до привлечения новых клиентов.
- Бэкапы базы настроены, но восстановление ни разу не проверялось: сколько займёт простой при сбое, неизвестно (F-03).
- Переписывать архитектуру не нужно: границы модулей в целом разумные, долг сосредоточен в расчёте цен (F-04).
- Порядок: F-01 и F-02 — до следующего релиза, F-03 — следом, F-04 и F-05 — в плане следующего этапа.
F-01HIGHAPI отдаёт заказ по номеру, не проверяя, чей онАвторизация · API1:2023
- Что наблюдали
- Маршрут GET /api/orders/:id проверяет, что пользователь вошёл в систему, но не сверяет компанию заказа с компанией пользователя.
- Доказательство
- src/api/orders/get.ts, строки 18–34, коммит a1b2c3d (вымышленные). Воспроизведено на тестовом стенде двумя тестовыми учётными записями разных компаний.
- Влияние на бизнес
- Клиенты видят чужие заказы: состав, цены, адреса доставки. Договорной и репутационный риск.
- Рекомендация
- Проверять владельца объекта на сервере во всех маршрутах с идентификатором — общей функцией; добавить интеграционный тест «чужой заказ → 404».
- Уверенность · воспроизведение
- HIGH · CONFIRMED
- Приоритет · трудоёмкость
- P1 — до следующего релиза · S
- Ограничения
- Полностью проверены маршруты заказов и счетов; остальные маршруты с идентификаторами — по выборке, рекомендована полная инвентаризация.
F-02HIGHКлюч подписи сессий общий для staging и production и лежит в истории gitСекреты и окружения
- Что наблюдали
- Файл .env.production когда-то был закоммичен и затем удалён, но остался в истории репозитория. Staging и production используют один и тот же ключ подписи сессий.
- Доказательство
- История git, коммит e4f5a6b (вымышленный); значение ключа в отчёте скрыто. Совпадение ключей — по конфигурации окружений, предоставленной командой.
- Влияние на бизнес
- Любой, у кого был доступ к репозиторию, включая бывших подрядчиков, теоретически может подделать сессию в production.
- Рекомендация
- Перевыпустить ключ, развести секреты по окружениям, хранить их в менеджере секретов платформы; добавить в CI проверку на секреты в коммитах.
- Уверенность · воспроизведение
- HIGH · INDICATED
- Приоритет · трудоёмкость
- P1 — до следующего релиза · S
- Ограничения
- Подделку сессии в production не проверяли: активные проверки production вне объёма. Вывод сделан по конфигурации.
F-03MEDIUMВосстановление из бэкапа ни разу не проверялосьДанные и восстановление
- Что наблюдали
- Ежедневные снимки базы настроены у провайдера. Описанной процедуры восстановления и записи о пробном восстановлении нет.
- Доказательство
- Настройки резервного копирования (снимок экрана без идентификаторов), разговор с командой, отсутствие инструкции в репозитории.
- Влияние на бизнес
- При сбое или ошибочной миграции неизвестно, сколько продлится простой и какой объём данных будет потерян.
- Рекомендация
- Провести пробное восстановление на отдельный стенд, записать шаги и фактическое время, повторять по расписанию.
- Уверенность · воспроизведение
- MEDIUM · NOT_TESTED
- Приоритет · трудоёмкость
- P2 · S–M
- Ограничения
- Восстановление не выполнялось: доступа к консоли провайдера в рамках объёма не было.
F-04MEDIUMРасчёт цены продублирован в трёх местах и уже расходитсяАрхитектура
- Что наблюдали
- Скидки считаются в API, в корзине на фронтенде и при формировании счёта. Для оптовых скидок две копии дают разный результат.
- Доказательство
- pricing.ts, cart/total.tsx, invoices/build.ts (вымышленные пути); расхождение показано тестовым примером.
- Влияние на бизнес
- Сумма в корзине может не совпасть со счётом; каждое изменение тарифов требует правки трёх мест.
- Рекомендация
- Оставить единственный расчёт на сервере, фронтенд — только отображение; закрыть граничные скидки тестами.
- Уверенность · воспроизведение
- HIGH · CONFIRMED
- Приоритет · трудоёмкость
- P2 · M
- Ограничения
- Проверены сценарии розничной и оптовой скидки; промокоды — вне объёма.
F-05MEDIUMГлавный сценарий не покрыт тестами, релиз выкладывается вручнуюТесты и релизы
- Что наблюдали
- Тесты есть, но относятся к утилитам; сценарий «создать заказ → оплатить → получить счёт» не покрыт. Выкладка — ручной скрипт с компьютера одного разработчика.
- Доказательство
- Каталог tests/ и отчёт покрытия, скрипт deploy.sh (вымышленные); CI запускает только линтер.
- Влияние на бизнес
- Поломки главного сценария первыми находят клиенты; релиз и откат зависят от одного человека.
- Рекомендация
- Добавить e2e-тест главного сценария, перенести выкладку в CI с возможностью отката, описать процедуру релиза.
- Уверенность · воспроизведение
- HIGH · CONFIRMED
- Приоритет · трудоёмкость
- P2 · M
- Ограничения
- Нагрузочное поведение не оценивалось.
Демонстрационный образец. Компания, продукт, код, пути к файлам и коммиты вымышлены. Серьёзность (severity) — последствия с учётом вероятности; уверенность (confidence) — насколько доказан факт. S / M / L — относительный класс трудоёмкости, а не оценка в часах.
Что ещё посмотреть
Как устроен аудит
- 01
Бриф
Что беспокоит бизнес и какие решения впереди: рост, смена подрядчика, сделка. Бриф — без кода и секретов. Оценку объёма и стоимости даём после брифа.
- 02
NDA и доступ
NDA по вашему шаблону или нашему. Доступ к репозиторию — только на чтение, отдельной учётной записью.
- 03
Объём
Письменно фиксируем системы, домены и окружения, допустимые методы и то, что остаётся вне проверки.
- 04
Диагностика
Ручной обзор по доменам, инструменты — в помощь. Фиксируем факты: файл и строки, конфигурацию, воспроизводимую проверку.
- 05
Отчёт
Резюме для владельца и находки для команды: серьёзность и уверенность — раздельно, ограничения проверки — открыто.
- 06
Приоритеты и roadmap
Порядок работ: риск для пользователей и бизнеса → зависимости → трудоёмкость. План самодостаточен — выполнить его может любая команда.
Оценим проект до старта разработки
Опишите задачу в форме ниже — ответим в течение рабочего часа и предложим следующий шаг: созвон, разбор или оценку.
Что именно проверяем
Систему смотрим по доменам в согласованном объёме: от модели доступа и базы данных до процесса релизов. Инструменты — вспомогательные: сканер зависимостей находит известные уязвимые версии, но не ошибки бизнес-логики, авторизации и архитектуры. Их находит ручной разбор.
- Архитектура и API
- Авторизация и роли
- Секреты и зависимости
- Базы данных и миграции
- Бэкапы и восстановление
- Тесты критических сценариев
- CI/CD и откат
- Логи и мониторинг
Аудит интеграций
Отдельно проверяем связки с внешними системами: платежи, 1С, Kaspi, CRM, мессенджеры. Ошибки на стыках — частая причина потерянных заказов и расхождений в данных, поэтому интеграции разбираем на уровне контрактов API и обработки сбоев.
1С, Kaspi, Платёжные сервисы, AmoCRM, Bitrix24, WhatsApp, Telegram, REST API
Пример разбора
Вопросы про технический аудит
Стоимость определяется после брифа и согласования объёма: лендинг, веб-приложение и ERP с десятком интеграций — разный объём работы. Оценку срока и стоимости даём после брифа.
Аудит — обзор кода, архитектуры и конфигурации с доказательствами в согласованном объёме. Тест на проникновение — отдельная работа с письменными правилами взаимодействия, где уязвимости пытаются эксплуатировать. В аудит он не входит, и сейчас InterLAB не предлагает его как услугу; отчёт аудита поможет сузить объём такой проверки, если она понадобится.
Отчёт в двух уровнях: резюме для владельца — главные риски и порядок действий, и технические находки для команды — с доказательствами, рекомендациями и ограничениями проверки. Плюс roadmap исправлений. Отчёт самодостаточен: работать по нему может ваша команда или любой другой подрядчик.
Нет. Аудит показывает риски, найденные в проверенном объёме, и прямо называет то, что не проверялось. Он не заменяет сертификацию и не подтверждает соответствие стандарту: OWASP ASVS и API Security Top 10 используем как ориентир для проверки, а не как сертификат.
Частично: производительность, внешний контур и инфраструктуру можно оценить снаружи. Но architecture review и code review требуют доступа к репозиторию. Работаем по NDA, доступ — только на чтение. Код, пароли и ключи не присылайте через форму или мессенджер: порядок передачи согласуем после брифа.
Да, если впереди рост: новые функции, увеличение нагрузки, интеграции или смена команды. Аудит до масштабирования дешевле разбора инцидентов после.
Нет. Аудит — самостоятельная услуга с законченным результатом: отчёт и план. Выполнять план можно своими силами или с другой командой; если нужно, исправления и развитие продукта берём на себя отдельным договором.
Разборы по теме в блоге
Смежные направления
Обсудить аудит
Опишите продукт и что вас беспокоит — без кода, паролей и ключей. Предложим уровень проверки и объём, а оценку срока и стоимости дадим после брифа.
- Первый короткий разговор бесплатный — выбираем формат работы
- NDA — по вашему или нашему шаблону
- Стоимость — после брифа и согласования объёма