Share This
Связаться со мной
Крути в низ
Categories
//∞ Зачем разработчику DevSecOps?

∞ Зачем разработчику DevSecOps?

С повышением объёмов данных растёт необходимость их защиты. Здесь как раз требуется DevSecOps, где DevOps – процесс разработки и доставки программы, а частица Sec отвечает за защиту этого приложения.

infin zachem razrabotchiku devsecops 5c30ea8 - ∞ Зачем разработчику DevSecOps?

Пара слов о DevSecOps DevSecOps – добавление в методологию DevOps. После условного шага внесения изменений в код, этот код извлекается и проверяется на ошибки безопасности. Затем новую версию приложения целиком проверяют на риски, проводят тесты безопасности, и после прохождения тестов – приложение отправляется в производство.

Грубо говоря, это врезка дополнительного шага в методологию разработки ПО. Шаг добавляется после внесения изменений в программу. Сама же методология направлена на более тесное сотрудничество между командами разработки и эксплуатации и добавляя к ним команду безопасности.

Каким разработчиками требуется знания DevSecOps? В теории – всем. Понимание методологии позволит меньше ругаться с безопасниками, возможно даже предвосхищать какие-то проблемы информационных утечек.

С учётом нынешней скорости разработки новых версий продукта, команда информационной безопасности не всегда успевает держаться в том же темпе. Для его сохранения следует задуматься о включении проверок безопасности кода как можно раньше – это можно назвать частью процесса «сдвиг влево», когда команда безопасности тестирует код до разработчиков.

Разумеется, вплотную заниматься методологией придётся тем разработчикам, которые входят в команду по информационной безопасности. Да, это та самая команда, которая позже взбесит всех прочих программистов, но такова цена безопасности.

При этом важно понимать, что и обычные разработчики, и команда безопасности всегда будут правы по своему и искать кого-то более виноватого бессмысленно – это лишь ещё оттянет процесс разработки.

Разница между DevOps и DevSecOps Большая часть организаций используют SDLC на базе Agile для ускорения разработки. DevOps и DevSecOps используют Agile в качестве базы, но для разных целей. DevOps фокусируется на скорости разработки приложения, а DevSecOps – на разработке максимально защищённого приложения в кратчайший срок.

Беспокойство о безопасности может полностью похоронить любую разработку из-за нерационально расходуемого времени.

Философия DevSecOps предлагает интегрировать тесты безопасности во все циклы DevOps: начало, дизайн, сборку, тестирование, выпуск, поддержку и обслуживание.

Методология предлагает постоянное сотрудничество между разработчиками, командой выпуска и безопасниками. Она помогает поддерживать высокую скорость разработки без большого урона для безопасности.

Особенности разработки

Самая главная особенность, способная сломать любой план – желание безопасников постоянно вмешиваться в каждый процесс.

Во избежание этого следует заранее создать различные правила остановки разработки при наличии уязвимостей. Например, при наличии критической ошибки безопасности дальнейшая разработка прекращается, и все силы перебрасываются на её исправление. Если ошибка не настолько критична, но имеет значение, можно не прерывать разработку, а лишь обратить на проблему внимание.

Для экономии времени следует обращать внимание на те ошибки безопасности, которые появились только в текущей итерации. Например, если разработчики передвинули кнопку, не стоит от них требовать немедленного исправления SQL-инъекции, которая не была исправлена несколько шагов назад.

infin zachem razrabotchiku devsecops 7a213ec - ∞ Зачем разработчику DevSecOps?

Важность DevSecOps

Правильное настроение во время программирования экономит время. В данном случае разработчикам следует фокусироваться на безопасности – в дальнейшем это сокращает время, затрачиваемое на вылов и исправление багов.

Методологию, кстати, можно использовать не только для разработки ПО, но и в других сферах:

  • Автомобилестроение. Сокращения времени цикла при соблюдении стандартов, вроде MISRA и AUROSAR.
  • Здравоохранение. Обеспечение цифровизации при сохранении конфиденциальности и безопасности данных в соответствии с HIPAA.
  • Финансы и коммерция. Избавление от OWASP 10 (основные риски веб-безопасности) и обеспечение безопасности данных платёжных карт по стандартам PCI DSS для транзакций.
  • Гаджеты. Предотвращение возникновения CWE 25 (самые опасные программные ошибки).

Мифы о DevSecOps

  • Для применения методологии требуются крутые спецы. Не до конца правдивое утверждение. Конечно, опытные работники со своими задачами справятся лучше, но не стоит утверждать, будто только одарённые разработчики спасут безопасность. Если же стоит задача воспитать своих программистов в рамках DevSecOps, это вполне реально.
  • DevSecOps может заменить Agile. В корне неверно. DevSecOps дополняет, а не заменяет Agile. Agile ориентирован на совместную работу и мгновенный фидбэк, но, в отличие от DevSecOps, никак не покрывает доставку ПО через тестирование, QA и производство. Совместное использование методологий позволяет закрыть все дыры.
  • Можно купить DevSecOps. Нельзя. Приобрести можно только инструменты, а сам процесс – никак. Это скорее методология разработки или философия. Ту самую совместную работу и фокус на собственной и коллективной ответственности купить не получится, только воспитать и привить.

Хорошие практики DevSecOps

