#безопасная_разработка — Public Fediverse posts

ИИ-агент почти без ИИ: в моём сметчике нейросеть не посчитала ни рубля

В продукте, который называется «ИИ-сметчик», нейросеть пока не посчитала ни рубля. Компания по ремонту и отделке квартир в Москве дала мне пять рабочих смет. По ним система выдала 310 замечаний (прогоны 16–21.08.2026). Самая дорогая находка — общий итог одной сметы занижен на 515 786 ₽ . Это занижение нашлось ещё при обследовании смет перед ТЗ, а правило под него я написал потом, так что здесь заслуга внимательного чтения, а не кода. Код интереснее другим: 51 подтверждённое замечание он выдал сверх эталонного списка ошибок, составленного при том обследовании. В списке их не было. Все 310 замечаний выдаёт код с правилами. ИИ-слой написан и покрыт тестами на заглушке, но на живой модели ещё не запускался: ключа доступа нет, платформу выбирает заказчик. Рабочую версию я ему передал, и она обходится без интернета. Во второй системе, конфигураторе замеров для сервиса, который готовит чертежи стеклянных душевых кабин под заказ, нейросети нет совсем. Модель в обоих проектах работала у меня в разработке: писала код, разбирала Excel заказчика, сверяла замечания со строками смет. В сам продукт я пускаю её только туда, где без неё нельзя.

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

#excel #ремонт #смета #безопасная_разработка #llm #ииагент #tool_use #сезон_код_будущего #output_guardrails #детерминированные_проверки

Кто взломает ваш пайплайн? Моделирование угроз, о которых все забывают. Часть 2

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

https://habr.com/ru/companies/ussc/articles/1088890/

#пайплайн #моделирование_угроз #моделирование_угроз_иб #безопасная_разработка #devsecops

Вайбкодинг: запретить нельзя возглавить

Четыре месяца назад мы разрешили коллегам без инженерного бэкграунда выкатывать в прод приложения, которые им пишет ИИ-агент. После этого получили более 260 проектов от 150 человек, и весь этот код не читал ни один программист. Дальше о том, как устроена наша песочница, что мы узнали за эти четыре месяца, где ошибались и что из этого получилось.

https://habr.com/ru/companies/flowwow/articles/1088660/

#вайбкодинг #llm #ииагенты #управление_разработкой #песочница #безопасность #безопасная_разработка #docker #автоматизация #генерация_кода

Одна строка, открытый порт и взломанный сервер: цена вайбкодинга

У меня есть небольшой пет-проект. Telegram-бот для тренировки устного счёта. Код писал Claude Code, я лишь задавал направление и проверял результат. На том же сервере параллельно работали и другие проекты. Один из них следил за нагрузкой сервера и присылал мне уведомления. Первое сообщение я пропустил, ведь сервер не самый мощный, проектов много и решил, что он просто не справляется. Но уведомления приходили второй день, а потом и на третий. Я останавливал нагруженные процессы и перезапускал сервисы. Нагрузка падала, но вскоре снова росла. На третий день я заметил в docker-compose одного из проектов опубликованный порт PostgreSQL. База была доступна для подключений из интернета. Сервер действительно взломали, но установить точную точку входа я не смог, нужных логов не сохранилось. Ошибка была моя. Я проверил, что бот запускается и отвечает, но не проверил, кому доступна база и нужен ли ей внешний порт. Claude Code писал код по моим указаниям, а ответственность за проверку результата оставалась на мне. Дальше разберём, что можно восстановить по косвенным признакам и как не допустить такую же ошибку при разработке собственных продуктов. Читаем дальше

https://habr.com/ru/companies/timeweb/articles/1085370/

#безопасная_разработка #аудит_безопасности #безопасность_кода #сезон_код_будущего #timeweb_статьи #telegram #ai #бот

Поиски «швейцарского ножа» или Обзор инструментов моделирования угроз

