Как стать автором
Обновить

Спецификация классификации методологии безопасной разработки

Время на прочтение 21 мин
Количество просмотров 4.9K
Рейтинг 0
Комментарии 12

Комментарии 12

Название статьи отражает суть современной разработки ПО: абстракция поверх абстрактной абстракции.
Это не критика, статью я не читал.

Приветствую, возможно вы правы ;) Спасибо за фидбэк.


Но, все-же стоит обратить внимание, что не возможно в одной статье детально и развернуто описать каждый метод со стороны практики. Именно поэтому приводится сводный анализ в виде спецификации и методам их управления. Если честно, — постарался поделиться мыслями и рассказать про практический опыт, без абстрактных сущностей ;)

Каким боком OWASP Top 10 относится к тем 15 типам ИС, которые Вы привели? Если только частично. Но тогда получается, что вопрос рассматривается однобоко. Но в том же АСУТП есть много других компонентов, для которых OWASP не применим.

Приветствую, изначально в статье вводится базис для понимания какие есть типы АИС и что такое в итоге ИС, среда, включая информацию, которая в ней обрабатывается. На базе данных типов ИС и сред, вводится объяснение по какой причине стала прогрессировать разработка безопасного ПО и почему разрослось количество методов, средств — методологий разработки ПО. Также, вопрос данной статьи рассматривается в конкретном направлении и условиях, где OWASP TOP 10 является применимым для каждой из перечисленной ИС при безопасной разработке ПО, так как ненадежный софт может предоставить значительные проблемы в стадии разработки, эксплуатации и модернизации.


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


Отвечу на ваш комментарий:


Но в том же АСУТП есть много других компонентов, для которых OWASP не применим.

Что мы не рассматривали комплексный подход типа MLS для всей параллели ИБ, а только конкретное узкое место. Надеюсь, что ответил на вопрос, спасибо за ваш фидбэк ;)

Спасибо за ответ.
Но все-таки OWASP — это безопасность веб-приложений. OWASP обычно применяется уже на последних этапах разработки, т.к. программисты не особо стараются соблюдать Best Practice OWASP из-за своих причин (сроки, приоритеты..).

Хотя использовать только OWASP легче всего из-за того, что последнее десятилетие только о нём и говорят в контексте безопасности приложений, но не стоит забывать и про другие уязвимости, возникающие при разработке приложений, например безопасность взаимодействия микро-сервисов, контейнеров и т.д.

Спасибо за комментарий, приятно пообщаться со знающим человеком ;)


Да, я понимаю этот момент, но по своему профилю стараюсь делать упор для «бизнеса» в процессе разработки. Так как «посмотрев» за границей, как работают ребятки — стало понятно, отчего и почему у нас в РФ идет копипаст)))


Я понимаю, что имеются другие типы уязвимостей от НДВ, НСД, теймплейтов и так далее, но OWASP TOP 10 был приведён в пример из за его популярности в сообществе, я думаю, что напишу отдельную статью по этой теме, которая касается уязвимостей ;)

поднимет активы и пассивы организации.

Это как? Одновременно растет и то и то?


И главный вопрос, какова цель: обеспечить безопасность разработки или создать безопасное (защищенное ПО?)?

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


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

Отмечу, что по Джефу Сазерленду (Scrum) рекомендуется отводить на обсуждение не более чем 10-15 минут, а проводить в удобное для всех сотрудников время, согласованное и установленное, и, конечно, с обязательным присутствием всех участников. Возможные даже такие случаи, когда на ответ выделяется ограниченное количество времени (минута-полторы) – на слова по существу.

Утверждается, что проведение таких обсуждений придаёт общности коллективу: появляется целостное понимание о ходе реальной работы команды. Соответственно, митинги для каждой-scrum команды будут свои.

Если говорить о ведущем, то логичней будет на этой позиции ожидать непосредственно scrum-мастера или ведущего продукта (– терминология; затрудняюсь с реальной позицией соотнести).

в ходе совещания задаются каждому разработчику вопросы, такого типа:
2.1. Что удалось выполнить для решения той или иной итерации за день?
2.2. Какие были проблемы в моменте реализации?
2.3. Что и как планируется сделать за сегодняшний день?
2.4. Как происходит интеграция и оптимизация ПО в данном интервале?
2.5. Иные виды вопросов исходя из практики организации.
По теории, выделялись только первые три их них. Специализировать надо, соглашусь.

Это – что касается пары слов о теории – подробнее у самого Сазерленда; за практическим примерами уже надо обращаться к живым командам.

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

Я правильно понял, что статья сгенерирована с помощью GPT-3?

Приветствую, спасибо за ваш фидбек. Интересное замечание про алгоритм написания автоматизированных статей, — поизучаю на досуге и посмотрю на сколько он работает. Судя по запросам в "гугле" выдаются забавные моменты :)


Отвечая на ваш вопрос: нет.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории