Скорее всего да, но тут существует много различных факторов, которые обговариваются до начала работ. Если мы говорим про проникновение на периметр склада, то договор для охранника можно подделать. Верить на одну подпись директора не совсем есть гуд.
Я считаю, что данный вопрос затрагивает достаточно широкую и интересную тему размером как минимум в новую статью, но постараюсь ответить вкратце.
Начать можно с Code Review тем же ИБ — шником, если он в силах делать ревью на выбранном языке. Для этого у него предварительно должен быть сформирован чеклист на ревью, определяющий, что конкретно он проверяет согласно сформированным требованиям (политики написания программного кода / разработки ПО).
Более простым выходом из ситуации будет использование как можно больше автоматизированных средств, готовых взять на себя некоторые обязанности по контролю. Ввиду небольшой команды их внедрение не займет много времени, но зато на длительной перспективе даст большой прирост в разработке и проверке.
В качестве примера, в том же Git можно воспользоваться Git Hooks. Настроить определенные проверки перед push-ом, например, стат анализ, запуск стороннего набора тестов или ту же проверку code style (если вы определили стиль).
По такому ревью некоторые интересные моменты можно почерпать в книге «Best Kept Secrets of Peer Code Review», а по Git Hooks много материалов на Хабре.
Полностью согласен, но в данном контексте починить это может только Microsoft. В терминах вашей аналогии лучше поставить «тазик», пока ждёшь, когда «приедут и починят».
Скорее всего да, но тут существует много различных факторов, которые обговариваются до начала работ. Если мы говорим про проникновение на периметр склада, то договор для охранника можно подделать. Верить на одну подпись директора не совсем есть гуд.
В рамках некоторых работ таких сотрудников тоже проверяют. Другими словами проверяются не только технологии но и люди.
Цель статьи обсудить проблему, а не тыкать в коллег по сфере.
Что если не секрет подразумевается под внутренней безопасностью?) И причём тут СЗИ?
Начать можно с Code Review тем же ИБ — шником, если он в силах делать ревью на выбранном языке. Для этого у него предварительно должен быть сформирован чеклист на ревью, определяющий, что конкретно он проверяет согласно сформированным требованиям (политики написания программного кода / разработки ПО).
Более простым выходом из ситуации будет использование как можно больше автоматизированных средств, готовых взять на себя некоторые обязанности по контролю. Ввиду небольшой команды их внедрение не займет много времени, но зато на длительной перспективе даст большой прирост в разработке и проверке.
В качестве примера, в том же Git можно воспользоваться Git Hooks. Настроить определенные проверки перед push-ом, например, стат анализ, запуск стороннего набора тестов или ту же проверку code style (если вы определили стиль).
По такому ревью некоторые интересные моменты можно почерпать в книге «Best Kept Secrets of Peer Code Review», а по Git Hooks много материалов на Хабре.