Привет, Хабр! Меня зовут Антон Станкевичус, я старший специалист по тестированию безопасности программного обеспечения в компании «Гарда». Моделирование угроз (Threat modeling) — уже давно не задача из серии «если дойдут руки», а важное требование по безопасности для российских разработчиков ПО. Мы тоже подходим к такой работе максимально тщательно. Недавно я выбирал инструмент для автоматизации Threat modeling. Было важно, чтобы он соответствовал ГОСТу по защите информации. Требовалось предоставить руководству обзор рынка и доступных решений, чтобы согласовать оптимальный вариант. Забегая вперед, Threat modeling редко выполняется единственным инструментом. Одни решения помогают формализовать архитектуру, другие — автоматически находить уязвимости, третьи удобно встраиваются в конвейер CI/CD. Для наглядности я решил не только сравнить между собой рассматриваемое ПО и подходы, но и оценить, насколько каждое из них соответствует требованиям регулятора, а также разложить их по функциональным группам. Итак, поехали!

https://habr.com/ru/companies/garda/articles/1085280/

#threat_modeling #моделирование_угроз #devsecops #безопасная_разработка #appsec #ГОСТ_Р_569392024

Кто взломает ваш пайплайн? Моделирование угроз, о которых все забывают. Часть 1

Представьте, что вы построили неприступную крепость. Стены из титана, рвы с акулами, а стража проходит проверку на полиграфе. Звучит надежно? Да. Только чертежи этой крепости были скомпрометированы еще на этапе проектирования, а ключи от ворот выдает стажер по первому требованию всем без разбора. В безопасной разработке мы часто совершаем похожую ошибку: фокусируемся на защите продукта (кода, его архитектуры и инфраструктуры), совершенно упуская из виду процесс его создания. Да, методологии вроде STRIDE или PASTA отлично отвечают на вопрос «Как взломают нашу систему?». Но что делать, если угроза кроется не в баге, а в том, как этот баг попал в релиз. Поэтому мы запускаем цикл статей, посвященных моделированию угроз для процессов разработки. В первом материале разберем, почему защиты кода недостаточно, где классический аудит достигает своих границ и как превратить общие рекомендации в точечный план действий. Без воды, с фокусом на системный подход.

https://habr.com/ru/companies/ussc/articles/1079214/

#development #моделирование_угроз #пайплайн_разработки #безопасная_разработка #shift_left #devsecops

Ловушка для собственного бэкенда: как заметить, что тебя уже взломали

У сервиса, который хранит ключи шифрования, есть клиент, которому он обязан верить. Это бэкенд приложения: он подписывает каждый запрос своим ключом, и подпись честно сходится. Теперь предположим, что бэкенд захвачен. Атакующий получает вместе с ним и ключ подписи, а значит выписывает себе совершенно валидные разрешения на любой документ. Все десять проверок при выдаче ключа проходят. Ни одна не заметит ничего необычного, потому что необычного и нет: пришёл доверенный клиент и попросил то, что имеет право просить. Эта статья про то, что делать в такой ситуации. Она вторая: в первой я разбирал, почему второй фактор, живущий в присланной сервером странице, защищает не то, что кажется. В комментариях там справедливо спросили: если захват одного сервера рушит всю схему, зачем вообще было городить разделение. Вот механизм, который на этот вопрос отвечает.

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

#honeytoken #обнаружение_вторжений #HMAC #модель_угроз #безопасная_разработка #honeypot

Летальное трио агентской разработки: как ИИ-агенты открывают доступ к инфраструктуре и что с этим делать

Привет, Хабр! Я Денис Макрушин, работаю в Яндексе, и вместе с командой SourceCraft Security строю платформу для безопасной агентской разработки, а в свободное время ищу уязвимости в ИИ-агентах и иногда рассказываю об исследованиях в своем блоге . Чем дольше этим занимаюсь, тем лучше вижу тенденцию: индустрия обсуждает, что агенты умеют делать, но реже говорит о том, какие решения и как проще внедрять, чтобы сделать агентскую инфраструктуру безопаснее. Вместе с моими коллегами Ратмиром Самархановым и Андреем Погирейчиком мы решили проверить гипотезу: “наши ИИ-агенты в разработке могут быть скомпрометированы и существуют простые средства для контроля их безопасности”. Расскажем о первых результатах.

