К сожалению, Хабр за это время эволюционировал также и в ещё одну площадку для размещения статей про успешные успехи с кликбейтными заголовками и рекламой телеграм-каналов, которая стала уже практически дефолтом.
Вставлять баннер в середину поста как-то не ок. Особенно с учётом того, что сверху есть уже настолько большой, что приходится скроллить до начала этого самого поста :(
За потоком ненависти, передёргивания фактов (?) и просто набросов в этом посте можно разглядеть и разумное зерно. Безопасность в большинстве случаев не должна вредить пользовательскому опыту, потому что она является "частью продукта". Как только пользователю становится неудобно использовать сервис по причинам так или иначе связанным с обеспечением безопасности, то это сразу начинает негативно влиять как на впечатление от самого сервиса (и компания теряет пользователя, а вместе с ним и деньги), так и на соответствующую функцию безопасности (пользователь начинает использовать эту функцию не так, как планировались при проектировании, потому что ему так удобно -- и это нормально). При этом важно помнить про анализ рисков и сервисы с многомиллионными аудиториями.
Поэтому в предложенном опросе, очевидно, не хватает третьего пункта "Безопасная свобода".
Всего 3 ссылки на Телеграм в конце поста -- надо больше! :) А вообще, выделить бы вот это всё "Развитие стартапа, Интервью, Лайфхаки для гиков, Бизнес-модели" в отдельную секцию Хабра...назвать как-нибудь необычно, например "ВЦ".
Есть вот такой небольшой проект генератора статического OPDS-каталога для домашней библиотеки: Lib2OPDS. На сервере есть директория, куда кладутся книги, а дальше по крону генерируется OPDS-каталог, который можно раздавать с помощью веб-сервера по вкусу.
Внезапно и странно с учётом позирования Хабра как сообщества IT-специалистов (https://company.habr.com/ru/) и возможности указать на несоответствие тематики при отметке минусом поста.
Наша цель — создать комфортную экосистему для сообщества разработчиков, инженеров, дизайнеров, менеджеров — всех, кто создаёт IT-продукты.
Надеюсь, что команда Хабра наконец-то обратит внимание и таких статей станет меньше (или хотя бы будет работающий способ убрать их отовсюду из интерфейса при игноре автора).
Допустим, что у вас 5 вертикалей и каждый SecBP уходит отпуск хотя бы раз в год, тогда почти полгода основная команда будет вынуждена переключаться на решение задач соответствующего бизнес-юнита (и следовательно будет необходимость поддерживать знание в соответствующем домене). Как вы планируете решать эту проблему? Планируете ли возможность организовать команду под каждого SecBP?
Нет, не рассматривали. С таким подходом вижу сложность в оценке, тк не все изменения можно предусмотреть заранее
По описании фичи часто можно спрогнозировать, что она в принципе будет рискованна. Следовательно можно и заложить под это полноценный анализ рисков (вместо фиксированного времени, которого просто может не хватить и будет пропущен действительно рискованный релиз).
В целом, любопытно было бы почитать такой же пост, но по прошествии 1-2 лет и, конкретно, про то, насколько много продуктовые команды вертикалей стали делать больше самостоятельно в плане ИБ (либо же SecBP стали для них ответом на все вопросы).
SecBP закреплен за бизнес-направлением, в котором может быть 25–40 команд. Он служит точкой входа в основную команду ИБ, но не берет на себя все задачи по безопасности.
А что происходит, когда SecBP уходит в отпуск?
Продуктовые команды действительно начали активнее работать с инструментами ИБ, улучшать их настройку и процессы. Однако пока рано говорить о полноценном эффекте, так как в ряде направлений (кроме двух пилотных) роль SecBP еще не внедрена, и эти задачи по-прежнему выполняются основной командой ИБ.
Этот результат немного отличается от декларируемого в статье: "В целом инициатива оказалась крайне полезной. Мы достигли повышения прозрачности ситуации с безопасностью, улучшили процессы и повысили зрелость команд в вопросах ИБ. Многие команды сильно поменяли свой mindset и стали относиться к ИБ не как к «необходимому злу», а как к надёжным помощникам, стали активнее давать обратную связь и делиться идеями по улучшению процессов ИБ. "
Приблизительно оценили, сколько времени уходит на выполнение задач.
Часто размер задач достаточно сложно оценить, тем более в часах. У вас же получилось упаковать то же тестирование безопасности и исправление найденных уязвимостей в достаточно жесткие временные рамки. Рассматривали ли вы возможность сначала делать быструю сортировку фич с дальнейшим анализом рисков и уже на основе этого тестирование безопасности и т.д.? То есть идти от того, насколько потенциально рискованная фича, а не просто строго выделять время в неделю.
Основной целью пилота было снижение рисков и повышение уровня безопасности продуктов Авито за счёт более тесного и эффективного взаимодействия между продуктовыми командами и командой безопасности, чтобы обе стороны выиграли от сотрудничества.
Не получилось ли так, что продуктовые команды по сути начали аутсорсить все вопросы безопасности в своих SecBP (и теперь надо как минимум иметь количество SecBP >= число команд) вместо того, чтобы осознать собственную ответственность за риски в разрабатываемых сервисах (и, как следствие, уделять больше внимание вопросам ИБ)? Стали ли продуктовые команды выполнять больше задач, относящихся к безопасности, после того как у них появлялся SecBP, но без его участия?
Чтобы пилот прошёл успешно, от команд разработки требовалось выделить время для онбординга Sec BP на регулярные встречи, предоставление документации и погружение в контекст проектов: 4 часа в неделю. Важно было выделить время на оценку рисков — 2 часа от команды, проведение пентестов ключевых фич — 1 час на одну фичу — и на устранение найденных уязвимостей.
А почему вы решили это измерять, причем формально (в часах)?
В команды могут влететь разные задачи: пройти аудит по защите персональных данных, запатчить баги, пройти обучение и т.д.;
Почему это рассматривается именно как "внешние" задачи, при том, что это по сути часть продукта?Например, если баги не будут исправлены, то может реализоваться риск соответствующей атаки (и инцидента). Этот риск может и быть принят в пользу расхода ресурсов на продуктовые фичи. И это решение продуктовой команды.
Заголовок мог быть ещё лучше -- "Сёрфер-энтузиаст из Санта-Круса закрыл прибыльный магазин на {маркетплейсе}, переехал жить в {например_хостел} и покорил 32-метровую волну. Как это у него получилось и в чём нюанс?". К сожалению, таких постов и новостей, теперь на Хабре становится всё больше.
Прочитал в оригинале. Книга произвела впечатление хорошего обзорного (угроз) труда. Идея с отсылками к конкретным моментам и вообще к ЗВ понравилась, хотя и частенько, как мне показалось, это было "притянуто за уши".
Кто сказал что здесь не может быть ничего альтерантивного?
С момента своего запуска Хабр эволюционировал из ресурса для обмена знаниями из мира информационных технологий (назовём это computer science) в гораздо менее специализированный сайт, который часто используется как генератор трафика или рекламная площадка. Ещё и добавили неотключаемые новостные блоки, чтобы ещё больше получить внимания. Проблема даже не в этой эволюции, а в том что альтернативы текущему Хабру, но с прежними принципами, так и не появилось (?) за это время. К тому же, всё-таки и сейчас бывают годные статьи тут.
Все эти млрд строк кода и десятки тысяч репозиториев (с кучей веток) выглядят как маркетинговые цифры и/или цифры, которые вы сами себе сгенерировали (как в случае со срабатываниями анализиторов). При этом сама AppSec платформа выглядит впечатляюще. Спасибо за интересную статью!
Хотелось бы побольше узнать о базовом процессе со стороны разработчика и безопасника: как буквально разработчик с этим взаимодействует и насколько это ухудшает (или улучшает) его жизнь? Security Gate скорее всего предполагает блокирование релиза на основе наличия High+ уязвимостей? То же самое и в контексте безопасника, особенно с учётом таких объёмов для триаджа.
Сорри за немного провакационный вопрос, но рассматривали ли возможность вообще не аггрегировать и не хранить результаты работы анализаторов, а показывать их только в контексте PR-ов?
На счет существующих решений - есть большое количество решений для git репозиториев, но именно для таск трекера находил несколько
Но ведь вам по факту уже не так важна интеграция с Джирой, сколько просто анализ текста на наличие секретов. Вы же всё равно сами забираете текст нужных тикетов и потом отдаете в ваш анализатор. Поэтому и подумалось, что вам мог бы подойти и какой-то из существующих анализаторов, который умеет в stdin принимать текст или же просто текстовые файлики анализировать.
Но тут есть сложности - это настраивается на каждом workflow а у нас их довольно много. Так же эта проверка не отработает, при написании комментария, либо после редактирования.
К сожалению, Хабр за это время эволюционировал также и в ещё одну площадку для размещения статей про успешные успехи с кликбейтными заголовками и рекламой телеграм-каналов, которая стала уже практически дефолтом.
Вставлять баннер в середину поста как-то не ок. Особенно с учётом того, что сверху есть уже настолько большой, что приходится скроллить до начала этого самого поста :(
За потоком ненависти, передёргивания фактов (?) и просто набросов в этом посте можно разглядеть и разумное зерно. Безопасность в большинстве случаев не должна вредить пользовательскому опыту, потому что она является "частью продукта". Как только пользователю становится неудобно использовать сервис по причинам так или иначе связанным с обеспечением безопасности, то это сразу начинает негативно влиять как на впечатление от самого сервиса (и компания теряет пользователя, а вместе с ним и деньги), так и на соответствующую функцию безопасности (пользователь начинает использовать эту функцию не так, как планировались при проектировании, потому что ему так удобно -- и это нормально). При этом важно помнить про анализ рисков и сервисы с многомиллионными аудиториями.
Поэтому в предложенном опросе, очевидно, не хватает третьего пункта "Безопасная свобода".
Всего 3 ссылки на Телеграм в конце поста -- надо больше! :) А вообще, выделить бы вот это всё "Развитие стартапа, Интервью, Лайфхаки для гиков, Бизнес-модели" в отдельную секцию Хабра...назвать как-нибудь необычно, например "ВЦ".
Есть вот такой небольшой проект генератора статического OPDS-каталога для домашней библиотеки: Lib2OPDS. На сервере есть директория, куда кладутся книги, а дальше по крону генерируется OPDS-каталог, который можно раздавать с помощью веб-сервера по вкусу.
Внезапно и странно с учётом позирования Хабра как сообщества IT-специалистов (https://company.habr.com/ru/) и возможности указать на несоответствие тематики при отметке минусом поста.
Спасибо за ссылку на комментарий!
Возможно, что сработал накопительный эффект, описанный в https://habr.com/ru/articles/883222/comments/#comment_27934622
Надеюсь, что команда Хабра наконец-то обратит внимание и таких статей станет меньше (или хотя бы будет работающий способ убрать их отовсюду из интерфейса при игноре автора).
Спасибо за ответы и в любом случае желаю удачи! :)
Кстати, на Хабре были также статьи про SecBP/БПИБ от ребят из Озона (https://habr.com/ru/companies/ozontech/articles/744524/).
Допустим, что у вас 5 вертикалей и каждый SecBP уходит отпуск хотя бы раз в год, тогда почти полгода основная команда будет вынуждена переключаться на решение задач соответствующего бизнес-юнита (и следовательно будет необходимость поддерживать знание в соответствующем домене). Как вы планируете решать эту проблему? Планируете ли возможность организовать команду под каждого SecBP?
По описании фичи часто можно спрогнозировать, что она в принципе будет рискованна. Следовательно можно и заложить под это полноценный анализ рисков (вместо фиксированного времени, которого просто может не хватить и будет пропущен действительно рискованный релиз).
В целом, любопытно было бы почитать такой же пост, но по прошествии 1-2 лет и, конкретно, про то, насколько много продуктовые команды вертикалей стали делать больше самостоятельно в плане ИБ (либо же SecBP стали для них ответом на все вопросы).
А что происходит, когда SecBP уходит в отпуск?
Этот результат немного отличается от декларируемого в статье:
"В целом инициатива оказалась крайне полезной. Мы достигли повышения прозрачности ситуации с безопасностью, улучшили процессы и повысили зрелость команд в вопросах ИБ.
Многие команды сильно поменяли свой mindset и стали относиться к ИБ не как к «необходимому злу», а как к надёжным помощникам, стали активнее давать обратную связь и делиться идеями по улучшению процессов ИБ. "
Часто размер задач достаточно сложно оценить, тем более в часах. У вас же получилось упаковать то же тестирование безопасности и исправление найденных уязвимостей в достаточно жесткие временные рамки. Рассматривали ли вы возможность сначала делать быструю сортировку фич с дальнейшим анализом рисков и уже на основе этого тестирование безопасности и т.д.? То есть идти от того, насколько потенциально рискованная фича, а не просто строго выделять время в неделю.
Спасибо за то, что поделились интересным опытом!
Не получилось ли так, что продуктовые команды по сути начали аутсорсить все вопросы безопасности в своих SecBP (и теперь надо как минимум иметь количество SecBP >= число команд) вместо того, чтобы осознать собственную ответственность за риски в разрабатываемых сервисах (и, как следствие, уделять больше внимание вопросам ИБ)? Стали ли продуктовые команды выполнять больше задач, относящихся к безопасности, после того как у них появлялся SecBP, но без его участия?
А почему вы решили это измерять, причем формально (в часах)?
Почему это рассматривается именно как "внешние" задачи, при том, что это по сути часть продукта?Например, если баги не будут исправлены, то может реализоваться риск соответствующей атаки (и инцидента). Этот риск может и быть принят в пользу расхода ресурсов на продуктовые фичи. И это решение продуктовой команды.
Зачем вы текст скриншотом вставляете?
Сделайте, пожалуйста, возможность добавлять авторов в чёрный список, чтобы скрывались их материалы со всех блоков Хабра, включая "Читают сейчас".
Тут мой парсер заголовка статьи сломался и я пошёл смотреть в спеку HTTP :)
Заголовок мог быть ещё лучше -- "Сёрфер-энтузиаст из Санта-Круса закрыл прибыльный магазин на
{маркетплейсе}, переехал жить в{например_хостел}и покорил 32-метровую волну. Как это у него получилось и в чём нюанс?". К сожалению, таких постов и новостей, теперь на Хабре становится всё больше.Прочитал в оригинале. Книга произвела впечатление хорошего обзорного (угроз) труда. Идея с отсылками к конкретным моментам и вообще к ЗВ понравилась, хотя и частенько, как мне показалось, это было "притянуто за уши".
С момента своего запуска Хабр эволюционировал из ресурса для обмена знаниями из мира информационных технологий (назовём это computer science) в гораздо менее специализированный сайт, который часто используется как генератор трафика или рекламная площадка. Ещё и добавили неотключаемые новостные блоки, чтобы ещё больше получить внимания. Проблема даже не в этой эволюции, а в том что альтернативы текущему Хабру, но с прежними принципами, так и не появилось (?) за это время. К тому же, всё-таки и сейчас бывают годные статьи тут.
Эта статья, к сожалению, вообще отвечает почти всем тенденциям последнего времени на Хабре:
кликбейтный заголовок
не относится к IT вообще
репост с другого ресурса, например VC
в посте куча картинок, часто и для кода
обязательно попытка в юмор и мемы, что само по себе и не так уж и плохо, но вопрос в уровне
в конце обязательно должне быть призыв подписываться на блог в Телеграме
Все эти млрд строк кода и десятки тысяч репозиториев (с кучей веток) выглядят как маркетинговые цифры и/или цифры, которые вы сами себе сгенерировали (как в случае со срабатываниями анализиторов). При этом сама AppSec платформа выглядит впечатляюще. Спасибо за интересную статью!
Хотелось бы побольше узнать о базовом процессе со стороны разработчика и безопасника: как буквально разработчик с этим взаимодействует и насколько это ухудшает (или улучшает) его жизнь? Security Gate скорее всего предполагает блокирование релиза на основе наличия High+ уязвимостей? То же самое и в контексте безопасника, особенно с учётом таких объёмов для триаджа.
Сорри за немного провакационный вопрос, но рассматривали ли возможность вообще не аггрегировать и не хранить результаты работы анализаторов, а показывать их только в контексте PR-ов?
Но ведь вам по факту уже не так важна интеграция с Джирой, сколько просто анализ текста на наличие секретов. Вы же всё равно сами забираете текст нужных тикетов и потом отдаете в ваш анализатор. Поэтому и подумалось, что вам мог бы подойти и какой-то из существующих анализаторов, который умеет в stdin принимать текст или же просто текстовые файлики анализировать.
Жаль. Выходит, что только мониторинг :(