Что такое тестирование безопасности в разработке ПО?

Да ты посмотри, что творят-то! Безопасность тестируют, говоришь? Ну это ж святое дело, блядь! А то наделают тут говнокода, а потом сиди и чеши репу — откуда данные уплыли, кто сервак положил и почему твою фотку с корпоратива теперь на порносайте рекламируют.

Так, слушай сюда, расписываю по полочкам, как у нормальных людей это делается, а не как у мартышлюшек, которые на кнопки тыкают.

Тестирование безопасности — это, по сути, ты берешь свою систему, садишься в позу злобного хацкера с тремя айпишниками в голове и начинаешь методично искать, куда бы воткнуть свою виртуальную отвертку, чтобы всё развалилось или уплыло. Цель — найти дыры, пока это не сделал кто-то другой, у кого цели похуистичнее. Всё крутится вокруг этой вашей тройки — CIA: конфиденциальность (чтобы не светилось), целостность (чтобы не поправили) и доступность (чтобы не легло). Короче, чтобы не было пиздеца.

Как это, блядь, делают?

• SAST (Статический анализ) — это когда ты берешь исходники и просто ебёшь мозг тексту, не запуская ни хуя. Сидишь, читаешь код, как книгу, и ищешь: "Ага, тут чувак строку от пользователя взял и прямо в запрос сунул, пидарас шерстяной!". Инструменты типа SonarQube — они как грамотный зануда, который каждую строчку комментирует: "Э, бошка думай, тут уязвимость, дебил!".

• DAST (Динамический анализ) — а вот это уже веселее. Ты запускаешь приложение и начинаешь в него тыкать палкой со всех сторон, как в спящего медведя. Шлешь ему левые запросы, кривые данные, пытаешься сломать форму логина. Инструменты вроде OWASP ZAP — они как автоматизированный гопник, который ко всем дверям подряд подходит и дергает ручку: "Открывай, ебта!".

• Тестирование на проникновение (Pentest) — это высший пилотаж, блядь. Тут уже не просто тыкают палкой, а реально пытаются взломать, как в кино, только без черных худи и злого смеха. Нанимают спецов (или сам становишься им), которые думают, как настоящий атакующий: социнженерия, поиск забытых портов, подбор паролей — весь спектр, сука. Цель — не просто баг найти, а добраться до "короны", то есть до самых жирных данных.

Вот смотри, классика жанра — SQL-инъекция:

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

SELECT * FROM users WHERE username = 'admin' OR '1'='1' --' AND password = '...';

Видишь эту пакость? Пользователь ввел не admin, а admin' OR '1'='1. Кавычка ломает строку, OR '1'='1' — это всегда правда, а -- комментирует всё остальное, включая проверку пароля. И всё, блядь, ты в системе! Овердохуища уязвимость, а делается из-за лени и кривых рук.

И как, спрашивается, не облажаться?

1. Валидируй и чисть всё, что приходит от пользователя. Представь, что каждый юзер — это обоссаный бомж, который пытается тебе в рот насрать. Не верь ни единому символу.
2. Используй подготовленные выражения (parameterized queries) или ORM. Это когда ты не лепишь данные в запрос как попало, а даешь БД понять: "Вот, дружок, это — шаблон запроса, а вот это — просто данные, которые туда нужно аккуратно положить". База сама всё разъебает и не даст инъекции пролезть.
3. Сканируй зависимости. Ты же не сам весь код пишешь? Библиотеки тянёшь? Так вот, в них тоже могут быть дыры. Нужно регулярно гонять сканеры (типа SCA), которые орут: "Э, сабака сука, в этой библиотеке дыра, обнови, пока тебя не взломали!".
4. Принцип наименьших привилегий. Это гениально просто. Если твоему сервису нужно только читать из базы — дай ему права только на чтение, а не на всё подряд. Чтобы даже если его взломают, ущерб был минимальный, а не "ой, бля, он всю базу дропнул".

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