Команда безопасности: прошлое, настоящее и будущее

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

Изначально, команда безопасности создавала выпуски как только могла — иногда это занимало несколько часов, но временами это занимало 3–4 месяца. Количество дополнительных модулей росло, возрастала и занятость. Затем мы перешли на выпуск новой версии каждые 2 месяца. Регулярные, через одно и то же время выпуски были умным ходом — это позволило лучше планировать и координировать деятельность, что повысило нашу эффективность. Команда безопасности сделала большой шаг вперёд и мы до сих пор идём в ногу с растущим объёмом работы.

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

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

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

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

Это хороший пример того, о чём я говорил в своём докладе на Друпалконе в Вашингтоне: «Изменение планирования с координацией» (Клай Ширки). Хорошие новости заключаются в том, что разные люди из команды безопасности понимают это и некоторые уже стремятся так работать.