HTML Diff
0 added 0 removed
Original 2026-01-01
Modified 2026-03-10
1 <p>Почему парадигма<strong><a>DevSecOps</a></strong>так важна в современной разработке?</p>
1 <p>Почему парадигма<strong><a>DevSecOps</a></strong>так важна в современной разработке?</p>
2 <p><strong>DevOps</strong>изначально предполагал наличие проверок на безопасность. Но, как принято говорить, есть<strong>нюанс</strong>. Если вспомнить классический подход, то команды, отвечающие за безопасность, выступали не как участники непосредственного процесса разработки, а в качестве, в каком-то смысле, контрольного органа, предъявляющего определенные требования к продукту с точки зрения ИБ и проверяющего качество продукта ближе к концу релиза. Однако при таком подходе команды безопасности находятся за условной стеной от активной разработки и не принимают непосредственного участия в процессе этой самой разработки.</p>
2 <p><strong>DevOps</strong>изначально предполагал наличие проверок на безопасность. Но, как принято говорить, есть<strong>нюанс</strong>. Если вспомнить классический подход, то команды, отвечающие за безопасность, выступали не как участники непосредственного процесса разработки, а в качестве, в каком-то смысле, контрольного органа, предъявляющего определенные требования к продукту с точки зрения ИБ и проверяющего качество продукта ближе к концу релиза. Однако при таком подходе команды безопасности находятся за условной стеной от активной разработки и не принимают непосредственного участия в процессе этой самой разработки.</p>
3 <p>Таким образом, можно сформулировать основную проблему: она заключается в том, что<strong>информационная безопасность стоит отдельно от разработки</strong>. На практике существует некий ИБ-контур, включающий в себя 2-3 дорогих и громоздких инструмента. Где-нибудь раз в 6 месяцев прилетает исходный код либо программное приложение, которое надо проверить, ну и ориентировочно раз в год проводится тестирование на проникновение (<strong>пентест</strong>).</p>
3 <p>Таким образом, можно сформулировать основную проблему: она заключается в том, что<strong>информационная безопасность стоит отдельно от разработки</strong>. На практике существует некий ИБ-контур, включающий в себя 2-3 дорогих и громоздких инструмента. Где-нибудь раз в 6 месяцев прилетает исходный код либо программное приложение, которое надо проверить, ну и ориентировочно раз в год проводится тестирование на проникновение (<strong>пентест</strong>).</p>
4 <p>И что мы получаем в итоге? А то, что<strong>сроки выхода в прод откладываются</strong>, так как на разработчиков сваливается большое число уязвимостей из автоматизированных средств. Разобрать и исправить всё бывает попросту невозможно, особенно если учесть, что еще прошлые результаты разобрать не успели, не говоря уже о новой партии.</p>
4 <p>И что мы получаем в итоге? А то, что<strong>сроки выхода в прод откладываются</strong>, так как на разработчиков сваливается большое число уязвимостей из автоматизированных средств. Разобрать и исправить всё бывает попросту невозможно, особенно если учесть, что еще прошлые результаты разобрать не успели, не говоря уже о новой партии.</p>
5 <p>Сегодня такое положение вещей становится попросту недопустимым. В результате появляется понимание, что<strong>безопасность должна "крутиться" с разработкой в одном колесе</strong>(привет,<strong>Agile</strong>). И именно парадигма DevSecOps прекрасно ложится на методологию гибкой разработки, а также на внедрение, поддержку и непосредственное участие Security-специалистов в каждом релизе и итерации.</p>
5 <p>Сегодня такое положение вещей становится попросту недопустимым. В результате появляется понимание, что<strong>безопасность должна "крутиться" с разработкой в одном колесе</strong>(привет,<strong>Agile</strong>). И именно парадигма DevSecOps прекрасно ложится на методологию гибкой разработки, а также на внедрение, поддержку и непосредственное участие Security-специалистов в каждом релизе и итерации.</p>
6 <p><em>По материалам https://habr.com/ru/company/oleg-bunin/blog/448488/.</em></p>
6 <p><em>По материалам https://habr.com/ru/company/oleg-bunin/blog/448488/.</em></p>
7  
7