Pull to refresh

Comments 4

Эм, я правильно понимаю, что Вы взяли конкретное приложение, вручную проанализировали что оно делает и как называются потенциально опасные методы и под это все подогнали запрос? Это супер неуниверсально и, следовательно, не имеет практической пользы — проще уж тогда ручным security code review заниматься.
Например, CMx SAST предполагает, что все запросы в базу будут выглядеть так: *createQuery* или *createSQLQuery*. Но если для работы c БД используются внутренние разработки, и метод для запроса в базу называется по-другому, например *driveMyQuery*, то все SQL методы будут пропущены. Например, наш заказчик использует custom ORM для SQL DB. В этом случае CMx запросы «из коробки» пропустили все SQL-инъекции.

В каждом языке/фреймворке есть вполне стандартные методы для доступа к БД — их и ищет Checkmarx, а затем строит дерево до вызывающей «пользовательской» функции. Кастомные костыли для стандартных действий, это, пожалуй, единственный кейс для описанного подхода, но как по мне, если они используются это уже само по себе плохо.
Практическая польза в том, что тюнинг запросов требуется только в начальной стадии проекта, дальше в процессе жизни проекта запрос будет просто работать и отлавливать баги. Это универсально для конкретного репозитория.

Если мы руками написали кастомный AST-процессор, то зачем нам Checkmarx за много денег? Почему не просто опенсорсный AST-парсер с хуками?

не знаю что вам ответить, если мы можем руками написать такой же функционал как в комерческом продукте, то действительно, зачем покупать комерческий продукт за много денег? =)
Sign up to leave a comment.