Утопали в дефектах, пока собирали «единое окно»

«У нас было два пакета findings SAST’а, семьдесят пять CVE с критичностью — Critical, пять дублей одной и той же CVE в разных сервисах, пол солонки false positive и целая россыпь уязвимостей всех сортов и расцветок: SQLi, XSS, SSRF, RCE, IDOR, утекшие секреты, misconfigs в Kubernetes, написанные человеком, который явно не планировал дожить до аудита. Кроме того, у нас были изменения, сгенерированные AI-ассистентами, забытые исключения в проверках доступа, временные обходные решения, давно ставшие частью архитектуры, два отчета пентеста, тысячи задач и дашборд, который краснел так, будто видел все наши будущие инциденты сразу. Не то чтобы это был необходимый запас для управления безопасностью приложений, но если уж ты решил строить ASPM через агрегацию всего подряд, рано или поздно ты оказываешься именно в такой машине — на полной скорости, без карты, с разработчиками на заднем сидении, которые только и спрашивают: “Что из этого реально надо исправлять?”». Всем привет! Меня зовут Артем Пузанков, я руководитель отдела консалтинга безопасной разработки в Бастионе. Сегодня хотелось бы порефлексировать с вами про управление состоянием безопасности приложений, ASPM, AI-generated код и AppSec. Эта статья о том, почему будущее ASPM не в том, чтобы собрать все дефекты в «единое окно», а в том, чтобы сопоставить обнаруженные находки, проверить достижимость и отделить реальные угрозы от шума (читай технического долга).

https://habr.com/ru/companies/bastion/articles/1031884/

#aspm #devsecops #application_security #ssdlc #безопасная_разработка #информационная_безопасность #AI_в_кибербезопасности #управление_уязвимостями #безопасность_приложений

Топ техник атак на веб-приложения — 2025 и как разработчику защищаться от нетривиальных уязвимостей

В ежегодный рейтинг Top 10 web hacking techniques попадают материалы об инновациях в области поиска и эксплуатации уязвимостей. Некоторые из них показывают целые категории проблем и новые методы атак. В этой статье хочу рассказать о самых интересных исследованиях из топа прошедшего года, а заодно поделиться собственными идеями о том, как защититься от описанных уязвимостей.

https://habr.com/ru/companies/sourcecraft/articles/1026090/

#безопасность_вебприложений #application_security #уязвимости

Никакого супергеройства на проектах. Гайд, как сделать безопасность частью разработки

Привет! С вами снова Александр Симоненко, операционный директор Xilant . В первой статье трилогии о бизнес-требованиях мы разобрали, как неточные формулировки в требованиях создают уязвимости, а во второй — методики безопасных требований: INVEST, SMART, What-If и misuse-cases. В заключительной статье поговорим о том, как встроить безопасность в процесс разработки, чтобы эти методики работали не на бумаге, а в жизни команды.

https://habr.com/ru/companies/technokratos/articles/974506/

#информационная_безопасность #appsec #application_security #безопасная_разработка #безопасные_требования #кибербез #кибербезопасность

Основы безопасности веб-приложений: с нуля до предупреждения атаки

Меня зовут Саша Чуфистов, я AppSec BP в Альфа-Банке. Сегодня я попробую ответить на вопрос «Как выглядит веб-приложение с точки зрения злоумышленника». Для этого мы используем заведомо уязвимое приложение , на примере которого покажу, как выглядят веб-сайты глазами атакующего: где искать точки входа, какие инструменты использовать для разведки и атаки, какие уязвимости можно повстречать и как их обнаружить в исходном коде. Ранее данный материал был представлен на воркшопе в рамках конференции Positive Hack Days — теперь он адаптирован и дополнен для более широкой аудитории, которая начинает интересоваться темой безопасной разработки. Вы можете развернуть учебную среду на своей машине, повторять команды и проверять результаты их выполнения на вашем экземпляре приложения. Для демонстрации техник разведки и инструментов я использую общеизвестные уязвимые ресурсы: demo.testfire и testphp.vulnweb . Их URL я положил в workshop/urls.txt в репозитории проекта. Дисклеймер : статья носит ознакомительный характер, и любые попытки злоупотребления данной информацией незаконны и могут повлечь за собой уголовное преследование в соответствии со статьями 272 и 273 УК РФ.

https://habr.com/ru/companies/alfa/articles/967226/

#application_security #приожение #кибербезопасность #информационная_безопасность #appsec

Делаем требования безопасными с помощью методик INVEST, SMART, What-If и misuse cases

