IT-стандарты *

Прямо сейчас я заметил, что моя статья получила дизлайк, и карма упала на два пункта.

На Хабре немало публикаций в духе: «Я попал в Яндекс, смотрите какой я крутой».
В них - ноль пользы и никакой информации.
Другие материалы поражают скомканностью и поверхностностью.

Я заметил любопытную закономерность: чем больше пустых слов и ерунды выливает автор, тем больше лайков он получает. Для примера: свою статью об опыте работы я написал наспех, без особого старания - и она спокойно прошла по показателям. А когда действительно стараешься, вкладываешь силы, результатом становится минус карма.

Особенно неприятно, когда у человека аккаунт с накрученной кармой: он сидит, поливает всех грязью, сам при этом ничего полезного для сообщества не сделав.

И вот я думаю: стоит ли вообще делиться знаниями на этой площадке, если здесь хватает людей, которые портят атмосферу? Может, есть достойные альтернативы Хабру?

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

Я целый день правил статью, перечитывал материалы, улучшал подачу - и в итоге получил такую обратную связь. При этом моя статья (и не одна) пробилась в топ Google и Яндекс-поиска, где информации по этой теме почти нет в таком разжёванном виде.

Я пока новичок здесь, хотя у меня есть друзья, которые уже обжигались на Хабре и в итоге просто плюнули на него, перестав публиковать материалы. Поэтому особенно интересно услышать опыт других участников.

Хочу осветить эту проблему хотя бы пока есть карма.
Уже видно, как работает эта система.

Ты, читатель, знаешь, сколько труда стоит такой материал?
Сколько сил уходит на его подготовку?
И если ты думаешь, что это сгенерировано ИИ - то ошибаешься.
Настоящая работа всегда отличается от «сырых» статей без структуры.

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

Обновление платформы SimpleOne 1.34.0 ускоряет реакцию на критичные события и снижает риски внутренних аудитов

Новая функциональность платформы SimpleOne помогает быстрее отрабатывать критичные события и снижать риски при внутренних проверках.

Что нового:

• Нативные push‑уведомления в браузер
  Оповещения приходят напрямую в поддерживаемые браузеры на разных устройствах, без зависимости от почты и мессенджеров.

• Форматирование теперь и там, где был только простой текст
  Лента активности перешла со стандартного текстового поля на визуальный редактор (WYSIWYG): форматирование, списки, ссылки и изображения; ранее созданные сообщения отображаются без изменений. А существующие колонки типа Text администратор может перевести на такой же редактор с сохранением данных — раньше для этого пришлось бы создавать новое поле и переносить значения вручную.

• Роль «Аудитор»
  Даёт полный доступ на чтение ко всем таблицам на уровне администратора, но без права редактирования. Это упрощает проверки и расследования и поддерживает принцип разделения обязанностей.

«Мы последовательно закрываем те точки, где промедление и непрозрачность обходятся бизнесу дороже всего. В 1.34 это два прямых ответа: критичное событие доходит до исполнителя сразу, а не когда он откроет почту, а проверяющий получает доступ на чтение ко всем данным без права что-либо изменить — раньше ради этого приходилось выдавать избыточные права», — Илья Радченко, директор по платформенным продуктам SimpleOne, корпорация ITG

Подробнее о платформе SimpleOne
Техническая документация

SimpleOne выпустила версию ITSM 2.0.0 с ИИ-помощником на сервисном портале

Теперь в SimpleOne ITSM есть ИИ-помощник на портале самообслуживания. Пользователь пишет запрос в свободной форме, ИИ понимает контекст, находит нужную услугу или статью, подготавливает форму обращения.

СМОТРЕТЬ ВИДЕО

Что меняет ИИ-помощник:

• Для бизнеса — типовые вопросы закрываются через самообслуживание, известные проблемы не порождают повторные инциденты, а сложные обращения приходят к специалистам сразу с заполненными полями и полным контекстом. Нагрузка на первую линию снижается без роста штата.

