Этой статьей мы завершим небольшой цикл о построении процесса безопасной разработки на основе SAST — статического анализа кода на безопасность. В первой части мы разобрали основные вопросы, возникающие при внедрении SAST в процесс разработки. Во второй части остановились на технических аспектах внедрения и разобрали несколько примеров выстраивания SSDLC на практике. В последней части расскажем об организационных моментах.

Для большинства компаний использование SAST — это новый процесс, а уязвимость — новая сущность. Уязвимость — это не баг и не функциональное требование, и нужно выстраивать процесс работы с новой сущностью. Нельзя забывать про историческое разделение безопасности и разработки, которое особенно обостряется, когда в процесс разработки нужно внедрять что-то новое. Масла в огонь подливают и технические особенности статического анализа, о которых мы говорили во второй части.

– Наташ, а Наташ? Мы там, это… SAST внедрили.
– Мы там всё уронили, Наташ. Вообще, всё!!!
– Пайплайны стоят, очередь забита…
– Ни одной сборки не прошло! Вставай, Натаааш!



Вот так примерно можно проснуться на следующее утро после внедрения в разработку статического анализа кода. Если заранее не подготовиться к этой увлекательной процедуре.
А можно получить совсем другой, намного более позитивный и полезный для разработки и бизнеса результат. Если учесть при внедрении ряд технических нюансов SAST-анализа и вовремя подстелить соломку. Об этих нюансах сегодня и поговорим!

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

Отталкиваясь от вопросов, с которыми мы часто сталкиваемся, мы описали весь процесс внедрения сканера кода в процесс безопасной разработки. Сегодня речь пойдет о том, как выбрать подходящий вам анализатор.

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

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

Сейчас все больше говорят о статическом анализе для поиска уязвимостей как необходимом этапе разработки. Однако многие говорят и о проблемах статического анализа. Об этом много говорили на прошлом Positive Hack Days, и по итогам этих дискуссий мы уже писали о том, как устроен статический анализатор. Если вы пробовали какой-нибудь серьезный инструмент, вас могли отпугнуть длинные отчеты с запутанными рекомендациями, сложности настройки инструмента и ложные срабатывания. Так все-таки нужен ли статический анализ?

Наш опыт подсказывает, что нужен. И многие проблемы, которые возникают при первом взгляде на инструмент, вполне можно решить. Попробую рассказать, что может делать пользователь и каким должен быть анализатор, чтобы его использование было полезным, а не вносило «еще один ненужный инструмент, который требуют безопасники».

Solar inCode умеет обнаруживать уязвимости в байткоде Java. Но показать инструкцию байткода, которая содержит уязвимость, мало. Как показать уязвимость в исходном коде, которого нет?