Как у каждой методологии, у DevSecOps есть собственные стандартные практики, упрощающие её использование:

  • Практика безопасного кода. Пусть и очевидно, но только так можно писать хороший код, защищённый от компрометации. Да, скорее всего это создаст дополнительную задержку и расходы, но позволит избежать проблем с информационной безопасностью: утечек данных и нарушения работоспособности сервисов. Создание стандартов позволит упростить процесс разработки.
  • Автоматизация. Как и в DevOps, автоматизация является ключевой характеристикой DevSecOps. Чтобы темп проверки безопасности поспевал за темпом разработки, автоматизация должна применяться изначально, особенно в крупных компаниях. Есть и обратная сторона: выбор неправильных инструментов приведёт к большой проблеме.
  • Смещение (сдвиг) влево. Методология тестирования, когда проверка безопасности встраивается в разработку с самого начала, не дожидаясь цепочки поставки. Очевидная выгода – проблемы засекаются сразу и работа по их исправлению завершается намного раньше. К тому же, чем раньше замечается баг, тем дешевле его починить. Проблема в том, что «сдвиг влево» может нарушить рабочий процесс и потребуется время для привыкания.
  • В DevSecOps есть три «кита»: люди, процесс, технологии.
  • Люди. Если работники не заинтересованы в DevSecOps, то никак не получится добиться соблюдения всех правил. Сначала следует убедить всех, что оно того стоит. Впрочем, здесь будет несложно – в последнее время очень часто вскрывают утечки конфиденциальных данных, которые наносят огромный ущерб тем, кто их допустил. Чего стоит одна история со взломом Kaseya.
  • Процесс. Важные его части: стандартизация и документация. Обычно, разные команды выполняют разные процессы, но DevSecOps призывает к созданию согласованных и совместному их исполнению для повышения безопасности при разработке.
  • Технология. Технология и есть. Та же автоматизация, менеджмент версий проектов, методология Security as Code и прочие возможности ПО, которые обеспечивают выполнение задач.

Краткий список инструментов DevSecOps:

  • Static application security testing (SAST). Статическое тестирование безопасности приложений. Инструменты сканируют код для выявления ошибок и конструктивных недостатков, которые приводят к появлению уязвимостей. SAST в основном используется на этапах создания кода, сборки и разработки SDLC. Coverity – один из вариантов.
  • Software composition analysis (SCA). Анализ состава ПО. Сканируется исходный код и двоичные файлы для выявления известных уязвимостей в компонентах с открытыми исходниками и продуктами сторонних разработчиков. Оценивается уровень риска безопасности для приоритизации ошибок и ускорения их исправления. SCA интегрируется в CI/CD процессы для постоянного мониторинга ошибок в компонентах с открытыми исходниками.
  • Interactive application security testing (IAST). Интерактивное тестирование безопасности приложений. Инструменты работают в фоне во время ручных или автоматических тестов. Анализируется поведение веб-приложений. Например, Seeker IAST наблюдает за взаимодействиями, поведением и потоком данных между запросами и ответами приложений. Находит уязвимости, воспроизводит и тестирует результаты, предоставляя информацию разработчикам. Вплоть до строки кода, где появляется ошибка.
  • Dynamic application security testing (DAST). Динамическое тестирование безопасности приложений. По сути это автоматизированный чёрный ящик, имитирующий поведение хакера. Работает он через сетевое соединение и исследует исполнение приложения со стороны клиента. Таким инструментам не нужен доступ к исходникам или настройкам для сканирования: они работают с приложением и ищут уязвимости с низким уровнем ложных срабатываний.

Заключение

DevSecOps – методология разработки, в которой код, прежде чем выйти в релиз, тестируется на возможные информационные утечки. Это влияет на скорость разработки, поэтому следует заранее определить уровни ошибок: от критических до маловажных.

Основная цель использования методологии – настроить команду на волну, когда каждый отвечает за безопасность. Необходимо, чтобы коллектив был одним механизмом, а не делился на независимых разработчиков и безопасников. Суть в единстве. ***

Если вы заинтересованы в развитии карьеры в этой сфере, стоит обратить внимание на «Факультет информационной безопасности» образовательной онлайн-платформы GeekBrains. На 70% учебная программа состоит из вебинаров с преподавателями, которым вы сможете задать все интересующие вопросы по темам и оперативно получить от них обратную связь.

Кроме того, куратор и менеджеры GeekBrains помогут освоиться и решить технические сложности на разных этапах обучения, а постоянная практика (в том числе командные соревнования по информационной безопасности в формате Capture the flag) не дадут застрять на месте.

Продолжительность обучения – один год. За это время вы освоите современные технологии и компетенции, которые необходимы специалистам по безопасности: Application Security Engineer, пентестеру, специалисту по информационной безопасности или DevSecOps-инженеру.

Интересно, хочу попробовать

  • 2 views
  • 0 Comment

Leave a Reply

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Свежие комментарии

    Рубрики

    About Author 01.

    blank
    Roman Spiridonov

    Моя специальность - Back-end Developer, Software Engineer Python. Мне 39 лет, я работаю в области информационных технологий более 5 лет. Опыт программирования на Python более 3 лет. На Django более 2 лет.

    Categories 05.

    © Speccy 2020 / All rights reserved

    Связаться со мной
    Close