• Для сотрудников и клиентов — портал становится понятнее: достаточно описать ситуацию своими словами, и помощник сам найдёт ответ, подберёт услугу или подготовит форму обращения.

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

И это работает не только для ИТ — помощник одинаково применим к HR, бухгалтерии, юридическому отделу и любому сервисному подразделению.

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

Андрей Вишняков, директор по бизнес-продуктам компании SimpleOne, корпорация ITG, ITIL 4 Master, ITIL 3 Expert, Practitioner, автор РИТМ

Что ещё изменилось в ITSM 2.0:

• База известных ошибок (KEDB) вынесена на портал — пользователи сами находят обходные решения до создания тикета

• Комментарии из мессенджеров и почты подтягиваются прямо в обращение

• Появилась возможность оставить заметку ко всем обращениям при их массовом завершении

• На форме инцидента появился виджет сервисных отношений

• Автозаполняемые поля дочерних инцидентов защищены от случайного редактирования

Подробнее о SimpleOne ITSM
Техническая документация

AI-Иллюзия: Фейковый успех в NYT и надувающийся пузырь на Уолл-стрит

Мы живем в эпоху AI-помешательства. С одной стороны, СМИ рисуют сказки о миллиардных империях, построенных одним человеком за ночь. С другой крупнейшие аналитики бьют тревогу: индустрия превратилась в финансовый пузырь, обреченный на коллапс. Две стороны одной медали: отсутствие проверок ради хайпа.

Сказка про $1.8 миллиарда

В апреле The New York Times опубликовала вдохновляющий текст о MEDVi: телехелс-стартап с двумя сотрудниками и кучей нейросетей якобы сделал $401 млн выручки с прогнозом в $1.8 млрд. Подача живое подтверждение слов Сэма Альтмана про «компанию на миллиард от одного основателя».

Проблема в том, что NYT забыла погуглить факты. За шесть недель до публикации FDA пригрозило MEDVi конфискацией за незаконный маркетинг лекарств. За 13 дней подали коллективный иск за спам-рассылки. А тысячи рекламных объявлений компании велись от имени вымышленных врачей (включая «Professor Dongledore»).

Более того, $1.8 млрд — это не оценка компании (valuation), а самозваный прогноз выручки без единого аудита. NYT намеренно утопила эту оговорку в конце текста ради кликабельного заголовка.

Опасный миф «один человек заменил команду»

История MEDVi идеальная иллюстрация того, как СМИ не понимают суть технологий. ИИ это мультипликатор. В MEDVi он умножил не эффективность, а хаос: чатбот выдумывал цены на лекарства, нейросети генерировали фейковых врачей, автоматизация стала спам-машиной.

Галлахер не заменил врачей или юристов он просто отключил контроль качества. Это не новая бизнес-модель, а классический обман, масштабированный ИИ. Точно так же, как "вайб-кодинг" дает приложение без тестов, которое развалится при первых ста пользователях.

От микро-обмана к макро-пузырю

Эта микро-история симптоматична для макро-рынка. Goldman Sachs, McKinsey и Gartner уже признают: AI-пузырь — надвигающаяся катастрофа.

Факты сухи: по данным BCG, лишь 5% компаний получают от ИИ реальную выгоду, половина GenAI-проектов проваливается. Возникла круговая схема: инвесторы дают деньги Big Tech те инвестируют в стартапы (OpenAI) стартапы покупают мощности у Big Tech акции растут. Конечного потребителя, готового окупить эти триллионы, в цепочке нет.

Индустрия села на иглу долгов. Oracle влезла в дата-центры на сотни миллиардов и потеряла половину капитализации. OpenAI рапортует о $20 млрд выручки, но скрывает хроническую убыточность. Участники гонки не могут остановиться: чтобы оплачивать старые долги, нужно брать новые, убеждая инвесторов, что «завтра всё окупится». Аналитики открыто сравнивают это с ипотечным кризисом 2008 года.