https://habr.com/ru/companies/oleg-bunin/articles/1071908/

#ai_security #agentic_engineering #ai_red_teaming #ИИагенты #агентская_разработка #безопасность_ИИ #безопасная_разработка #LLM_security #prompt_injection #RAG_poisoning

Второй фактор, который жил в чужой странице: как я выбросил WebAuthn из своего сервиса ключей

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

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

#WebAuthn #конвертное_шифрование #модель_угроз #Argon2id #AESGCMSIV #шифрование_данных #двухфакторная_аутентификация #безопасная_разработка

Как внедрить требования к безопасной разработке кода: опыт Контур.Staffcop

Безопасная разработка для Контур.Staffcop (системы расследования инцидентов внутренней инфобезопасности) — это не отдельная проверка перед релизом, а процесс, который команда постепенно встраивает в работу с кодом. С одной стороны, это связано с требованиями регулятора и подготовкой продукта к сертификации. С другой — помогает находить уязвимости раньше, до того как код попадёт в общую ветку, пройдёт все стадии разработки и дойдёт до пользователя. В команде уже тестируют инструменты для разных видов анализа: статического, композиционного, динамического, фаззинга и поиска секретов. Один из первых подробно разобранных этапов — пилот статического анализатора кода .

https://habr.com/ru/companies/skbkontur/articles/1069664/

#staffcop #рбпо #безопасная_разработка #статический_анализ #композиционный_анализ #фаззинг #поиск_секретов #тестирование #pvs_studio #анализатор_кода

Как PVS-Studio улучшает качество embedded-проектов

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

https://habr.com/ru/companies/pvs-studio/articles/1066854/

#embedded #static_analysis #c++ #c #встраиваемые_системы #статический_анализ #статический_анализ_кода #программирование #безопасная_разработка #программирование_микроконтроллеров

Summ3r Of h4ck 2026: разбор заданий отборочного этапа

C 13 апреля по 10 мая был открыт приём заявок на стажировку Summ3r 0f h4ck 2026 . В этом году на обучающую программу в DSEC by Solar пытались попасть 225 человек – это в несколько раз больше, чем в предыдущие годы! В качестве испытаний в отборочном этапе нужно было решить 10 задач по практической информационной безопасности и пройти интервью. Спасибо всем, кто не только пользовался последними достижениями в области AI, но и активно работал над заданиями сам. Мы это очень ценим! Комментарий от технической команды Summ3r 0f h4ck 2026: « В этом году мы подобрали задания с упором на поиск уязвимостей в веб приложениях, аудиту корпоративной инфраструктуры и поиск уязвимостей в мобильном приложении. В одном из заданий кандидаты расследовали инцидент по логам HTTP-трафика: необходимо было понять, как приложение было взломано, и что смог получить атакующий. Для решения заданий не хватит вузовской программы — нужно активно интересоваться практической ИБ, решать задачи с CTF или лабы по типу Hack The Box. » На стажировку к нам попали 5 участников. Возможно, уже в скором времени они присоединятся к нашей команде. Мы покажем вам решение одного из тестовых заданий. Остальные решения вы можете найти

https://habr.com/ru/companies/dsec/articles/1065452/

#поиск_уязвимостей #vulnerability_research #bughunting #анализ_кода #безопасная_разработка #безопасность_веб_приложений #безопасность_мобильных_приложений #пентест #безопасность_инфраструктуры #active_directory

От Security Champion к инженерной культуре безопасности: как мы изменили подход к DevSecOps

Модель Security Champion многим кажется очевидной: если внутри команды появляется человек, который смотрит на продукт еще и с точки зрения безопасности, всем становится лучше. Но на деле путь от формального назначения до реально работающей роли гораздо длиннее и тернистее, чем кажется. Привет, Хабр! На связи Илья Шаров (@issharov), Head of DevSecOps, и Николай Лузгин, DevSecOps Lead из МТС Web Services. Мы тоже через это проходили и в какой-то момент пересмотрели весь подход. Если в прошлый раз мы рассказывали о пользе, ролях и о том, что стоит предусмотреть при внедрении Security Champion, то сегодня поделимся опытом трансформации: как сместили фокус на вовлеченность, развитие компетенций и естественное встраивание безопасности в повседневную работу команд. Читать дальше

