Комментарии 12
Название статьи отражает суть современной разработки ПО: абстракция поверх абстрактной абстракции.
Это не критика, статью я не читал.
Приветствую, возможно вы правы ;) Спасибо за фидбэк.
Но, все-же стоит обратить внимание, что не возможно в одной статье детально и развернуто описать каждый метод со стороны практики. Именно поэтому приводится сводный анализ в виде спецификации и методам их управления. Если честно, — постарался поделиться мыслями и рассказать про практический опыт, без абстрактных сущностей ;)
Приветствую, изначально в статье вводится базис для понимания какие есть типы АИС и что такое в итоге ИС, среда, включая информацию, которая в ней обрабатывается. На базе данных типов ИС и сред, вводится объяснение по какой причине стала прогрессировать разработка безопасного ПО и почему разрослось количество методов, средств — методологий разработки ПО. Также, вопрос данной статьи рассматривается в конкретном направлении и условиях, где OWASP TOP 10 является применимым для каждой из перечисленной ИС при безопасной разработке ПО, так как ненадежный софт может предоставить значительные проблемы в стадии разработки, эксплуатации и модернизации.
Также, отмечу, что в статье рассматривается только разработка ПО, методологии разработки и управления.
Отвечу на ваш комментарий:
Но в том же АСУТП есть много других компонентов, для которых OWASP не применим.
Что мы не рассматривали комплексный подход типа MLS для всей параллели ИБ, а только конкретное узкое место. Надеюсь, что ответил на вопрос, спасибо за ваш фидбэк ;)
Но все-таки OWASP — это безопасность веб-приложений. OWASP обычно применяется уже на последних этапах разработки, т.к. программисты не особо стараются соблюдать Best Practice OWASP из-за своих причин (сроки, приоритеты..).
Хотя использовать только OWASP легче всего из-за того, что последнее десятилетие только о нём и говорят в контексте безопасности приложений, но не стоит забывать и про другие уязвимости, возникающие при разработке приложений, например безопасность взаимодействия микро-сервисов, контейнеров и т.д.
Спасибо за комментарий, приятно пообщаться со знающим человеком ;)
Да, я понимаю этот момент, но по своему профилю стараюсь делать упор для «бизнеса» в процессе разработки. Так как «посмотрев» за границей, как работают ребятки — стало понятно, отчего и почему у нас в РФ идет копипаст)))
Я понимаю, что имеются другие типы уязвимостей от НДВ, НСД, теймплейтов и так далее, но OWASP TOP 10 был приведён в пример из за его популярности в сообществе, я думаю, что напишу отдельную статью по этой теме, которая касается уязвимостей ;)
поднимет активы и пассивы организации.
Это как? Одновременно растет и то и то?
И главный вопрос, какова цель: обеспечить безопасность разработки или создать безопасное (защищенное ПО?)?
Приветствую, спасибо за ваш фидбэк, отвечу следующим образом: мы не рассматриваем защищенное ПО в конечном виде, а рассматриваем процесс безопасной разработки ПО, которая позволит выстроить процессы в организации.
Активы и пассивы организации взаимосвязаны, так как при изменении одного параметра изменяется соответствующий ему другой параметр, — например, так просчитывается амортизация сотрудника как ресурса в организации, либо же рентабельность, ликвидность продукта. Про рост, я бы сказал, что он происходит последовательно.
Утверждается, что проведение таких обсуждений придаёт общности коллективу: появляется целостное понимание о ходе реальной работы команды. Соответственно, митинги для каждой-scrum команды будут свои.
Если говорить о ведущем, то логичней будет на этой позиции ожидать непосредственно scrum-мастера или ведущего продукта (– терминология; затрудняюсь с реальной позицией соотнести).
в ходе совещания задаются каждому разработчику вопросы, такого типа:По теории, выделялись только первые три их них. Специализировать надо, соглашусь.
2.1. Что удалось выполнить для решения той или иной итерации за день?
2.2. Какие были проблемы в моменте реализации?
2.3. Что и как планируется сделать за сегодняшний день?
2.4. Как происходит интеграция и оптимизация ПО в данном интервале?
2.5. Иные виды вопросов исходя из практики организации.
Это – что касается пары слов о теории – подробнее у самого Сазерленда; за практическим примерами уже надо обращаться к живым командам.
Приветствую, спасибо за ваш фидбэк, по данной методологии SCRUM согласен, что именно так и проходит формат общения, где Product Owner и/или SCRUM-мастер выступают в роде ведущего. В статье описываются методология управления в том числе. Про SCRUM достаточно много статей, которы описывают процессы и передают опыт в формате оптимизации мощностей.
Я правильно понял, что статья сгенерирована с помощью GPT-3?
Спецификация классификации методологии безопасной разработки