Скучное будущее

Первая волна любой революции токсична. Pets.com обанкротилась, но пришел Amazon. Настоящие успешные AI-компании не попадут на обложки NYT. Они будут скучными: с жестким комплаенсом, кросс-модельными проверками, тестами и независимым аудитом.

Итог один: авось не стратегия. AI мощный инструмент, но без контроля он становится не магией, а ускорителем катастрофы. Проверяйте факты, даже если источник — The New York Times.

SimpleOne подтвердила совместимость с РЕД ОС

SimpleOne подтвердила совместимость своей платформы с РЕД ОС. Для заказчиков это значит, что запуск проектов в импортонезависимой ИТ-среде становится проще и предсказуемее.

Подтвержденная совместимость помогает:

• сократить барьеры на этапе архитектурных согласований

• упростить прохождение аудитов безопасности

• быстрее запускать проекты по переходу на российское ПО

РЕД ОС широко используют в корпоративной и государственной инфраструктуре. По данным разработчика, систему уже применяют 12 000 компаний и государственных организаций, а общее количество инсталляций превысило 2 млн.

Подробнее на сайте

ГОСТ Р 56939-2024 на практике: что мы сделали, чтобы получить сертификат РБПО

🔎 Контекст
У Cloud.ru есть платформа, созданная специально для заказчиков, которые обязаны соблюдать особые требования к хранению данных и разработке ПО. Вся инфраструктура, которую они используют, должна быть аттестована на соответствие стандартам безопасности, а платформенные сервисы должны пройти жесткую проверку у регуляторов. Ранее платформа уже получала сертификат ФСТЭК России №4979, но при внесении определенной массы изменений в продукт, процесс требуется пройти заново, а сделать это невозможно без привлечения сторонней лаборатории и многомесячных ожиданий. Чтобы иметь возможность развивать продукт более оперативно, требовалось сертифицировать не только платформу для создания частного, гибридного или распределенного облака Cloud.ru Evolution Stack, но и все процессы вокруг нее, т.е. подтвердить соответствие ГОСТу Р 56939-2024.

🚀 Задача
Стандарт требует выстроить 25 взаимосвязанных регламентов и поддерживать более 200 артефактов в актуальном состоянии постоянно. Но этого мало: ведь стандарт есть, но конкретной методологии его реализации не существует, нужно было приземлить элементы процесса на орг.структуру нашей компании. Осложнялось всё тем, что в любой крупной ИТ-компании команды непрерывно перетасовываются, ответственные меняются, а любое кадровое изменение должно быть тут же отражено во всей документации сразу.

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

☁️ Что мы сделали
Применили существующую в компании BPM-систему как единый источник правды: описали в ней ключевые процессы РБПО, зафиксировали роли, связали их с командами через орг.структуру, разместили все артефакты, точки контроля и указали их взаимосвязи. Следующим этапом автоматизировали конвертацию и публикацию свежих документов: по расписанию из BPM-модели экспортируется HTML, который автоматически конвертируется в Markdown и публикуется во внутреннюю Wiki. Изменился владелец роли — один раз вносишь правки в BPM, все документы актуализируются и тут же становятся доступны всем и каждому. Чтобы новички не впадали в ступор от количества регламентов, поверх Wiki добавили ассистента с RAG под капотом. Можно написать в корпоративный чат любой вопрос и получить структурированную информацию о том, кто за что отвечает и как действовать в любой ситуации, причем сразу со ссылками на конкретный документ в базе знаний. 

🦾 Что получили в итоге
В компании появилась полная живая и взаимосвязанная база элементов, включающая организационные единицы, роли, артефакты и инструкции по процессам. То есть на аудите мы показываем не просто набор Word'овских файлов, а живую модель с автоматически собранными артефактами. Каждый сотрудник, причастный к процессу безопасной разработки ПО, четко знает, что в какой ситуации делать и уверен в том, что данные не устарели. ИИ-ассистент сокращает время погружения в регламенты и процессы с дней до пары десятков минут, что значительно упрощает онбординг при смене роли. 