https://habr.com/ru/companies/ru_mts/articles/1063844/

#security #security_champions #devsecops #безопасная_разработка #культура_разработки #инженерная_культура

Мост между SAST и фаззингом: как из сработки SAST получить подтверждённую уязвимость

Инструменты статического анализа (SAST) лишь подсвечивают вероятные уязвимости, генерируя гипотезы. Динамическое тестирование (DAST) и фаззинг, напротив, выявляют реальные сбои на работающем приложении и фиксируют вектор атаки, но не указывают на конкретную строку в исходниках. Традиционно эти два подхода существуют в изоляции, образуя методологический разрыв, преодолеть который способен только AppSec-эксперт путем кропотливого ручного триажа. В этой статье мы расскажем про то, как в INFERA AI.SafeCode уменьшаем поток ложных срабатываний в целом, зачем для этого формируем единый реестр знаний о проекте, и как строим мост от SAST к автоматически подтверждаемой уязвимости.

https://habr.com/ru/companies/infera_security/articles/1061880/

#Fuzzing #безопасная_разработка #devsecops #secret_scanner #mlsecops #ai_sast #infera_aisafecode #контроль_vibe_coding #appsecинструменты #ai_dast

От сотен алертов к доказанным уязвимостям: как эволюционирует DevSecOps при объединении 7 сканеров в единый пайплайн

Классический подход к Application Security сегодня переживает кризис, ситуацию усугубляет бум AI-помощников (GitHub Copilot, Cursor, Claude). Разработка ускорилась кратно, но вместе с ней масштабировалась и генерация небезопасного кода. Разработчик теперь может сгенерировать за час то, что раньше писал день, при этом уязвимости тоже начинают появляться с такой же скоростью. Если процесс безопасности остался прежним, AppSec быстро превращается в узкое место. В этой статье мы разберем архитектуру и механику работы INFERA AI.SafeCode – платформы непрерывного анализа кода, которая отказывается от концепции «просто показать список подозрений» в пользу автоматического доказательства уязвимостей и MLSecOps-подхода. Решение объединяет SAST, SCA, Secrets, DAST, Pentest, Code Fuzzing и API Fuzzing в единый DevSecOps / MLSecOps-контур. Статья продуктовая, но мы ее публикуем на HABR не как рекламную, а как концептуальную. Хотим показать, как меняются подходы к безопасной разработке и насколько неэффективным становится «разрозненный» AppSec в эпоху ИИ и вайб-кодинга.

https://habr.com/ru/companies/infera_security/articles/1061862/

#INFERA_AISafeCode #MLSecOps #безопасная_разработка #контроль_vibe_coding #DevSecOps #AppSecинструменты #AI_SAST #AI_DAST #fuzzing #secret_scanner

Под капотом у MOLOT’а: обзор ML-модели для обнаружения вредоносного кода

Всем привет! На связи Максим Митрофанов, руководитель ML-команды Application Security в Positive Technologies. Недавно мы выпустили нейросеть MOLOT и описали архитектуру решения в техрепорте на arXiv. Эта статья в каком-то смысле его TLDR в свободном изложении. Скажу сразу, наша модель — не LLM, хотя к трансформерам имеет самое прямое отношение. MOLOT построен на базе BERT-энкодера (не modern, не neo, а самого ванильного) и умеет обнаруживать вредоносный код по цепочкам вызовов не хуже Mythos от Anthropic (как минимум не боится промпт-инъекций).

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

#безопасная_разработка #molot #mlмодуль #вредоносный_код #детектирование #нейросеть #mythos #anthropic #llm #bert

Praetorian: как мы сделали security-продукт для корпоративных чатов в Telegram и Max

