Почему разработчик ≠ тестировщик безопасности (и почему антивирус вас не спасёт)

«У нас сильные разработчики, они всё проверяют».
«Стоит фаервол, антивирус, VPN – мы под защитой».
«Если бы в коде были проблемы, мы бы уже заметили».

Если вы работаете в IT-компании, продуктовой или аутсорсинговой, скорее всего, эти аргументы звучали в переговорах или при планировании бюджета. Они кажутся логичными. Но на практике это ловушка уверенности, из которой растут утечки данных, взломанные админки и миллионные убытки. Системная защита и тестирование безопасности – это разные игроки на поле обороны.

Продолжая нашу серию постов о тестировании безопасности, разбираем, почему нельзя заменять тестировщика безопасности разработчиком, чем отличается Firewall от реальной проверки защиты продукта и в конце статьи делимся гайдом для ИТ-руководителей «Нужно ли вашему продукту тестирование безопасности?»

Разработчик – не тот, кто ломает

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

Разработчик создаёт функциональный, а иногда и очень красивый код. Но у него другой фокус. Он создаёт то, что должно работать, а не ищет, как это взломать. Любое приложение можно сломать, если знать, куда смотреть.

Даже если вы используете антивирус, фаервол, WAF (Web Application Firewall), это не обнаружит уязвимость в логике разрешений или провал в проверке аутентификации.

Тестировщик безопасности (или security-аналитик) имитирует настоящих Malware («вредоносное ПО») и ломает систему. У него другие цели, другие инструменты (например, Burp Suite, OWASP ZAP, Nikto, Metasploit) и даже другой мировой взгляд. Его задача – не доверять, а проверять. Точно так же, как это сделает Malware. Он ищет, где правила можно обойти, проверяет, как система реагирует на «неправильные» сценарии, симулирует действия злоумышленника: от подбора паролей до попытки доступа к чужим данным.

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

Прежде чем читать дальше, проверьте себя. Всего 7 вопросов. Пройдите мини-тест 😉

Вы понимаете, чем фаервол отличается от антивируса?

1. Что делает фаервол?
а) Лечит заражённые файлы
б) Контролирует, кто и как подключается к системе
в) Удаляет вирусы
г) Проверяет USB-носители

2. А что делает антивирус?
а) Блокирует IP-адреса и порты
б) Защищает от DDoS
в) Ищет и удаляет вредоносное ПО
г) Предотвращает фишинг в браузере

3. Если вирус уже попал в систему, кто его поймает?
а) Фаервол
б) Антивирус
в) Только DevOps
г) Никто, если у вас нет тестирования безопасности

4. Фаервол и антивирус – это одно и то же?
а) Да, просто разные названия
б) Нет, это два уровня защиты
в) Антивирус – это модуль фаервола
г) Главное – чтобы хоть что-то было

5. Вы настроили фаервол, но забыли про антивирус. Что может пойти не так?
а) Ничего – фаервол и так всё ловит
б) Вирус залетит через флешку или почту, и фаервол его не заметит
в) Компьютер будет работать медленнее
г) В браузере пропадут все закладки

6. Представьте, что ваша сеть – это клуб. Кто такой фаервол?
а) Ди-джей, который качает треки
б) Бармен, разливающий пакеты данных
в) Фейс-контроль, который решает, кого пустить внутрь
г) Wi-Fi

7. Ваш backend общается с внешними сервисами через API. Что может сделать фаервол на этом уровне?
а) Оценить, безопасна ли бизнес-логика в ответах API
б) Заблокировать подозрительные запросы по IP, порту или URL-паттерну
в) Провести нагрузочное тестирование API на лету
г) Автоматически переписать незащищённый код

Антивирус и фаервол – вовсе не панацея

На первый взгляд фаервол и антивирус могут казаться «одной бандой по защите», но на деле они решают разные задачи и работают по-разному. Если ваш сайт, CRM или маркетплейс взломают, 99% вероятности, что это произойдёт не через вирус и не через торчащий порт.

📌 Антивирус защищает устройство от известных вредоносных программ. Если ты случайно скачал заражённый файл, антивирус попытается его поймать и нейтрализовать. Но он не контролирует сетевые соединения, как фаервол.
📌 Фаервол (Firewall) фильтрует сетевой трафик – кто может подключиться и куда. Фаервол может не дать вирусу войти в систему по подозрительному соединению. Но если вирус уже внутри — фаервол его не заметит и не удалит.