Также такой подход позволил снизить затраты на устранение уязвимостей, поскольку их выявление предусмотрено на самых ранних стадиях процесса. Мы получили подтверждение качества платформы и стали первым облачным провайдером в России с сертификатом РБПО. У нас появилось больше контроля над собственным релизным циклом и теперь мы можем планировать обновления на годы вперед. 

🧠 Рефлексия
Можем смело рекомендовать аналогичный пайплайн командам, которые: 

• сами готовятся к сертификации процессов РБПО;

• хотят упростить адаптацию сотрудников на новых ролях; 

• хотят убрать «слепые зоны» из разработки;

• ищут способ более предметно демонстрировать работу руководству или инвесторам. 

О невольной индивидуализации идентифицированных доменов

Уже много написано о деанонимизации администраторов доменов и прочих прелестях жизни. Расскажу о главной прелести при идентификации доменов переходящих подобно красному знамени с регистратора Р01. Один непоименованный продавец доменов, которым я был вполне доволен в последние 10 лет внезапно признался, что неаккредитован для идентификации доменов и их надо своим пешком в nic.ru заносить и там идентифицировать. Веселье заключается в том, что nic.ru открывает новый договор каждый раз когда делается попытка идентификации домена.

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

Я задал этот вопрос техподдержке nic.ru и она его обдумывает уже вторую неделю, не отвечая ни на письма по этому поводу, ни на сам тикет.

Второй забавный нюанс -- на каждый домен nic.ru прислал мне отдельное письмо с требованием идентификации. Интересно, а сколько писем они послали массовым регистраторам доменов? Им тоже по-одному домену на договор будут открывать?

ESM VS ITSM: что выбрать, когда начинать проект и как обосновать бюджет

Вебинар 24 июня, 12:00 по мск

В крупных компаниях большинство запросов от сотрудников приходят не в IT-отдел, но автоматизацию при этом чаще всего начинают именно с IT-услуг.

Наладив работу с обращениями в IT-отделе, компании начинают приводить в порядок работу с заявками, которые поступают в другие подразделения: HR-департамент, АХО, юридическую службу, бухгалтерию. Это новые проекты внедрения, требующие новых бюджетов, которые приходится каждый раз заново согласовывать.

Компании, которые при автоматизации IT-услуг, закладывают в проект внедрения ITSM масштабирование до ESM, экономят колоссальные ресурсы, окупают внедрение быстрее и получают конкурентное преимущество. К тому же поддержка одной системы обходится IT-департаменту значительно дешевле, чем управление разрозненным IT-ландшафтом для бухгалтерии, АХО, HR и др. отделов. Но как доказать это руководству и обосновать бюджет на комплексную автоматизацию?

На вебинаре мы рассмотрим, как единая платформа SimpleOne работает для разных отделов и как сквозные процессы экономят время. Представим кейсы внедрения ESM-системы. Покажем калькулятор экономической ценности внедрения ESM, который поможет определить возможную окупаемость проекта.

В программе:

Отличие ESM от ITSM

Преимущества ESM и почему внедрение ESM актуально сейчас

ESM-система на платформе SimpleOne

Успешные кейсы внедрения SimpleOne ESM

Подходы к реализации проекта внедрения ESM

Формирование бюджета на проект и расчет экономического эффекта от внедрения ESM

Спикеры:

Илья Жакашев, коммерческий директор SimpleOne

Алексей Лыков, руководитель направления ESM Softline

Регистрация

Страх как продукт: почему мы до сих пор продаём ужас вместо ценности

Рынок ИБ до сих пор продаёт не защиту, а спокойный сон до следующего квартала. Страх стал валютой - от отчётов «80% компаний под угрозой» до тепловых карт, где всё красное. Ниже — ещё более сжатая выжимка: как устроена эта машина страха и чем её заменить.