Привет, Хабр! Рабочие обсуждения давно ушли из почты и таск-трекеров в мессенджеры. Там собирают проектные группы и каналы, координируют инциденты, кидают ссылки на внутренние системы, за минуту стягивают нужных людей в один чат. У нас это в первую очередь корпоративные группы и каналы в Telegram и Max. Это удобно, но с точки зрения безопасности — новая поверхность риска. Как только группа или канал становится частью бизнес-процесса, он тянет за собой и все риски этого процесса: фишинг, социальную инженерию, вредоносные ссылки, угон аккаунтов, утечки, заброшенные чаты, участников, которых давно пора убрать, и переписку, которую никто не чистит годами.

https://habr.com/ru/companies/mvideo/articles/1056458/

#иб #информационная_безопасность #безопасность #безопасность_в_сети #безопасность_данных #безопасность_вебприложений #безопасная_разработка #безопасность_мобильных_приложений #безопасность_приложений #безопасность_linux

ASOC from scrap. Как реализовать автоматизацию DevSecOps контролей за несколько вечеров, используя OpenSource и LLM

Привет, Хабр! Сегодня я хочу поделиться своим опытом разработки ASOC платформы. В статье я расскажу о преимуществах такого решения, затем опишу особенности реализации всех ключевых компонентов. Моя цель показать, что разработка собственных ИБ инструментов сегодня не является сложной задачей и, возможно, вдохновить кого‑то на самостоятельное улучшение практик AppSec и DevSecOps в своей компании.

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

#python #fastapi #postgresql #grafana #appsec #devops #asoc #безопасная_разработка

«РБПО для бедных»: проверяем CI/CD-конвейер на реальных уязвимостях

За шесть предыдущих выпусков мы собрали собственный конвейер безопасной разработки: развернули виртуальные машины, подняли инфраструктуру из GitLab, Vault, Nexus, DefectDojo и Dependency-Track, написали CI/CD-пайплайн, подключили сканеры безопасности и настроили резервное копирование. Остается главный вопрос: сможет ли наш конвейер находить реальные уязвимости, а не просто радовать разработчиков зелеными галочками в интерфейсе GitLab? Как говорили старые DevSecOps-бояре, «в нашем деле на слово не верят — безопасность нужно проверять». Поэтому сегодня устроим нашему конвейеру проверку боем. Возьмем уязвимое приложение Reactvulna, загрузим его в GitLab и прогоним через собранный нами пайплайн. После этого разберем результаты сканирования и посмотрим, насколько хорошо собранная нами инфраструктура справляется с обнаружением проблем безопасности.

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

#рбпо #безопасность_вебприложений #безопасная_разработка #DevSecOps #react #secure_development #рбпо_для_бедных #ci_cd #информационная_безопасность #стартапы

[Перевод] Agentic SAMM: безопасная разработка, когда разработчик больше не только человек

Расширенная версия моего кейноута на ISC.AI 2026 в Пекине. Фреймворк и инструмент открыты — берите, ломайте и присылайте мне, что найдёте.

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

#SDLC #уязвимость #owasp #безопасная_разработка

«РБПО для бедных»: настраиваем резервное копирование

В прошлой статье мы завершили сборку конвейера безопасной разработки: настроили GitLab CI/CD, подключили Vault для безопасной работы с секретами, добавили статический и динамический анализ, генерацию SBOM, а также интеграцию с DefectDojo, Dependency-Track и Nexus. Теперь у нас есть пайплайн, который автоматически собирает приложение, проверяет его на уязвимости и сохраняет результаты анализа. Но любой конвейер хорош ровно до первого серьезного сбоя. Отказ диска, повреждение виртуальной машины или банальная человеческая ошибка могут за несколько минут уничтожить результат долгих часов работы. Сегодня займемся тем, о чем обычно вспоминают слишком поздно: резервным копированием. Подготовим отдельный диск для хранения бэкапов, автоматизируем создание резервных копий виртуальных машин с помощью PowerShell и настроим их регулярный запуск через планировщик Windows. В общем, избавим себя от необходимости собирать всю инфраструктуру заново в случае сбоя.

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

