Поиск уязвимостей в коде API до того, как они попадут в рабочую среду

Еще в сентябре 2019 года Microsoft приобрела платформу анализа кода Semmle. С тех пор они усердно работали над тем, чтобы встроить его в GitHub в форме сканирования кода, функции безопасности GitHub, которую разработчики могут использовать для анализа кода в репозитории GitHub для выявления возможных уязвимостей безопасности и ошибок кодирования. Эта функция сканирования кода доступна в общедоступных репозиториях на GitHub, а также в частных репозиториях, принадлежащих организациям, если у них есть лицензия Advanced Security.

Сканирование кода GitHub можно запланировать на определенные дни и в определенное время. В качестве альтернативы вы можете настроить репозитории для запуска сканирования при возникновении определенного события, например, при выполнении push-уведомления. Когда сканирование кода выявляет потенциальную уязвимость или ошибку в вашем коде, в репозитории GitHub отображается предупреждение. Затем, как только вы исправите проблему с кодом, вызвавшую оповещение, GitHub автоматически закроет оповещение. Чтобы узнать, как включить сканирование кода для репозитория, см. эту страницу на сайте документации GitHub.

Механизм сканирования кода, встроенный в GitHub, также является расширяемым и поставляется с набором сторонних надстроек. Одно из этих дополнений было разработано 42Crunch и добавляет возможность выполнения статического анализа кода REST API в репозитории GitHub. Это позволяет вам анализировать ваши API на предмет уязвимостей безопасности при каждом изменении кода в репозитории или отправке кода и видеть любые обнаруженные проблемы прямо в центре безопасности GitHub. Все проблемы, обнаруженные с помощью этого дополнения, сопровождаются списком соответствующих статей базы знаний 42Crunch, которые позволяют вам увидеть, где в вашем коде находится недостаток, прочитать о потенциальном сценарии использования и ознакомиться с рекомендациями 42Crunch по устранению.

Поскольку API-интерфейсы управляют большинством современных приложений, разрабатываемых сегодня, переход к повсеместному использованию микросервисов, мобильных приложений и облачных приложений привел к огромному распространению API-интерфейсов. Раньше большая часть корпоративных разработок была сосредоточена на создании компонентов монолитных приложений, взаимодействующих с одним сервером; теперь организации обычно имеют множество автономных API, взаимодействующих друг с другом по сети. Побочным эффектом такого изменения подхода к написанию корпоративных приложений является значительное расширение поверхности атаки. Это привело к увеличению числа атак API из-за новых уязвимостей, обнаруживаемых почти еженедельно в популярных API, используемых для разработки корпоративных приложений. Фактически, исследовательская и консалтинговая компания Gartner предсказала, что в течение двух лет API-интерфейсы, вероятно, станут наиболее распространенным вектором атаки, используемым для попыток использования уязвимостей кода в корпоративных сервисах и приложениях.

Меня, как человека, работающего в сфере ИТ, беспокоит эта тревожная тенденция, и я уверен, что она беспокоит и вас. Однако, к счастью, инструмент статического тестирования безопасности REST API от 42Crunch, который доступен в виде действия GitHub, может помочь вам закрыть многие из этих уязвимостей, чтобы обеспечить безопасность вашего кода. Использование этого действия GitHub (на GitHub Marketplace вы также должны проверить многие другие) позволяет вам обнаруживать любые REST API в вашем репозитории GitHub и проверять каждый API, используя более 200 проверок безопасности, предоставляемых 42Crunch, которые охватывают лучшие отраслевые практики для аутентификация, авторизация, транспорт и проверка данных. Полученный в результате аудит затем используется для анализа любых обнаруженных уязвимостей и представляет вам список предупреждений с приоритетом, который вы можете использовать для принятия мер по устранению этих уязвимостей. И, наконец, он позволяет вам обеспечивать безопасность API, устанавливая критерии для ваших рабочих процессов CI/CD и автоматических проверок запросов на вытягивание.

Глядя на статическое тестирование безопасности REST API в действии

Поскольку я хотел узнать больше об инструменте статического тестирования безопасности REST API от 42Crunch, я обратился к Дмитрию Сотникову, директору по продукту в 42Crunch. Дмитрий любезно удовлетворил мою просьбу о дополнительной информации, продемонстрировав мне некоторые возможности их инструмента статического тестирования безопасности REST API. Для тех из вас, у кого такие же опасения, как у меня, по поводу безопасности своих современных приложений, управляемых API, вот несколько снимков экрана из моего разговора с Дмитрием, а также некоторые описательные комментарии, которые он дал, чтобы объяснить, что мы можем увидеть в их:

Дмитрий говорит: «Этот первый рисунок, показанный выше, иллюстрирует, как компании могут использовать действие 42Crunch, чтобы заставить GitHub выполнять проверки безопасности для REST API в своих репозиториях. На снимке экрана показано, как изменение кода, негативно влияющее на безопасность API, было заблокировано автоматической проверкой запросов на извлечение».

«На рисунке 2, показанном выше, — говорит Дмитрий, — показаны все проблемы безопасности API, обнаруженные в репозитории, о которых сообщается на вкладке «Безопасность» GitHub. Отображенные проблемы затем можно отфильтровать по ветке, серьезности, правилам или тегам. Выявленные проблемы безопасности могут быть решены вручную действиями разработчика или автоматически, когда уязвимость будет устранена в самом API».

«Этот третий и последний рисунок, показанный выше, демонстрирует, как разработчики могут щелкнуть любое из предупреждений сканирования кода, чтобы увидеть местонахождение проблемы в контракте API. Для каждой выбранной таким образом проблемы инструмент объясняет уязвимость, потенциальный сценарий ее использования и объясняет, как ее исправить».

Предоставление беспрепятственного опыта DevSecOps

Будущее разработки корпоративного кода определенно принадлежит DevSecOps. Но что на самом деле означает эта методология? DevOps задумывался как способ сократить жизненный цикл разработки систем и состоит из набора методов, сочетающих разработку программного обеспечения (Dev) и ИТ-эксплуатацию (Ops). DevSecOps основывается на природе цикла быстрого выпуска DevOps, включая некоторые дополнительные методы, которые позволяют принимать решения по безопасности со скоростью и масштабом жизненного цикла DevOps. Предоставляя безопасность REST API в виде кода, инструмент статического тестирования безопасности REST API от 42Crunch вносит значительный вклад в превращение DevSecOps в реальность в нашем быстро меняющемся мире современной разработки корпоративного программного обеспечения. Если вы разработчик DevOps, использующий GitHub, обязательно ознакомьтесь с этим инструментом сегодня.