Как страх стал главным продуктом:

Доказать эффект от ИБ трудно: мало данных, спорные методики, внутренняя политика сильнее формул. В результате страх стал универсальным инструментом: случился инцидент - рынок завален продуктами и отчётами «как раз от такой угрозы».

Классика жанра:

• Вирус уровня WannaCry использует старые уязвимости, но продаётся как «новая эра вымогателей и уникальных защит».

• Отчёты «80% компаний под угрозой» строятся на кривых опросах своей аудитории и заканчиваются «запросите демо/пилот».

FUD даёт краткосрочное внимание, но в долгую убивает доверие и либо ведёт к хаотичным покупкам «серебряных пуль», либо к апатии: всё кажется одинаково страшным.

Чеклист для CISO:

На любую страшилку ответьте:

1. Какой конкретный сценарий атаки описан?

2. Какова вероятность и ущерб именно для нашей компании?

3. Что изменится в нашей модели угроз, если мы это купим/внедрим?

Если хотя бы на один пункт ответа нет - это продажа эмоции, а не безопасности.

Иммунитет CEO и красные тепловые карты:

У многих CEO уже аллергия на FUD-слайды «Россия в топ‑3 по атакам» и «каждая вторая компания пострадала».В ответ безопасники приносят тепловые карты, где половина клеток ярко‑красные.

Что реально происходит:

• Красный цвет мгновенно бьёт по инстинктам, один слайд перекрывает пачку таблиц.

• Но карта «всё красное» без чисел - это эмоциональный шантаж ради бюджета, а не управление рисками.

Что можно поправить быстро:

• У каждой «красной зоны» должны быть: сценарий, диапазон потерь и время простоя.

• Вместо абстрактных рейтингов - 2–3 реально возможных для вашего бизнеса кейса с понятными цифрами.

Медиа и «исследования»: аналитика или хоррор:

ИБ‑медиа и вендорские отчёты - крупная шестерёнка машины страха.
По оценкам редакторов, 90–95% исследований делаются ради продвижения продукта: методика мутная, цифры разных отчётов по одной теме могут расходиться на порядки.

Полезно:

• Читать аналитику по реально эксплуатируемым уязвимостям и zero‑day в массовых продуктах.

• Разборы реальных инцидентов - их мало, но именно они меняют практику.

Вредно:

• Разгонять фейки, неподтверждённые сливы и «80% под угрозой» без описания выборки.

Фильтр для отчётов

Один вопрос: «Эта цифра способна изменить наше решение?»
Если нет - перед вами маркетинг, а не аналитика.

Регулятор против хакера: чей страх сильнее:

У российского заказчика два фронта: хакеры и регулятор.

Факты:

• 60–70% бюджетов ИБ уходит на комплаенс (приказы, ГОСТы, 152‑ФЗ, отраслевые требования).

• Остаток - на «живую» защиту: SOC, мониторинг, сегментацию, реагирование.

Почему страх регулятора побеждает:

• Атака - вероятностна, может и не случиться.

• Проверка - гарантирована, с датой и понятными санкциями.

• Мини-действие

  • Разложите бюджет на «комплаенс» и «реальную защиту».

  • В каждый комплаенс‑проект заложите хотя бы одну меру, которая действительно снижает риск.

  Как уйти от продажи страха к продаже ценности:

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

  На практике:

  • Переводите «страшно» в «сколько стоит и что конкретно делаем в ответ».

  • Привязывайте ИБ к бизнес‑метрикам: простои, выручка, операционные издержки, скорость изменений.

  • Используйте новости и инциденты как материал для обучения и улучшений, а не как повод продавить очередную «серебряную пулю».

  Если вы:

  • Перепишете одну ключевую презентацию, убрав хоррор и добавив сценарии с деньгами.

  • Хоть раз в неделю спросите команду: «Мы сейчас управляем риском или реагируем на хорошо проданный страх?» - значит, вы уже выходите из режима «страх как продукт» и начинаете говорить с бизнесом на взрослом языке.

  А у вас решения по ИБ сейчас чаще объясняют «по регулятору надо», «видели страшный кейс» или нормальным разговором про риски и деньги?