#рбпо #резервное_копирование #безопасная_разработка #devsecops #бэкап_виртуальных_машин #vm #виртуальные_машины

Тёмная сторона Go: разбор живых уязвимостей с продакшена и инструменты против них

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

https://habr.com/ru/companies/oleg-bunin/articles/1048122/

#Go #golang #информационная_безопасность #безопасная_разработка #HTTP_request_smuggling #JWT #логирование #govulncheck #DevSecOps #OWASP

«РБПО для бедных»: собираем CI/CD-конвейер безопасной разработки

В прошлой статье мы завершили настройку нашего стенда РБПО: подготовили GitLab и GitLab Runner, настроили Nexus, Vault, DefectDojo и Dependency-Track, а также создали все необходимые учетные записи, роли и переменные для будущего конвейера безопасной разработки. Теперь настало время собрать все эти инструменты в единый пайплайн. В этой статье напишем GitLab CI/CD-конвейер, который автоматизирует сборку приложения, проверки безопасности, генерацию SBOM и публикацию результатов в настроенные ранее сервисы. Другими словами, именно здесь наш стенд начнет выполнять ту работу, ради которой мы собирали его на протяжении предыдущих частей цикла.

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

#рбпо #конвейер #пайплайн #безопасная_разработка #devsecops #gitlab #ci_cd

«РБПО для бедных»: настраиваем сервисы безопасной разработки

В прошлой статье цикла мы закончили разворачивать инфраструктуру будущего РБПО: установили GitLab, Nexus, HashiCorp Vault, Dependency-Track и DefectDojo, подготовили отдельную виртуальную машину с инструментами безопасности и убедились, что все сервисы успешно запускаются. Но установить сервисы — это только половина дела. Теперь их нужно настроить и подготовить к совместной работе. Без этого GitLab останется просто GitLab, Vault — просто хранилищем секретов, а DefectDojo и Dependency-Track — красивыми веб-интерфейсами без практической пользы. В этой статье займемся базовой конфигурацией. Настроим GitLab и GitLab Runner, подготовим Nexus к приему артефактов, научим Vault доверять GitLab через JWT-аутентификацию и создадим необходимые сущности в DefectDojo и Dependency-Track. Документация открыта, терминал запущен, банка кваса на месте. Начинаем настройку инструментов.

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

#vault #devsecops #рбпо #безопасная_разработка #gitlab #Nexus #hashicorp_vault #DefectDojo #DependencyTrack #настройка

«РБПО для бедных»: разворачиваем сервисы безопасной разработки

В прошлой части цикла мы подготовили фундамент будущего РБПО: развернули виртуальные машины, настроили Ubuntu Server, сеть, брандмауэр и Docker. Другими словами, построили площадку, на которой теперь можно начинать возводить сам конвейер безопасной разработки. Теперь пора наполнять наши виртуальные машины полезным содержимым. Если продолжать сказочную аналогию — заселим наше царство безопасной разработки первыми жителями: хранителем секретов, смотрителем артефактов, летописцем уязвимостей и прочими полезными персонажами. То есть установим и настроим GitLab, Nexus, HashiCorp Vault, DefectDojo и Dependency-Track, а также подготовим отдельную виртуальную машину с набором CLI-инструментов для анализа безопасности. Большая часть сервисов будет работать в Docker-контейнерах, поэтому заодно разберемся с настройкой постоянного хранения данных, Docker Compose и некоторыми особенностями конфигурации отдельных компонентов. Что ж, глаза боятся, а руки команды в терминале набирают. Начнем с GitLab.

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

#рбпо #безопасная_разработка #стартапы #DevSecOps #развертывание_GitLab #управление_секретами #HashiCorp_Vault #конвейер_безопасной_разработки #defectdojo #DependencyTrack

«РБПО для бедных»: разворачиваем виртуальные машины

