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

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

Zip File, мамкины хаЦкеры. С вами Денчик и сегодня мы поговорим о том, чем же безопасная разработка отличается от классической. Рассмотрим этапы конвейера разработки, разберёмся в различиях статического анализа от динамического.

Ну и конечно рассмотрим все плюсы и минусы обоих подходов. Если вам интересно узнать про SAST, DAST, RAST, BAST и прочий *яст, тогда устраивайтесь по удобнее.

Цедите себе в бокал чего-нибудь интересненького. Откидывайтесь по удобнее в компуктерном кресле и приготовьтесь слушать весьма душный, но дико полезный ликбез до последней минуты. Погнали

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

Речь идёт, конечно же, о фронтенде. Ведь помимо основного кода, в момент создания приложения нужно ещё разработать пользовательские функции и продумать весь интерфейс.

Т.е. всё с чем пользователь обычно взаимодействует: картинки, меню, анимации, кнопки, чекбоксы, крутые интерактивные элементы, не появляется просто так.

Их созданием занимается фрондент-разработчик, хорошо разбирающийся в таких умных штуках, как JavaScript, HTML и само-собой CSS.

Современные фреймворки, разветвлённые алгоритмы, структуры данных, архитектуры, методологии создания и исправлении кода. Всё это многообразие запросто уложится у вас в голове, после освоения профы Фронтенд-разработчик на Хекслете.

Для тех, кто не в теме, Хекслет – это популярная образовательная онлайн-платформа, специализирующаяся на обучении программистов и разработчиков более 10 лет.

Их фишка в том, что её создатели – профессиональные разработчики, работающие в известных компаниях и стартапах, а не просто безымянные прогеры с улицы.

Поэтому по вопросам стажировки, поиску престижного места работы и прочим моментам так или иначе связанным с дальнейшим трудоустройством – можете не волноваться.

Если будете усердно учиться правильным инженерным практикам и акцентировать внимание на получении базовых знаний работая с прикладными задачами – за вас однозначно всё порешают.

Главное не избегайте практики и набивайте портфолио. Ведь тут для этого есть масса возможностей. Более 400 заданий в онлайн-тренажёре, сотни тестов, десятки Open Source проектов и ещё куча всего интересного.

В рамках этой истории вам предстоит писать приложения различных уровней сложности. От простых консольных игрушек до полнофункционального таск-менеджера. Эт вам не хухры мухры.

А если останутся силы – можно попробовать себя на бесплатных курсах профессии, коих вам откроется целых 7. Начать обучение по ним можно прямо сейчас! Они появятся в кабинете сразу после регистрации на платформе.

Так что смело изучайте, тестируйте, пробуйте писать код. И если понравится, оплачивайте обучение в основной группе по профессии «Frontend-разработчик». Ссылку само-собой, оставлю прямиком в описании. Чекай скорей.

Ну а мы возвращаемся к основной теме нашего выпуска. И начнём мы с того, что разберёмся чем DevSecOps отличается от классического DevOps.

Последний включает в себя написание кода, тестирование, развёртывание в продуктив, мониторинг и прочие известные всему ITшному миру этапы.

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

Статический анализ кода (SAST)

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

Качественный SAST анализатор помимо работы с библиотеками, которые имеются в вашем распоряжении, может обнаруживаться уязвимости, о которых ещё неизвестно.

Т.е. баги ещё нигде не задекларированы, а SAST их уже обнаружил. Это пример хорошего инструмента статического анализа. Само собой эти истории обычно платные и стоят немалых денег. Примерно от 10 тысяч долларов.

Нищеброды же, как обычно, ограничиваются процессом ревью. Эдакой ручной проверкой исходного кода, где проверяющий пишет правила и затем ищет код, который как-либо “выбивается” из общего порядка.

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

На этом фоне, более интересным вариантом статического анализа являются линтеры. Это автоматизированные проверки. Линтер самостоятельно проверяет наличие в коде уязвимостей на уровне несложных проверок и “причесывает” его.

Иногда линтеры умеют находить утечки памяти, циклические зависимости и даже некорректно объявленные классы. К слову, для некоторых языков программирования полноценные SASTы не пишутся от слова совсем и линтеры здесь выступают единственной панацеей.