Привет! На связи снова Саша Симоненко, операционный директор Xilant . Сегодня разбираем конкретные методики написания безопасных требований: INVEST, SMART, What-If и misuse cases. Чтобы быть в контексте, зачем они нужны и какую проблему решают, рекомендую начать с первой части трилогии — о том, как неточные формулировки становятся уязвимостями и где в SDLC теряется безопасность.

https://habr.com/ru/companies/technokratos/articles/968428/

#информационная_безопасность #требования_к_разработке #appsec #application_security #безопасная_разработка #безопасная_разработка_приложений

Баг не в коде, а в словах: как требование превращается в уязвимость

Всем привет! Меня зовут Саша Симоненко, и я операционный директор кибербез компании Xilant . Эта статья родилась из моего сентябрьского выступления на конференции KazHackStan 2025 в Алматы, где рассказывал, как качественные бизнес-требования помогают избежать проблем с безопасностью. В первой части статьи разберем, как неточные формулировки превращаются в реальные инциденты и где в процессе теряется безопасность.

https://habr.com/ru/companies/technokratos/articles/963252/

#информационная_безопасность #требования_к_разработке #appsec #application_security #безопасная_разработка #безопасная_разработка_приложений

Тренды безопасной разработки: разбираем BSIMM 15 и сравниваем топ-10 активностей с предыдущим отчетом

Процессы безопасной разработки — это не просто набор инструментов для проверки кода. Основная концепция в том, чтобы все процессы работали как единый механизм, а безопасность была не просто дополнением, а неотъемлемой частью разработки. Фреймворк Building Security in Maturity Model (BSIMM) предлагает смотреть на процессы безопасной разработки с точки зрения зрелости, как на измеримую систему действий и результатов, а не просто как на чек‑лист практик. В этом году Synopsys не обделил нас новым отчетом и представил BSIMM 15, который мы с вами разберем. Не буду углубляться, что такое BSIMM и как его применять на практике, об этом вы можете прочесть в статье про BSIMM 14 , но стоит отметить, что BSIMM дает ежегодную оценку применимости различных практик. На этом и сосредоточимся, посмотрим, какие появились новые активности и какие сейчас в тренде.

https://habr.com/ru/companies/pt/articles/956682/

#bsimm #безопасная_разработка #appsec #application_security #фреймворки #методология

Как не потерять свои контейнеры у себя в инфраструктуре?

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

https://habr.com/ru/companies/pt/articles/936868/

#container_security #appsec #application_security #devsecops

Безопасная разработка как игра в Dungeons & Dragons

Привет! 👋 Меня зовут Алина. Я маркетолог и давно работаю в ИТ, но с безопасной разработкой познакомилась только когда пришла в продуктовую студию по кибербезопасности Axel PRO. И знаете, эта область заинтересовала меня в процессе работы. А еще у меня есть интересное хобби — я люблю играть в Dungeons&Dragons, иначе говоря — ДНД 🎭. И вот что я заметила: процесс разработки ПО очень похож на эту игру. Сейчас расскажу, почему. Представьте, что разработка ПО — это ваша игра в Dungeons&Dragons. Вы собрали отряд: разработчиков, тестировщиков, продакт‑менеджеров, выбрали для них роли и отправились в приключение — создавать крутой продукт 🚀. Но вот загвоздка: пока вы исследуете подземелья (пишете код) 🏰, на каждом шагу вас поджидает разная нечисть — уязвимости‑ловушки 🕳️, баги‑драконы 🐉 и орки‑ошибки конфигурации 🪓. Если вы не взяли с собой защитные свитки с политиками и шаблонами безопасности 📜, зелья исправления уязвимостей 🧪 и доспехи из безопасных практик 🛡️ — ваша команда рискует быстро проиграть. Собираем команду Как и в мире ДНД, в безопасной разработке у каждого участника команды есть своя уникальная роль и задачи. Например: ⚔️ Бэкенд‑разработчик — это воин, который создает и защищает код, отражая атаки. 🧙‍♂️ Тестировщик — маг, исследующий систему с помощью «заклинаний» тестов, чтобы найти слабые места. ⛩️ Администратор инфраструктуры — жрец, поддерживающий стабильность и безопасность серверов и окружения 🎶 HR‑менеджеры и менеджеры проекта — подобно бардам, поддерживают коммуникацию и помогают команде достигать общих целей.

https://habr.com/ru/articles/925524/

#appsec #devsecops #информационная_безопасность #безопасная_разработка #application_security #dungeons_and_dragons