Как понять до внедрения, станет ли Low-code платформа точкой роста?

На старте почти любая No/Low-code система, основанная на платформе, выглядит удобно: быстрый запуск, простые сценарии, минимум разработки.

Проблемы начинаются позже, когда нужны нестандартная логика, интеграции и масштабирование. Тут часто выясняется, что у платформы есть потолок:

• бизнес снова идет в очередь к разработчикам

• растет зависимость от вендора

• доработки становятся дорогими и медленными

В новом интервью для TAdviser Илья Радченко, директор по платформенным продуктам SimpleOne, рассказал, как проверить поставщиков платформенных решений.

Полезный материал для тех, кто выбирает платформу не под пилот, а на несколько лет вперед.

Читать материал

Три подразделения, три правды. Куда уходит ИТ-бюджет и при чём тут ITAM

Бухгалтерия: «3000 на балансе». ИТ: «1800 в сети». Безопасность: «2200 под защитой». И никто не врёт — каждый считает свой срез.

Корень проблемы — не сами расходы, а отсутствие единой экономической модели ИТ. CFO видит строку «50 млн руб./год» без детализации. CIO знает, что серверы на грани, но не может перевести это на язык финансов. Бизнес требует цифровизации, не понимая нагрузки на бюджет.

При этом контекст 2024–2026 усложнил всё кратно: параллельный импорт — плюс 20–40% к закупкам, импортозамещение — рост годового бюджета на 40–70% не за счёт расширения, а за счёт выкупа лицензий в альтернативных стеках. Компании тратят миллионы на ПО «про запас», которое не используют прямо сейчас.

Если раньше мы платили 10 млн руб./мес. за подписку M365, то сейчас вынуждены держать 50 млн руб. единовременного резерва на закупку ПО в реестр, плюс 15 млн руб./мес. на доработку интеграций.

Алексей Бородин, эксперт по развитию ITAM- и ITSM-проектов

Совместно с практикующими экспертами по ITAM и ITSM мы подготовили материал о том, как IT Asset Management помогает сделать ИТ-затраты прозрачными и управляемыми.

Внутри:

• Анализ ключевых вызовов 2024–2026: санкции, переход от OPEX к CAPEX, рост НДС, дефицит ИТ-специалистов

• Почему Excel, ERP, ITSM с CMDB и BI-системы перестают справляться с управлением затратами — и где у каждого инструмента потолок

• Системный подход к управлению ИТ-активами через ITAM — на примере SimpleOne ITAM

• Кейс ITGLOBAL.COM (by ITG): переход с Excel на ITAM в международной структуре с присутствием в 12 странах

• Чек-лист «Как сделать ИТ-затраты управляемыми»: 4 шага + методика расчёта TCO и ROI

📎 Скачать материал

Как людям на самом деле НРАВИТСЯ нейрослоп. В том числе на Хабре.

Я изредка делаю кросспосты заметок из своего тг-канала в threads и на хабр, чтобы выйти из пузыря умных читателей канала. На хабре очевидно короткие посты вместо статей не заходят. Более того, мои плотные посты с нумерацией почти каждый раз обвиняли в AI слопе (хотя конечно это несправедливо).

"Ну ладно!" подумал я. Сделал эксперимент: взял один из недавних постов про статистику фейковых гитхаб-звезд, попросил клод "распиши до размеров небольшой статьи", убрал буквально пару формулировок и просто опубликовал на хабре: https://habr.com/ru/articles/1025032/

Статья вошла в топ-5 за день 🥲