В прошлой статье цикла «РБПО для бедных» мы разобрались, что такое разработка безопасного программного обеспечения, зачем она нужна стартапам и как может выглядеть минимальный конвейер безопасной разработки. Теперь пора переходить от схем и планов к практике. В этом материале мы рассмотрим: • создание виртуальных машин в VirtualBox для сервисов безопасной разработки ПО; • подготовку виртуальных машин к дальнейшей работе; • установку Ubuntu Server с ручной настройкой статического IP; • первичную настройку серверов: часовой пояс, базовые утилиты, брандмауэр UFW, установку Docker и docker-compose. Мы создадим и подготовим пять виртуальных машин, на которых в следующих частях будем разворачивать сервисы безопасной разработки. К концу статьи у нас будет готова инфраструктурная основа будущего конвейера РБПО. Так что запасаемся терпением, запускаем VirtualBox и начинаем строить нашу небольшую лабораторию безопасной разработки.

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

#рбпо #безопасная_разработка #виртуальный_сервер #стартапы #DevSecOps #разработка_безопасного_по #ci_cd #виртуальные_машины

«РБПО для бедных»: сказ о том, как стартап безопасность прикручивал

Сказка — ложь, да в ней намек, разработчикам урок. В некотором опенспейсе, в некотором коворкинге завелся один стартап. С кофе-машиной, горящими дедлайнами и вечными созвонами. Решили там сделать ПОшечку невиданную — чтобы пользователи радовались, инвесторы кивали одобрительно, а деньги сами шли в кассу. И закипела работа, и стартовали один за другим спринты. Фичи выкатывались, метрики росли, разработчики героически коммитили по ночам. Вот только о безопасности в стартапе вспоминали примерно никогда. Некому было охранять секреты пользовательские, деньги виртуальные да API-ключи заветные. А хранилось всё это, прямо скажем, не самым надежным образом. На ту беду нашлись хакеры с купленным эксплойтом, и наступили у стартапа времена невеселые. Третьи точки горели, базы данных утекали, пользователи разбегались, а данные разлетались по самым темным уголкам интернета. Позвали тогда богатыря бывалого — эксперта по безопасной разработке. Ну, то есть меня. И попросили научить разработчиков код проверять, секреты хранить да конвейеры защищенные строить. В общем, построить РБПО, но без бюджетов размером с ВВП сказочного государства. Так появился этот цикл статей — про то, как собрать на коленке минимальный, но рабочий конвейер безопасной разработки. Долго сказка сказывается, да только CI/CD-пайплайн собирается еще дольше. Так что устраивайтесь поудобнее — расскажу, как строил «РБПО для бедных».

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

#рбпо #безопасная_разработка #стартапы #конвейер #DevSecOps_для_стартапов #ci_cd #appsec #разработка_безопасного_по #внедрение_РБПО

Больше, чем просто безопасность, или Зачем контролировать зависимости

Привет, Хабр! Меня зовут Артём Бердашкевич, в Positive Technologies руковожу направления DevSecOps. Сегодня хочу поговорить о теме, которая с годами становится только острее — о контроле зависимостей и о том, почему привычных подходов к нему уже катастрофически не хватает. Современная разработка давно превратилась в сборку из готовых компонентов, где мы почти не пишем код с нуля, а комбинируем фреймворки, библиотеки и модули с открытым исходным кодом. Такой подход радикально ускоряет вывод продуктов на рынок, но за скорость приходится платить прозрачностью. Команда часто не знает точный состав своего приложения до финальной сборки. Почему это стало большой проблемой и что с ней делать — читайте под катом.

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

#cybersecurity #devsecops #sca #легаси #зависимости #cve #безопасная_разработка #docker #sandbox #appsec

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

«У нас было два пакета 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_в_кибербезопасности #управление_уязвимостями #безопасность_приложений

[Перевод] ИИ против ИИ: кибербезопасность в эпоху мгновенного ПО

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

https://habr.com/ru/companies/cloud4y/articles/1029844/

#кибербезопасность #искусственный_интеллект #ИИ #уязвимости #поиск_уязвимостей #безопасная_разработка #вайбкодинг #MCP #Брюс_Шнайер #DRaaS