Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
Никогда не подумал бы что «fsquirt.exe» это часть винды. Кажется, я безнадежно испорчен.
История с fsquirt навеяла вот такое замечание: «Если из унитаза потекло, пустой тазик можно поставить… но может лучше канализацию починить»?
При внедрении SDL компания, сформирует что-то типа политики написания программного кода / разработки ПО.
Но для того, чтобы какие-либо требования работали, в том числе данная политика, нужен контроль их выполнения.
Как вы видите лучшую практику организации подобного контроля для небольших компаний, где есть 1-2 разработчика ПО и например 1 ИБист?
Но для того, чтобы какие-либо требования работали, в том числе данная политика, нужен контроль их выполнения.
Как вы видите лучшую практику организации подобного контроля для небольших компаний, где есть 1-2 разработчика ПО и например 1 ИБист?
Я считаю, что данный вопрос затрагивает достаточно широкую и интересную тему размером как минимум в новую статью, но постараюсь ответить вкратце.
Начать можно с Code Review тем же ИБ — шником, если он в силах делать ревью на выбранном языке. Для этого у него предварительно должен быть сформирован чеклист на ревью, определяющий, что конкретно он проверяет согласно сформированным требованиям (политики написания программного кода / разработки ПО).
Более простым выходом из ситуации будет использование как можно больше автоматизированных средств, готовых взять на себя некоторые обязанности по контролю. Ввиду небольшой команды их внедрение не займет много времени, но зато на длительной перспективе даст большой прирост в разработке и проверке.
В качестве примера, в том же Git можно воспользоваться Git Hooks. Настроить определенные проверки перед push-ом, например, стат анализ, запуск стороннего набора тестов или ту же проверку code style (если вы определили стиль).
По такому ревью некоторые интересные моменты можно почерпать в книге «Best Kept Secrets of Peer Code Review», а по Git Hooks много материалов на Хабре.
Начать можно с Code Review тем же ИБ — шником, если он в силах делать ревью на выбранном языке. Для этого у него предварительно должен быть сформирован чеклист на ревью, определяющий, что конкретно он проверяет согласно сформированным требованиям (политики написания программного кода / разработки ПО).
Более простым выходом из ситуации будет использование как можно больше автоматизированных средств, готовых взять на себя некоторые обязанности по контролю. Ввиду небольшой команды их внедрение не займет много времени, но зато на длительной перспективе даст большой прирост в разработке и проверке.
В качестве примера, в том же Git можно воспользоваться Git Hooks. Настроить определенные проверки перед push-ом, например, стат анализ, запуск стороннего набора тестов или ту же проверку code style (если вы определили стиль).
По такому ревью некоторые интересные моменты можно почерпать в книге «Best Kept Secrets of Peer Code Review», а по Git Hooks много материалов на Хабре.
По заголовку решил, что это статья про game dev,
т.к. SDL довольно известная в узких кругах библиотека: http://www.libsdl.org/
Вот кстати, хороший вопрос. Как это всё правильно называть аббревиатурой? Мы говорим про Secure Software Development LifeCycle. Тогда получается: SSDLC? SSDL? Secure SDL? Secure SDLC? Тьма вариантов в интернетах.
Но vas-v сказал, что Microsoft и Cisco используют «SDL» (Security DL), поэтому решили, что будем писать SDL.
Но vas-v сказал, что Microsoft и Cisco используют «SDL» (Security DL), поэтому решили, что будем писать SDL.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Жизнь без SDL. Зима 2017