Безусловно, поэтому этому надо учить не безопасников, а программистов PLC

Комитет ISA99 опубликовал обновленную презентацию с обзором серии стандартов ISA/IEC 62443 Security for industrial automation and control systems. Со статусом текущих активностей и планами

https://isaorg.sharepoint.com/:p:/s/Standards/ISA99/EcxWv8vUZ_FIj_PiOVPQZzoBGtsvDNx7GTzxUfQe-tsIrg?e=xC9Rko

Я думаю никаких центров нет, собственно и не нужно. Думаете, что программисты, которые хотят изучить новый язык, идут на какие-то условные курсы? Конечно нет. Достаточно прочитать несколько гайдлайнов, описание работы компилятора/интерпретатора и под рукой иметь мануал по синтаксису.
В конце концов предъявлять требования к безопасности надо к готовому продукту (по крайней мере системно, заказчик в принципе может установить дополнительные требования, но тут важно учитывать интеллектуальную собственность производителя), а не к исходному коду, который производитель в праве оставлять закрытым.

Ну хз, всякие Udemy, Coursera, Степик, etc популярны

Только отечественных производителей ПЛК и преподавателей не достаточно. Для эффективного контроля нужны SAST и DAST умеющие разбирать синтаксис ПЛК. Иначе получится как всегда, вот вам новые требования, методики будут через год/два, а средства реализации лет через 5-10, когда мы выпустим новые требования :)

Коллеги, в программах управления технологическими процессами гораздо важнее избегать ошибок обработки данных этих процессов и принятия конкретных решений, изменяющих текущее состояние системы. Об этом специалисты АСУТП говорят нам уже лет 10-15, но специалисты ИБ, конечно же, лучше разбираются в чужих предметных областях...

в обсуждаемой выше инициативе я вижу скрытое желание разработчиков средств защиты (ИБ) в очередной раз увеличить свою прибыль

Ни в коем случае. В разработке ПО много нюансов. И ИБ только один из них.

ряд инструментов статического контроля качества программного кода ПУ ПЛК встроен в инструментальное ПО (зависит, конечно, от производителя)

Конечно. Увеличение числа высококвалифицированных рабочих мест, налоги, ВВП.

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

Да. Но по классике все ИТ контроли в средствах разработки не относятся к вопросам ИБ, иначе не нужны были бы средства SSDLC. Хотя, возможно, средства разработки для ПЛК все учитывают :)

Еще раз обращу внимание. Хотя это видно когда читаешь описание и сам документ: Top 20 Secure PLC Coding Practices собирают специалисты по АСУ ТП. И они понимают что есть в отрасли на самом деле, а чего нет. Специалисты по ИБ этот проект поддерживают и продвигают. Что что тут мир и взаимопонимание. Не нужно искать и разжигать конфронтацию

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

Наброшу на вентилятор. ИМХО программирование ПЛК на 61131 доживает поледнее десятилетие. Его придумали когда были дохлые процессоры и бывшие электрики. Сейчас ситуация изменилась.

сейчас можно писать на JavaScript и Haskell?:)

В принципе можно, но это не причём

я видел реальные решения (контроллеры), где можно писать только на JavaScript

Увы пока не было предложено ни одного дельного инструмента по автоматизации проверок (на котором можно было бы заработать). Поэтому страно что вы видите скрытое желание разработчиков среда защиты.

Тренды приведут к визуальному программированию.