S
Size: a a a
2021 March 12
C
Jeff Campbell, код неверный, обратись к админу.
2021 March 13
ДП
патент facebook позволяет связать смартфон с его владельцем по царапинам на объективе камеры, которые оставляют след на всех загруженных в соцсеть фотографиях – незаметный для глаза, но уникальный, как папиллярные линии и все твои трещинки
https://bit.ly/2PTaa9v
https://bit.ly/2PTaa9v
Потому что могут))
Интересно разобрать за счёт чего/как они определяют эти царапины.
Интересно разобрать за счёт чего/как они определяют эти царапины.
A
Потому что могут))
Интересно разобрать за счёт чего/как они определяют эти царапины.
Интересно разобрать за счёт чего/как они определяют эти царапины.
наверно принцип действия схож с отпечатками пальцев. Хотя интересно: если поверх царапины наложить еще больше царапину – он перестанет ее определять?
ДП
наверно принцип действия схож с отпечатками пальцев. Хотя интересно: если поверх царапины наложить еще больше царапину – он перестанет ее определять?
Там инкрементальный эффект должен быть
A
тема дня: как вести себя при визите полиции
https://pikabu.ru/story/k_zhitelyu_ekaterinburga_prishla_politsiya_za_poseshchenie_im_podozritelnyikh_saytov_8072177
как в истории - не надо
https://pikabu.ru/story/k_zhitelyu_ekaterinburga_prishla_politsiya_za_poseshchenie_im_podozritelnyikh_saytov_8072177
как в истории - не надо
М
А копаться в телефоне без постановления суда законно? И вообще, вламываться в квартиру и в чем-то там обвинять...
S
Всем привет. Подскажите, здесь есть кто-то кто занимается интеграцией security в процесс разработки? Поделитесь, пожалуйста, опытом постановки требований.
Как лучше ставить требования по security к user stories?
Как быть с требованиями которые повторяются из стори в стори?
Из чего нужно формировать глобальный список требований?
Про это есть много теоретической информации, но когда дело доходит к практике - много неопределенности. Спасибо!
Как лучше ставить требования по security к user stories?
Как быть с требованиями которые повторяются из стори в стори?
Из чего нужно формировать глобальный список требований?
Про это есть много теоретической информации, но когда дело доходит к практике - много неопределенности. Спасибо!
Ну я например работаю этим (ssdlc).
Вопрос слишком поверхностный.
Для начала можно изучить материалы owasp, а потом по мере просветления нюансы изучать
https://blog.sonatype.com/owasp-security-knowledge-framework
Вопрос слишком поверхностный.
Для начала можно изучить материалы owasp, а потом по мере просветления нюансы изучать
https://blog.sonatype.com/owasp-security-knowledge-framework
S
Привет 👋
Спасибо за ответ! Я для себя вчера сформировал более детальный список вопросов. Буду благодарен если поделитесь своим опытом.
1. Достаточно ли ASVS для постановки глобальных требований по security если клиенту не нужен compliance (GDPR, ISO)?
2. Начальный threat modeling всей системы лучше проводить до или после постановки требований по security?
3. На каком этапе SDLC лучше всего устанавливать security requirements к user story?
4. Как лучше переиспользовать повторяющиеся требования для user stories? Выносить часть требований в общий список? Как в таком случае проверять выполнение таких требований? (Например требования по input validation или XSS/SQL protection)
5. Как могут выглядеть общие security требования (system generic requirements)?
6. Как меняется Definition of Done проекта после установления требований по security? Должны ли вноситься требования по security в Definition of Done?
7. Как лучше оформить requirements к user story? Нужно ли для каждого requirement писать acceptance criteria? В какой форме это может быть?
8. Нужно ли security специалисту проверять все требования к user story самостоятельно перед тем как ее принять? Или можно делегировать QA специалистам?
9. В каких случаях проводить manual code review security специалисту? Нужно ли проводить manual code review всех pull requests?
Спасибо за ответ! Я для себя вчера сформировал более детальный список вопросов. Буду благодарен если поделитесь своим опытом.
1. Достаточно ли ASVS для постановки глобальных требований по security если клиенту не нужен compliance (GDPR, ISO)?
2. Начальный threat modeling всей системы лучше проводить до или после постановки требований по security?
3. На каком этапе SDLC лучше всего устанавливать security requirements к user story?
4. Как лучше переиспользовать повторяющиеся требования для user stories? Выносить часть требований в общий список? Как в таком случае проверять выполнение таких требований? (Например требования по input validation или XSS/SQL protection)
5. Как могут выглядеть общие security требования (system generic requirements)?
6. Как меняется Definition of Done проекта после установления требований по security? Должны ли вноситься требования по security в Definition of Done?
7. Как лучше оформить requirements к user story? Нужно ли для каждого requirement писать acceptance criteria? В какой форме это может быть?
8. Нужно ли security специалисту проверять все требования к user story самостоятельно перед тем как ее принять? Или можно делегировать QA специалистам?
9. В каких случаях проводить manual code review security специалисту? Нужно ли проводить manual code review всех pull requests?
S
Переслано от Slava
1. Asvs от овасп более чем достаточно.
2. Моделирование угроз лучше сначала в общих терминах обозначить и уточнить по мере разработки требований, т.к. с самого начала никогда не сможешь наверняка оценить все возможные угрозы.
3. На каком комфортнее, по большому счёту разницы никакой нет когда проверять безопасность.
Мировая практика сложилась такая, что проверки безопасности происходят после выпуска разработчиками релиза, до выхода в прод, параллельно с этапом тестирования.
4. В общем списке оно и будет. Если изначально таким образом построить процесс разработки, то никаких замедлений это не вызовет.
Обычно это делается в виде code style guide-ов, в соответствии которым разработчики пишут код.
Ну а всё что стайл гайды не покроют - проверять руками. Собственно для этого секурити проверки и нужны
5. Собственно в предыдущем вопросе это же и рассматривается, т.е. необходима разработка code style guides, по которым будут работать программисты. У любого языка есть такого рода "базовые стайл гайды", на основе которых и формируют внутренние (корпоративные) стайл гайды (учитывающие нюансы компании).
6. Зависит от уровня критичности выявленных уязвимостей и последствий эксплуатации (низкий уровень можно отложить до общего трижа багов например, а критические баги - необходимо исправить и только после этого выпускать код в прод.
7. Это уже вопросы продакт-менеджеров/продакт овнеров, вот тут можно посмотреть: https://leadstartup.ru/db/acceptance-criteria
8. Секурити специалист должен проверять только то, что входит в его работу, т.е. уязвимости в коде.
Остальные вопросы по части реализации функций должны решать продакт менеджер/qa
9. Манул код ревью как правило проводится при первом анализе кода. В дальнейшем это почти не требуется, т.к. код проверяет софт, а секурити специалист - проверяет результаты проверки кода (верифицирует их).
За пулл-реквесты тоже отвечает продакт, обращаясь за помощью к сесурите по необходимости. Как правило весь процесс достаточно хорошо автоматизируется
2. Моделирование угроз лучше сначала в общих терминах обозначить и уточнить по мере разработки требований, т.к. с самого начала никогда не сможешь наверняка оценить все возможные угрозы.
3. На каком комфортнее, по большому счёту разницы никакой нет когда проверять безопасность.
Мировая практика сложилась такая, что проверки безопасности происходят после выпуска разработчиками релиза, до выхода в прод, параллельно с этапом тестирования.
4. В общем списке оно и будет. Если изначально таким образом построить процесс разработки, то никаких замедлений это не вызовет.
Обычно это делается в виде code style guide-ов, в соответствии которым разработчики пишут код.
Ну а всё что стайл гайды не покроют - проверять руками. Собственно для этого секурити проверки и нужны
5. Собственно в предыдущем вопросе это же и рассматривается, т.е. необходима разработка code style guides, по которым будут работать программисты. У любого языка есть такого рода "базовые стайл гайды", на основе которых и формируют внутренние (корпоративные) стайл гайды (учитывающие нюансы компании).
6. Зависит от уровня критичности выявленных уязвимостей и последствий эксплуатации (низкий уровень можно отложить до общего трижа багов например, а критические баги - необходимо исправить и только после этого выпускать код в прод.
7. Это уже вопросы продакт-менеджеров/продакт овнеров, вот тут можно посмотреть: https://leadstartup.ru/db/acceptance-criteria
8. Секурити специалист должен проверять только то, что входит в его работу, т.е. уязвимости в коде.
Остальные вопросы по части реализации функций должны решать продакт менеджер/qa
9. Манул код ревью как правило проводится при первом анализе кода. В дальнейшем это почти не требуется, т.к. код проверяет софт, а секурити специалист - проверяет результаты проверки кода (верифицирует их).
За пулл-реквесты тоже отвечает продакт, обращаясь за помощью к сесурите по необходимости. Как правило весь процесс достаточно хорошо автоматизируется
t
Переслано от Slava
1. Asvs от овасп более чем достаточно.
2. Моделирование угроз лучше сначала в общих терминах обозначить и уточнить по мере разработки требований, т.к. с самого начала никогда не сможешь наверняка оценить все возможные угрозы.
3. На каком комфортнее, по большому счёту разницы никакой нет когда проверять безопасность.
Мировая практика сложилась такая, что проверки безопасности происходят после выпуска разработчиками релиза, до выхода в прод, параллельно с этапом тестирования.
4. В общем списке оно и будет. Если изначально таким образом построить процесс разработки, то никаких замедлений это не вызовет.
Обычно это делается в виде code style guide-ов, в соответствии которым разработчики пишут код.
Ну а всё что стайл гайды не покроют - проверять руками. Собственно для этого секурити проверки и нужны
5. Собственно в предыдущем вопросе это же и рассматривается, т.е. необходима разработка code style guides, по которым будут работать программисты. У любого языка есть такого рода "базовые стайл гайды", на основе которых и формируют внутренние (корпоративные) стайл гайды (учитывающие нюансы компании).
6. Зависит от уровня критичности выявленных уязвимостей и последствий эксплуатации (низкий уровень можно отложить до общего трижа багов например, а критические баги - необходимо исправить и только после этого выпускать код в прод.
7. Это уже вопросы продакт-менеджеров/продакт овнеров, вот тут можно посмотреть: https://leadstartup.ru/db/acceptance-criteria
8. Секурити специалист должен проверять только то, что входит в его работу, т.е. уязвимости в коде.
Остальные вопросы по части реализации функций должны решать продакт менеджер/qa
9. Манул код ревью как правило проводится при первом анализе кода. В дальнейшем это почти не требуется, т.к. код проверяет софт, а секурити специалист - проверяет результаты проверки кода (верифицирует их).
За пулл-реквесты тоже отвечает продакт, обращаясь за помощью к сесурите по необходимости. Как правило весь процесс достаточно хорошо автоматизируется
2. Моделирование угроз лучше сначала в общих терминах обозначить и уточнить по мере разработки требований, т.к. с самого начала никогда не сможешь наверняка оценить все возможные угрозы.
3. На каком комфортнее, по большому счёту разницы никакой нет когда проверять безопасность.
Мировая практика сложилась такая, что проверки безопасности происходят после выпуска разработчиками релиза, до выхода в прод, параллельно с этапом тестирования.
4. В общем списке оно и будет. Если изначально таким образом построить процесс разработки, то никаких замедлений это не вызовет.
Обычно это делается в виде code style guide-ов, в соответствии которым разработчики пишут код.
Ну а всё что стайл гайды не покроют - проверять руками. Собственно для этого секурити проверки и нужны
5. Собственно в предыдущем вопросе это же и рассматривается, т.е. необходима разработка code style guides, по которым будут работать программисты. У любого языка есть такого рода "базовые стайл гайды", на основе которых и формируют внутренние (корпоративные) стайл гайды (учитывающие нюансы компании).
6. Зависит от уровня критичности выявленных уязвимостей и последствий эксплуатации (низкий уровень можно отложить до общего трижа багов например, а критические баги - необходимо исправить и только после этого выпускать код в прод.
7. Это уже вопросы продакт-менеджеров/продакт овнеров, вот тут можно посмотреть: https://leadstartup.ru/db/acceptance-criteria
8. Секурити специалист должен проверять только то, что входит в его работу, т.е. уязвимости в коде.
Остальные вопросы по части реализации функций должны решать продакт менеджер/qa
9. Манул код ревью как правило проводится при первом анализе кода. В дальнейшем это почти не требуется, т.к. код проверяет софт, а секурити специалист - проверяет результаты проверки кода (верифицирует их).
За пулл-реквесты тоже отвечает продакт, обращаясь за помощью к сесурите по необходимости. Как правило весь процесс достаточно хорошо автоматизируется
5. Кроме требований из ASVS в код стайл гайд будут входить best practices по языку/фреймворку?
S
5. Кроме требований из ASVS в код стайл гайд будут входить best practices по языку/фреймворку?
Это уже каждый сам для себя выбирает. Где-то все бест практисы соблюдают, а где-то какие-то исключают из-за их сложности (собственно для этого внутренние стандарты разработки и формируют)
t
Это уже каждый сам для себя выбирает. Где-то все бест практисы соблюдают, а где-то какие-то исключают из-за их сложности (собственно для этого внутренние стандарты разработки и формируют)
Окей, тогда еще такой вопрос. А что первично, security требования к user story или архитектура функционала?