То есть текст стал очевидно ХУЖЕ, но людям понравился больше. Никто не поставил минус за подозрение на нейрослоп (там можно видеть причины). А редакторы хабра добавили статью в соцсети (включая тг канал), чего ни разу не случалось с моими кросспостами.

Уверен, что если еще поработать с ллм, типа добавь фактуры, вот отсюда добавь инсайты и т.д. то это могла бы быть топовая статья (тема-то хорошая). Наверное можно и твит так расписать.

Короче говоря, можно смеяться над откровенным AI слопом, но я уверен, что чуть более сложный мы уже читаем каждый день, даже не замечая этого.

РБПО по ГОСТ Р 56939—2024: вебинар №16 из 30 – Использование инструментов композиционного анализа

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.16. – "Использование инструментов композиционного анализа". На YouTube. Слайды.

Цели 16-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

РБПО по ГОСТ Р 56939—2024: вебинар №12 из 30 – Использование безопасной системы сборки программного обеспечения

Команда ООО "ПВС" совместно с Виталием Пиковым из учебного центра "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.12. – "Использование безопасной системы сборки программного обеспечения". На YouTube. Слайды.

Цели 12-го процесса по ГОСТ Р 56939—2024:

Обеспечение безопасности при сборке ПО, недопущение привнесения в код ошибок, обусловленных небезопасными преобразованиями кода.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации, подготовленная Андреем Карповым, доступна по ссылке: ГОСТ56939.РФ.

P.S. Мы регулярно проводим вебинары на различные темы, не обязательно связанные с РБПО. У нас появился подкаст «Разбаговка»! Приглашаем слушать и принять участие в качестве гостя.

С ростом популярности данного сообщества G, средний уровень интеллекта этого сообщества приближается к среднему по популяции. Это выведенная мной аксиома, о которой очень важно знать сегодня людям, находящимся в поиске ассиметричного превосходства на рынке чего угодно.

То есть, либо сообщество умных людей глупеет с ростом популярности, либо движение шизов умнеет с ростом популярности.
На рассвете программирования, в 20-м веке, по существующим данным, средний IQ был 130 у типичного нерда в этом деле. По существующим данным опять же, где-то в 2011, и чуть позже, средний уровень интеллекта программиста упал до 115. В 2025 году он упал до 105(это по миру).

Об исходящих леммах хоть книгу пиши. Правило №1 - если нет собственного мнения, то слушать стоит только дедов. Исключения из этого правила конечно же существуют, но пока нет понимания, их остаётся только игнорировать

РБПО по ГОСТ Р 56939—2024: вебинар №10 из 30 – Статический анализ исходного кода

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.10. – "Статический анализ исходного кода". На YouTube. Слайды.

Цели десятого процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Рассмотрение 10-го процесса в ГОСТ Р 56939—2024 неразрывно связано с другим ГОСТ Р 71207—2024 "Статический анализ программного обеспечения". В нём говорится о том же, только более подробно и конкретно.

Про ГОСТ Р 71207—2024 я отдельно рассказывал в цикле из пяти вебинаров:

1. Общее описание и актуальность;

2. Терминология;

3. Критические ошибки;

4. Технологии анализа кода;

5. Процессы.

Разрабатываемый нами анализатор кода PVS-Studio совместим с ГОСТ Р 71207—2024 и закрывает 10-й процесс ГОСТ Р 56939—2024 для языков C, C++, C#, Java. Сейчас в процессе реализации поддержка языков Go, JavaScript, TypeScript. Попробовать PVS-Studio.

Как SimpleMES создала универсальную MES-систему на базе платформы SimpleOne за 1,5 года

По мере работы с MES-проектами команда сталкивалась с типичными проблемами:

• Каждое внедрение превращалось в отдельный проект

• Рос технический долг

• Решения было сложно масштабировать

• Зависимость от узкоспециализированных разработчиков тормозила развитие

Рынку не хватало универсального платформенного решения — приходилось либо дорабатывать системы под каждую отрасль, либо использовать несколько вендоров.

