Измерение безопасности кода, написанного разработчиками программного обеспечения

Question

Если вы являетесь разработчиком и имеете доступ к таким инструментам, как Ounce Labs, Fortify Software или Veracode, не могли бы вы возражать против того, чтобы показатели кода, который вы пишете, стали общедоступными? Если вы возражаете, что вам нужно, чтобы вы чувствовали себя более комфортно с большей прозрачностью в этом отношении?

Если показатели были общедоступными, считаете ли вы, что это будет иметь положительный побочный эффект, побуждая разработчиков тратить больше времени на обучение методам secure coding? Есть ли более эффективные подходы к поощрению разработчиков тратить свое время на изучение secure coding, учитывая конкурирующие проблемы?

Answer 1

Я рассматриваю любую метрику с высокой степенью подозрения по всем обычным причинам. Показатели безопасности, скорее всего, будут использоваться как FUD. Вы также должны знать уместность. Например, дефекты, связанные с ненадежным кодом, не имеют отношения к ненадежному коду.

Есть два важных вопроса: ИМО: Уязвимость? Насколько это очевидно?

(Другой вопрос будет: Почему вы ссылка на какую-то местную группу, не давая понять, в ссылке?)

Answer 2

Я не думаю, что доступ к инструментам обязательно является проблема. По внешнему виду вашего профиля мы находимся в аналогичной позиции. Я отвечаю за архитектуру довольно крупных клиент-серверных решений. Проблемы с безопасностью в нашей кодовой базе являются результатом безопасной практики, которая просто не является «на радаре». Они набиваются для наборов функций и других исправлений ошибок клиента.

В настоящее время мы изучаем, как защитить нашу кодовую базу, управлять ролями безопасности на уровне предприятия и все эти хорошие вещи из-за рыночного спроса. Я думаю, что иметь возможность оценить уровень риска в кодовой базе очень важен. Именно здесь начинают действовать инструменты - они предлагают отчеты и могут быть использованы для улучшения. Разработчики, такие как измеримое продвижение и уменьшение количества угроз безопасности, обнаруженных инструментом анализа от одного выпуска к другому, очень измеримы.

Я думаю, что инструменты и отчеты, которые они предлагают, могут быть полезны и на самом деле играют довольно важную роль. Но до тех пор, пока кто-то (менеджмент, рынок и т. Д.) не установит какое-то значение на закрытие дыр в безопасности и мандаты на повторное использование инструментов для снижения снижения рисков, разработчики не будут чрезмерно заинтересованы в связанных с безопасностью программирование. На самом деле это не так интересно, когда вы смотрите на все другие действительно классные вещи из свиста. Вы можете захотеть check out this related thread с нескольких недель назад или even this one с октября прошлого года.

Хуже того, проблемы безопасности действительно влияют на очень небольшое количество программного обеспечения сегодня. С учетом сказанного, большое количество дефектов, о которых сообщает Поле не произошло бы, если бы мы уделяли больше внимания безопасности; другими словами, они являются дефектами безопасности, хотя они сообщаются, потому что они вызывают другие проблемы. Именно здесь я считаю, что мы можем получить самый большой удар по доллару при устранении дефектов безопасности. Интересно, проводил ли кто-нибудь исследование, изучающее скорость отчетов об ошибках до и после прохождения оценки безопасности и ремонта. Моя кишка говорит мне, что скорость сообщаемых дефектов должна уменьшаться, т. Е. «Более безопасное программное обеспечение» == «программное обеспечение более высокого качества». Этого достаточно ...