Где-то в вашей системе есть инструмент обеспечения безопасности разработчиков, лицензия на который никто не использует. Он прошел процедуру закупки. Он прошел пилотный проект. CISО подтвердил. А через шесть месяцев разработчики обходят это ограничение, отключают оповещения или молча продолжают работать так, как всегда. Это не проблема обучения или культуры соблюдения нормативных требований. Это проблема внедрения безопасности разработчиками, и она гораздо более распространена и предсказуема, чем большинство руководителей служб безопасности готовы признать.
Что на самом деле означает внедрение мер безопасности для разработчиков?
Внедрение инструментов обеспечения безопасности разработчиками — это разрыв между развертыванием инструмента и его использованием по назначению, ежедневно, без необходимости постоянного контроля со стороны кого-либо. Сканер, работающий в среде непрерывной интеграции (CI). Проблема, которую разработчики никогда не решаются решить, внедряется, а не принимается. Проблема, которую сразу же игнорируют, потому что последние десять случаев были ложными срабатываниями, внедряется, а не принимается. Реальное внедрение мер безопасности разработчиками выглядит скучно: разработчики добровольно открывают инструмент, действуют на основании его информации и не ищут способов обойти его.
Это различие важно, потому что показатели закупок и показатели внедрения измеряют совершенно разные вещи. Команда безопасности может сообщать о 100% охвате развертывания, в то время как уровень внедрения безопасности разработчиками близок к нулю, и оба показателя могут быть верны одновременно.
Почему традиционное программное обеспечение для обеспечения безопасности разработчиков не находит широкого применения
Большинство инструментов обеспечения безопасности для разработчиков терпят неудачу при внедрении по нескольким одним и тем же причинам, которые повторяются практически в каждой организации, пытавшейся внедрить такой инструмент:
- Слишком много шума, слишком мало доверия. Самый быстрый способ подорвать внедрение мер безопасности разработчиками — это высокий процент ложных срабатываний. После того, как разработчик проверяет три результата, которые оказываются безрезультатными, он перестает доверять четвертому и прекращает проверку пятого.
- Оно находится там, где его нет у разработчиков. A dashboard Разработчикам необходимо помнить, что открытие — это... dashboard Они об этом забудут. Программное обеспечение для обеспечения безопасности, требующее выхода из IDE, переключения контекста и последующего возвращения, упускает момент, когда исправление является самым дешевым и простым в реализации.
- Оно выявляет проблемы, не предлагая при этом решений. Сообщение об ошибке, гласящее «SQL-инъекция, строка 42», без объяснения пути эксплуатации или предложения решения проблемы, лишь подталкивает разработчиков к самостоятельной работе, а не помогает им. Это существенный удар по внедрению мер безопасности среди разработчиков, поскольку каждое такое сообщение превращается в исследовательский проект вместо полноценного решения проблемы.cisион.
- Это блокирует сборку, не объясняя причин. Красный pipeline Без контекста воспринимается как препятствие, а не как сигнал. Разработчики учатся воспринимать контрольную точку как нечто, что нужно преодолеть, а не как нечто, на что нужно обратить внимание.
- Он создан для аудитора, а не для разработчика. Инструменты, разработанные в первую очередь для получения доказательств соответствия требованиям, часто это демонстрируют: многословные отчеты, перегруженные профессиональным жаргоном выводы, отсутствие попыток говорить на языке человека, от которого фактически ожидается выполнение этих требований.
Тест для разработчиков программного обеспечения в области безопасности: откроют ли они его во второй раз?
Вот полезный фильтр для оценки любого программного обеспечения для обеспечения безопасности разработчиков перед его покупкой: откроет ли разработчик его завтра без запроса? Не потому, что этого требует политика, а потому, что вчера оно предоставило ему что-то полезное. Большинство инструментов, которые не проходят проверку на безопасность разработчиков, проваливают этот тест в первый же день, и все уже подозревали об этом до подписания контракта.
Инструменты, которые проходят проверку, имеют несколько общих черт. Они находятся внутри редактора, а не за ним. loginОни объясняют обнаруженную проблему так, как это сделал бы опытный инженер в ходе проверки кода, а не так, как это сделал бы отчет о соответствии. Они предлагают конкретное решение, а не просто диагноз. И что особенно важно, они достаточно часто оказываются правы, так что разработчику не нужно перепроверять каждое предупреждение, прежде чем ему доверять.
Что на самом деле стимулирует внедрение?
Правильное внедрение мер безопасности для разработчиков сводится не к улучшению обучения или ужесточению требований. Всё сводится к небольшому числу аспектов проектирования.cisионы:
- Встречайтесь с разработчиками там, где они уже работают. Безопасность, встроенная в интегрированную среду разработки (IDE)., pull requestИ интерфейс командной строки используется. Безопасность, требующая отдельного места назначения, не используется.
- Объясните, а не просто отметьте как подозрительное. Обнаруженная уязвимость в сочетании с понятным объяснением пути её использования превращает загадочное предупреждение в нечто, что разработчик может осмыслить и немедленно отреагировать.
- Предложите решение, а не просто описание проблемы. Автоматическое исправление ошибок, которое разработчик может просмотреть и принять за считанные секунды, экономит его время так, как это никогда не удается при отправке отчета об ошибке.
- Поддерживайте высокое соотношение сигнал/шум. Агрессивная фильтрация ложных срабатываний — это не просто желательная функция, а самый важный фактор, определяющий, сохранится ли внедрение решений по безопасности для разработчиков после первого месяца.
- Оставляйте жесткие ограничения только для действительно важных вещей. Guardrails которые разрушают сборку при каждой незначительной проблеме, заставляя разработчиков обучать других негодовать по поводу ворот. Guardrails Блокировка только действительно критических, устранимых проблем приучает разработчиков доверять системе.
Как компания Xygeni подходит к проектированию программного обеспечения для обеспечения безопасности разработчиков
Плагин Xygeni IDE Программа запускается там, где уже находятся разработчики, внутри IDE, непрерывно сканируя код, сгенерированный людьми и ИИ, по мере его написания, без каких-либо запросов. При обнаружении уязвимости она объясняет полный путь её эксплуатации простым языком и предлагает исправление, которое разработчик может просмотреть и применить, вместо того чтобы оставлять его разбираться в проблеме только по идентификатору CVE.
ИИ-триаж Применяется одинаковая фильтрация ложноположительных результатов ко всем системам. SAST, Секреты, IaCи обнаружение вредоносного ПО на всей платформе, чтобы проблема информационного шума, которая препятствует внедрению безопасности разработчиками в других областях, решалась до того, как обнаруженное ПО попадет в очередь разработчиков. Разработка guardrails обеспечивать соблюдение политики на pipeline На уровне, но избирательно, блокируя действительно критические, устранимые проблемы, а не рассматривая каждое обнаруженное нарушение как одинаково критическое для сборки. Именно это различие мешает разработчикам научиться обходить блокировку.
Всё это не отменяет того факта, что застройщики, как правило, являются рычагом, а не экономическим покупателем. enterprise AppSec decisион. А CISО подписывает контракт; вице-президента по разработке волнует, создаст ли инструмент проблемы для его команды. Но именно внедрение инструментов обеспечения безопасности разработчиками превращает этот рычаг в рычаг: инструмент, который разработчики действительно используют, устраняет реальные уязвимости, а инструмент, который они обходят стороной, не устраняет ни одной, независимо от того, кто одобрил заказ на покупку.
Оценка внедрения, а не просто развертывания.
Если вы хотите получить объективную оценку уровня внедрения мер безопасности разработчиками в вашей организации, то показатель охвата развертываний — это неправильный критерий. Более информативными показателями являются:
- Как часто разработчики открывают инструмент без предварительного уведомления?
- Какая доля предложенных решений принимается, а какая отклоняется?
- Действительно ли сокращается время, необходимое для устранения проблемы, а не просто регистрируются ли результаты проверок.
- Независимо от того, запрашивают ли разработчики инструмент для нового проекта или ждут указаний по его установке.
Количество лицензий показывает, что вы приобрели. Эти цифры показывают, действительно ли разработчики внедрили меры безопасности.
FAQ
Что означает «внедрение безопасности разработчиками»?
Это разрыв между развертыванием инструмента безопасности и его фактическим использованием по назначению, добровольно, ежедневно, без принуждения. Высокий уровень внедрения и низкий уровень использования средств безопасности разработчиками могут сосуществовать, и часто так и происходит.
Почему разработчики игнорируют инструменты безопасности даже после обучения?
Обучение не исправит инструмент, который выдает слишком много ложных срабатываний, выходит за рамки рабочего процесса разработчика или указывает на проблему, не предлагая решения. Это проблемы проектирования, а не пробелы в знаниях, и никакое обучение не изменит лежащие в основе проблемы.
Какой самый важный фактор способствует внедрению мер безопасности среди разработчиков?
Доверяйте сигналу. Как только разработчики перестают доверять тому, что обнаруженная ошибка реальна, они перестают реагировать на все эти ошибки, включая те, которые действительно важны. Агрессивная фильтрация ложноположительных результатов обычно является наиболее эффективным решением.
Чем отличается программное обеспечение для обеспечения безопасности разработчиков от традиционных инструментов обеспечения безопасности приложений?
Лучшее программное обеспечение для обеспечения безопасности разработчиков рассматривает разработчика как основного пользователя, а не просто как объект проверки на соответствие требованиям: оно работает внутри IDE, объясняет результаты проверки простым языком и предлагает решения, а не создает отчет для последующего анализа кем-то другим.
Должен ли CISМеня волнует вопрос безопасности использования инструмента разработчиками, если именно они его покупают?
Да, напрямую. Инструмент с высоким уровнем соответствия нормативным требованиям, но слабым уровнем внедрения мер безопасности разработчиками, на самом деле не снижает риски, а просто генерирует отчеты. Снижение рисков... CISПокупка O реализуется только в том случае, если разработчики используют этот инструмент.