Решением стало создание собственного продукта на базе единой технологической платформы SimpleOne.

Платформа позволила сразу заложить ключевые требования: гибкость Low-code, возможность глубокой кастомизации через Pro-code, масштабируемость и независимость от редких специалистов.

Команда использовала полный стек возможностей платформы: workflow, кастомные скрипты, API, очереди сообщений и собственные виджеты.

«История создания SimpleMES для нас показательна: она демонстрирует настоящую универсальность и потенциал платформы. Команда смогла построить промышленную MES‑систему без опоры на узкоспециализированный стек, используя только Low‑code инструменты и архитектуру SimpleOne. Такие возможности помогают бизнесу запускать сложные продукты быстро, системно и без чрезмерных затрат — на единой платформе, которая изначально создавалась не только для сервисных процессов, но для любых бизнес‑процессов и корпоративных приложений»

Илья Радченко, Директор по платформенным продуктам SimpleOne

О результатах и дальнейших планах развития читайте в кейсе на сайте

У вас был опыт внедрения MES или других производственных систем?

ESM-платформа SimpleOne 2.1.1: автоматизация многоязычной коммуникации и улучшение управления зависимостями

SimpleOne выпустила версию 2.1.1 ESM-платформы с двумя ключевыми обновлениями:

Ресурсно-сервисная модель:

• Строится на основе классов CMDB и настраиваемых правил связывания

• CMDB на расширенной модели данных REM позволяет гибко описывать конфигурационные единицы

• Добавлен справочник правил и типов связей с настройкой визуального отображения

• Выделен класс «Услуга» для связи бизнес-сервисов с инфраструктурными ресурсами

• Система автоматически исключает некорректные связи, дубли и циклические зависимости

• Готовая модель зависимостей для импакт-анализа снижает число аварийных изменений и откатов

Смотреть видео

Мультиязычные объявления:

• Новый виджет для создания объявлений на разных языках системы

• Автоматическое определение языка пользователя и отображение контента

• При отсутствии перевода показывается язык по умолчанию

• Централизованное хранение и автоматическое обновление переводов обеспечивают целостность данных

Смотреть видео

Узнайте больше об обновлении 2.1.1
Техническая документация

SimpleOne выпустила платформу 1.32.0: быстрые переносы конфигураций, точнее SLA, удобная работа с каталогом услуг

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

Главное в 1.32.0:

1. Перенос больших пакетов настроек между средами (разработка → тест → прод) теперь идёт в фоновом и не блокирует систему — можно переносить даже пакеты от 100 000 записей

2. Новый виджет для контроля таких переносов:
   кто запустил, на каком этапе, ссылки на детали

3. SLA-таймеры теперь учитывают паузы, которые случились ещё до старта замера:
   отчёты становятся точнее, особенно при миграции данных из других систем

4. К каждому типу запроса в каталоге услуг можно привязать свой рабочий процесс без условной логики и дублирования

5. Зависшие фоновые задачи восстанавливаются за 1 минуту вместо часа

6. Исправлены ошибки миграции, работы клиентских скриптов и усилена безопасность интеграции с LDAP

Узнайте больше об обновлении 1.32.0
Техническая документация

РБПО по ГОСТ Р 56939—2024: вебинар №04 из 30 – Управление конфигурацией программного обеспечения

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.4. – "Управление конфигурацией программного обеспечения". Слайды.

Цели четвёртого процесса по ГОСТ Р 56939—2024:

5.4.1.1 Осуществление уникальной идентификации ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).

5.4.1.2 Контроль реализации изменений ПО, документации на ПО, других элементов, подлежащих отслеживанию в рамках управления конфигурацией ПО (элементов конфигурации).

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

P.S. При разработке регламента идентификации ПО (версий ПО, модулей ПО) можно оттолкнуться от ГОСТ 19.103—77 "Единая система программной документации. Обозначение программ и программных документов".