Comments 4
Эм, я правильно понимаю, что Вы взяли конкретное приложение, вручную проанализировали что оно делает и как называются потенциально опасные методы и под это все подогнали запрос? Это супер неуниверсально и, следовательно, не имеет практической пользы — проще уж тогда ручным security code review заниматься.
В каждом языке/фреймворке есть вполне стандартные методы для доступа к БД — их и ищет Checkmarx, а затем строит дерево до вызывающей «пользовательской» функции. Кастомные костыли для стандартных действий, это, пожалуй, единственный кейс для описанного подхода, но как по мне, если они используются это уже само по себе плохо.
Например, CMx SAST предполагает, что все запросы в базу будут выглядеть так: *createQuery* или *createSQLQuery*. Но если для работы c БД используются внутренние разработки, и метод для запроса в базу называется по-другому, например *driveMyQuery*, то все SQL методы будут пропущены. Например, наш заказчик использует custom ORM для SQL DB. В этом случае CMx запросы «из коробки» пропустили все SQL-инъекции.
В каждом языке/фреймворке есть вполне стандартные методы для доступа к БД — их и ищет Checkmarx, а затем строит дерево до вызывающей «пользовательской» функции. Кастомные костыли для стандартных действий, это, пожалуй, единственный кейс для описанного подхода, но как по мне, если они используются это уже само по себе плохо.
0
Если мы руками написали кастомный AST-процессор, то зачем нам Checkmarx за много денег? Почему не просто опенсорсный AST-парсер с хуками?
0
Sign up to leave a comment.
«Hello, Checkmarx!». Как написать запрос для Checkmarx SAST и найти крутые уязвимости