Firewall (фаервол) — система защиты, которая контролирует входящий и исходящий трафик в сети на основе заданных правил безопасности. Проще говоря, это охранник на входе: он решает, кого пускать внутрь (в вашу сеть или компьютер), а кого — нет.
Есть два основных типа фаерволов:
Сетевые фаерволы стоят на границе сети (например, между офисной сетью и интернетом) и фильтруют трафик по IP-адресам, портам, протоколам и т. д.
Локальные фаерволы устанавливаются на отдельные устройства (например, Windows Firewall), чтобы фильтровать трафик только на этом компьютере.

Они не проверяют:

• можно ли получить доступ к чужому аккаунту через ID в URL;
• уязвимы ли API-эндпоинты к подмене токенов;
• работают ли ограничения ролей в админке;
• может ли бот брутфорсить логины без капчи.

Это всё не «плохие» инструменты. Просто у них другая задача. А значит, надёжность вашего продукта – всё ещё открытый вопрос. Такие средства защищают от известных угроз. Но если у вас ошибка в API, сложная иньекция в GraphQL, нарушения в access control или ошибки в логике приложения – они будут полезны как замочек на дверь, когда стены стеклянные.
Фаервол – ваша система контрольно-пропускных пунктов. Антивирус – служба внутренней безопасности. Оба нужны. Особенно в корпоративных сетях, где одно без другого – как двери без замков или замки без дверей.

Что может выявить тестирование безопасности?

🛡️ Тестирование безопасности – это не защита «по кругу», а проверка «что внутри сломано». Оно нужно, когда:

• вы обновили сайт, и пошёл трафик (или платежи);
• продукт работает с персональными данными (ФЗ-152, GDPR);
• ваш заказчик – банк, госкорпорация или маркетплейс, у которого свои требования;
• проект вырос, но проверок по безопасности ни разу не было.

В среднем один серьёзный инцидент обходится бизнесу в 1,5–3 млн рублей. Потери — это не только деньги. Это потеря доверия клиентов, остановка процессов и испорченная репутация, которую потом приходится «отмывать» годами.

Тестирование безопасности помогает не просто найти баг, оно показывает, где вас уже «ждут»:

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

Это то, что ни один фаервол не отловит. А автоматизированные сканеры (например, OWASP ZAP или Burp Suite) могут не увидеть, если баг кроется в логике бизнес-процесса.

Мы уже писали об инструментах обеспечения безопасности приложений и что выбор зависит от целей бизнеса и зрелости проекта. Коротко повторим:

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

Все еще мучает вопрос «Так зачем, если уже есть фаервол?» да потому что антивирусы и фаерволы хороши, когда к вам ломятся в лоб. Но они:

• не знают о логике вашего приложения. Они не понимают, что в поле «номер карты» можно засунуть скрипт, и он выполнится.
• не видят, что админка лежит по адресу /admin123, и туда можно войти с простым паролем.
• не проверяют, что база данных отдаёт по запросу все e-mail клиентов.

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

Важный вывод

Защита периметра – это хорошо. Но если в системе есть дыры, их должен найти не злоумышленник, а вы. Тестирование безопасности – возможность заранее увидеть, где бизнес может потерять деньги, доверие и клиентов. И да, антивирус – отлично. Но он не увидит, что в вашем API можно вытянуть данные чужого пользователя, просто добавив ?id=2.

Если вы не уверены, что у вас всё безопасно — значит, пора это проверить

Частый кейс «У нас нет бюджета на безопасность»

Справедливо. У многих стартапов, особенно на стадии MVP, реально нет лишних денег. Но тут вопрос не в бюджете, а в приоритетах.

🔸 Не тестировать вообще – значит рискнуть всем.
🔸 Проверить хотя бы основные сценарии – это уже защита. Иногда достаточно одного тестирования вручную, чтобы закрыть критичную дыру.

Пример с проекта. Клиент долго откладывал тестирование. А потом пришёл с жалобой, что из CRM клиенты скачивали друг другу документы. Два дня ушло на анализ, ещё три – на исправления, потом – уведомления, компенсации, юристы…
Цена вопроса? Несколько сотен тысяч рублей.
Цена базового теста? 40–70 тысяч.

Вывод. Даже если нет бюджета на комплексный аудит с DevSecOps, сканерами и CI/CD, можно протестировать ключевые сценарии. И это уже на порядок безопаснее, чем слепая вера в «у нас же всё по SSL».

Что делать дальше?

Если вы запускаете новый сервис, вносите критичные изменения в код, работаете с API, платёжками, личными кабинетами или просто не уверены, где может протечь, 👉 тогда начните с диагностики.

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

И помните:
🧨 Самый дорогой баг – тот, о котором вы узнаёте из новостей.
🛠 Самая простая защита – тестирование. Не разработчиком, не фаерволом, а специалистом, который умеет ломать. Чтобы вы могли не бояться.