Ну и третий тип – это непосредственно инструменты статического анализа. Они позволяют разработчикам находить уязвимости безопасности в исходном коде приложения на ранних этапах жизненного цикла разработки ПО.

Помимо этого, SAST также обеспечивает соответствие руководствам и стандартам кодирования без фактического выполнения базового кода. ОпенСурсные САСТы, как правило, полная шляпа.

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

Плюсы и минусы статического анализа

К плюсам статического анализа можно отнести возможность выявления дефектов ещё до этапа передачи на тест. Т.е. можно увидеть проблему в самом зачатке, исправить и не выдумывать в дальнейшем велосипед.

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

Оценить зависимости и несоответствия (к примеру, в ссылках) в разных версиях программного обеспечения и банально вручную поправить все косяки благодаря опыту, полученному непосредственно во время этапа разработки продукта.

Вы ведь, как никак автор кода. А кто, как не автор, лучше других знает свои халтуры и упущения. К слову, о них родимых. Есть у статического анализа конечно же и вагон фундаментальных минусов.

Первый, пожалуй, самый очевидный – это предоставление доступа к исходному коду. Логично, что проревьюить какой-либо код попросту невозможно без доступа к исходникам.

Второй минус – это ограничение по языкам программирования. Например, на редкие языки аля Go, Dart. Последний позиционируется в качестве альтернативы JavaScript’у, но на деле адекватный SAST для него *уй найдёшь.

Ну и третий, наиболее существенный минус – это большое количество false-positive уязвимостей. Это когда инструмент вроде сообщает нам об ошибке, однако на самом деле ошибки никакой нет.

Но на практике гораздо страшнее, когда уязвимость всё-таки есть, но анализатор молча её пропускает. Так что уж лучше пусть будет больше ложных срабатываний, чем полное их отсутствие.

До февраля ещё была проблема, заключающаяся в том, что если решение облачное, то данные об исходной коде передаются третьей стороне, но теперь данная проблема отпала.

Все адекватные зарубежные SAST решения ушли с отечественного рынка. А в нашей стране попросту нет подобных облачных сервисов. А значит и передавать код никому и не надо. Так что не парьтесь.

В с которыми вы сегодня реально сможете поработать можно по пальцам пересчитать. Самый популярный это, пожалуй, PVS-studio. Это российская разработка, покрывающая всю ветку языков C и имеющая возможность тестировать Java.

Checkmarx, израильский вендор. Также пока остаётся в России и не собирается уходить. Поистине кошерный анализатор хавающий C#, Java, Kotlin и даже Swift. Заявлена также поддержка Golang, но с Go’шкой данный SAST справляется разве что номинально.

Из OpenSource решений, есть неплохой вариант под названием Snyk. Он и ставится легко и документации по нему валом. Разработчики заявляют поддержку C#, Python, Java, PHP и конечно же Go, который сразу можно смело выкидывать, не теша себя надеждой.

Да и с шарпом эта история, откровенно говоря, работает не ахти. Короче если и юзать, то только для Питона и Явы. Они из этого списка более-менее легко тестируемы.

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

Динамический анализ кода (DAST)

Динамический анализ кода начинается на этапе когда мы уже развернули приложение и настала пора идти дальше.  DAST детектирует уязвимости в поведении уже рабочей программы.

Данный инструмент имитирует поведение приложения, проверяет недопустимые значения и затем отправляет алерты ответственным за разработку и информационную безопасность продукта.

Типов динамического анализа существует значительно больше, чем статического. Первый – это Web application scanning. Он же модуль сканера уязвимостей.

По сути - банальная проверка запущенного веб-приложения. Для этой проверки необходимо дать учетную запись сканеру и отключить для неё какие-то сложные этапы аутентификации (например, 2FA).

Второй тип – автотесты. Если в случае со статикой мы говорили сугубо о правилах, то тут тестировщики совместно с безопасниками пишут тесты. Вернее, безопасники диктуют хотелки, а тестировщики уже напрягают свой мозг.

Третий тип – классические DAST инструменты, изначально предназначенные для проведения динамического анализа. Тут вам возможность сканирования SOAP, REST, различные проверки аутентификации и прочие полезные вещи.

