#shift_left — Public Fediverse posts

Код пишет ИИ. Кто и как его проверяет?

Инструмент внедрили за неделю, а правила приёмки не написали вовсе. Это не преувеличение. За последний год картина в большинстве команд стала одинаковой: ИИ-ассистент стоит почти у каждого разработчика, его код ежедневно уходит в продукт, а общего стандарта «что считать принятым» у компании нет. Проверять успевают не всё, т.к. изменений стало в разы больше , а ревьюеров в лучшем случае осталось столько же. «Выглядит правдоподобно» подменяет «проверено». Ошибка, не пойманная на входе, возвращается переделкой через одну-две недели. Скорость выросла у всех, а дисциплина почти ни у кого. Эта статья про то, почему обычное ревью и обычный SAST в эпоху vibe coding перестают быть достаточным контуром контроля, какой стандарт приёмки ИИ-кода мы считаем минимально рабочим и как устроена проверка, в которой модель, написавшая код, не является тем, кто его принимает. Мы разберём, что именно ломается в инженерном процессе, когда код пишет не человек , и какие слои контроля должны появиться до репозитория, в IDE, в pull request и в CI/CD.

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

#стандарт_приёмки_ИИкода #AppSec #INFERA_AISafeCode #SAST #DAST #ИИассистент_для_ревью #Shift_Left #vibe_coding #Code_Fuzzing #AIпентест

Код пишет ИИ. Кто и как его проверяет?

Инструмент внедрили за неделю, а правила приёмки не написали вовсе. Это не преувеличение. За последний год картина в большинстве команд стала одинаковой: ИИ-ассистент стоит почти у каждого разработчика, его код ежедневно уходит в продукт, а общего стандарта «что считать принятым» у компании нет. Проверять успевают не всё, т.к. изменений стало в разы больше , а ревьюеров в лучшем случае осталось столько же. «Выглядит правдоподобно» подменяет «проверено». Ошибка, не пойманная на входе, возвращается переделкой через одну-две недели. Скорость выросла у всех, а дисциплина почти ни у кого. Эта статья про то, почему обычное ревью и обычный SAST в эпоху vibe coding перестают быть достаточным контуром контроля, какой стандарт приёмки ИИ-кода мы считаем минимально рабочим и как устроена проверка, в которой модель, написавшая код, не является тем, кто его принимает. Мы разберём, что именно ломается в инженерном процессе, когда код пишет не человек , и какие слои контроля должны появиться до репозитория, в IDE, в pull request и в CI/CD.

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

#стандарт_приёмки_ИИкода #AppSec #INFERA_AISafeCode #SAST #DAST #ИИассистент_для_ревью #Shift_Left #vibe_coding #Code_Fuzzing #AIпентест

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

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

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

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

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

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

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

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

ИИ для QA: мы перестали тратить часы на подготовку Acceptance Criteria

Всем привет! Я Марго, QA-инженер команды МС в Банки.ру. Этой весной мы с командой автоматизировали подготовку Acceptance Criteria (это по сути такой чек-лист, по которому команда проверяет, готова ли задача) с помощью ИИ. Это сократило рутинную работу и ускорило тестирование. Ниже расскажу, как мы это сделали.

https://habr.com/ru/companies/banki/articles/1056464/

#acceptance_criteria #критерии_приемки #shift_left #QAавтоматизация #ИИ_для_тестирования #Claude_Sonnet #AIскилл #Happy_Path_Edge_Case #Jira_Confluence_автоматизация #встроенное_качество

ИИ для QA: мы перестали тратить часы на подготовку Acceptance Criteria

Всем привет! Я Марго, QA-инженер команды МС в Банки.ру. Этой весной мы с командой автоматизировали подготовку Acceptance Criteria (это по сути такой чек-лист, по которому команда проверяет, готова ли задача) с помощью ИИ. Это сократило рутинную работу и ускорило тестирование. Ниже расскажу, как мы это сделали.

https://habr.com/ru/companies/banki/articles/1056464/

#acceptance_criteria #критерии_приемки #shift_left #QAавтоматизация #ИИ_для_тестирования #Claude_Sonnet #AIскилл #Happy_Path_Edge_Case #Jira_Confluence_автоматизация #встроенное_качество

4 мифа про DevSecOps, которые мешают безопасной разработке

Привет, Хабр! На связи Николай Лузгин, DevSecOps Lead и Илья Шаров (@issharov), Head of DevSecOps из МТС Web Services. Те самые безопасники, которые приходят в каске, запускают сканеры и доводят разработчиков до слез (нет). На самом деле DevSecOps — это не про страдания и бесконечные отчеты сканеров в PDF, а про здравый смысл и взаимодействие. У нас в MWS это полноценный процесс, состоящий не только из инструментов, пайплайнов, требований и Security Gate. В своей работе мы учитываем особенности продуктовой разработки большого количества команд — от крупных до малых инженерных групп, создающих MVP. Вместе с ними боремся за Time-to-Market и оптимизацию расходов, но при этом делаем ставку на повышение безопасности выпускаемого продукта. И главное — помогаем находить уязвимости на ранних этапах. Объясняем их суть на понятном языке, проверяем эксплуатируемость, придумываем меры митигации и составляем план по устранению — причем не где-то там в своих кабинетах, а вместе с командой при планировании работы на спринт или квартал. Звучит неправдоподобно? Из-за образа безопасников-церберов, который складывался в ИТ-тусовке десятилетиями, работа DevSecOps и правда представляется по-другому. Мы решили разобрать четыре главных мифа, которые встречаются при выстраивании отношений между ИБ и ИТ. Погнали рушить стереотипы!

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

#devsecops #devsecops_и_devops #безопасная_разработка #ssdlc #мифы_о_devsecops #безопасная_архитектура #безопасный_процесс #shift_left #shift_left_security

4 мифа про DevSecOps, которые мешают безопасной разработке

Привет, Хабр! На связи Николай Лузгин, DevSecOps Lead и Илья Шаров (@issharov), Head of DevSecOps из МТС Web Services. Те самые безопасники, которые приходят в каске, запускают сканеры и доводят разработчиков до слез (нет). На самом деле DevSecOps — это не про страдания и бесконечные отчеты сканеров в PDF, а про здравый смысл и взаимодействие. У нас в MWS это полноценный процесс, состоящий не только из инструментов, пайплайнов, требований и Security Gate. В своей работе мы учитываем особенности продуктовой разработки большого количества команд — от крупных до малых инженерных групп, создающих MVP. Вместе с ними боремся за Time-to-Market и оптимизацию расходов, но при этом делаем ставку на повышение безопасности выпускаемого продукта. И главное — помогаем находить уязвимости на ранних этапах. Объясняем их суть на понятном языке, проверяем эксплуатируемость, придумываем меры митигации и составляем план по устранению — причем не где-то там в своих кабинетах, а вместе с командой при планировании работы на спринт или квартал. Звучит неправдоподобно? Из-за образа безопасников-церберов, который складывался в ИТ-тусовке десятилетиями, работа DevSecOps и правда представляется по-другому. Мы решили разобрать четыре главных мифа, которые встречаются при выстраивании отношений между ИБ и ИТ. Погнали рушить стереотипы!

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

#devsecops #devsecops_и_devops #безопасная_разработка #ssdlc #мифы_о_devsecops #безопасная_архитектура #безопасный_процесс #shift_left #shift_left_security