Самым неодназначной практикой, которую почему-то тоже приписывают к динамическому анализу является фазинг. По сути, фазинг призван проверить то, что не могут проверить другие инструменты.

Гугл как-то заказал фазинг своих сервисов и за год нашлось всего 50 уязвимостей. Не густо, но и не пусто. Данный инструмент имитирует действия пентестера, который 24/7 проверяет ваше приложение на наличие дыр.

Также существует пятый тип. Многие ошибочно относятся его к динамическому, но это на самом деле отдельная практика. Речь идёт о так называемом интерактивном анализе. Нечто среднее между статическим и динамическим вариантом.

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

Плюсы и минусы динамического анализа

К плюсам всех практик динамического анализа можно отнести маленькое количество false positive. Если, конечно, вы не спустили на тормозах этап с SASTом.

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

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

Отсюда, собственно, вытекают основные минусы DASTа. Во-первых, для качественного динамического анализа вы должны иметь полноценную учётную запись для доступа к кишкам проги.

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

Что касается конкретных инструментов для DAST, то тут список ещё более скудный. Оперсурсный zaproxу. И не ушедший из России PortSwigger с продуктом burp.

Интеграция инструмента в пайплайн происходит науровне CD-системы. Если сканирование вдруг прошло неудачно, мы отменяем задачу и возвращаемся к тому, с чего начали. Всё, как и в истории с SASTом.

Этапы внедрения анализаторов 

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

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

Затем происходит закупка, если, конечно, решение платное. В конторе, где разработчики добрые, пробуем поиграться на тестовом проджекте. Проверяем, что получилось. И затем дорабатываем, доводя эту историю до ума.

Там, где надо в заключении пробуем в другой команде разработки. Но это, сами понимаете уже частный случай. Как правило, в лайфе, всё ограничивается вышеперечисленными пунктами.

Касательно сроков, внедрение статического анализатора, можно назвать цифру от 6 месяцев. Примерно месяц на выбор решения. Столько же на закупку, т.к. в этой истории всегда задействуется не один и не два отдела.

Бухи, юристы, различные менеджеры. Короче всеми любимые прелести бюрократии. Ещё недели 2 вас будут мурыжить админы, которые ленятся выделить адекватную виртуалку. И только затем вы сможете приступить к первым тестам.

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

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

Но, как говорится, лучше поздно, чем никогда. Ибо если баги нашёл SAST или DAST – то вы свой кэш отработали. А вот если эта честь выпала злоумышленнику, то тут уж простите. Специалист из вас мягко скажем какашка.

Инструменты не примитивного контроля

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

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

Речь идёт о RASPах и BASTах. Работают они непосредственно на уровне приложения и в теории должны справляться со своими задачами много лучше существующих примитивных средств тестировки.

Но, сами понимаете, в этом мире нет ничего идеального. Хотя нет, пожалуй, что-то всё-таки есть. Например, мой авторский курс по работе с распределённой системой Git.

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

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

Введя его на портале матёрых IT-спецов, вы получите 15% скидку на курс по ГИТу. А внезапно образовавшийся профит можно потом потратить на распутных женщин и виски.

Короче, всё как мы любим. Ссылку на практический курс «GIT – Это просто!» и на другие авторские материалы от Денчика чекаем в описании.

Окей, друзья. Нынче мы подробно разобрались в чём заключается разница между статическим и динамическим анализом кода, рассмотрели инструменты, которые пока не попали под санкции.

И наскоро пробежались по основным этапа конвейера разработки. Если вам зашла эта темка и вам хочется видеть на канале больше материалов по разработке – не стесняйтесь, пишите об этом в комментах.

Обязательно ставьте лайки и оформляйте подписку. Ведь чем больше наше комьюнити, тем значительнее вклад в распространения действительно качественных знаний мы привнесём.

В заключении, по традиции, хочу пожелать вам удачи, успеха, и самое главное, отличного настроения. Берегите себя и свой код, исправляйте свои разработки вылизывая их с точки зрения безопасности, и будет вам счастье. До новых встреч, мои кайфные друже. Всем пока.