Запрягаем ламу. Как использовать Llama для поиска критичных данных в коде

Ищем критичное в коде

В док­ладе лет­ней Offzone я рас­ска­зывал, как мы исполь­зуем дви­жок и пра­вила semgrep для пар­синга кода сер­висов и извле­чения отту­да важ­ных для нас объ­ектов. Оставлю тех­ничес­кие под­робнос­ти пар­синга в сто­роне, напом­ню толь­ко основную идею.

Ес­ли корот­ко, дан­ные кли­ентов мы бережем как зеницу ока и хотели бы сле­дить за тем, в каких мик­росер­висах нашего про­дук­та живут име­на, адре­са, телефо­ны, пас­пор­тные дан­ные, финан­совая информа­ция, логины, пароли и дру­гие авто­риза­цион­ные дан­ные. Это поз­волит сфо­куси­ровать имен­но на них наши ИБ‑про­цес­сы, то есть выб­рать те двад­цать про­цен­тов сер­висов, повышен­ное вни­мание к которым при­несет нам восемь­десят про­цен­тов поль­зы.

Пред­ста­вим типич­ную ситу­ацию: с интерне­том наш про­дукт свя­зан через некото­рый API gateway, все, что туда отда­ется по опре­делен­ным роутам, мы можем най­ти в Swagger-фай­ле, лежащем в коде это­го гей­твея. Внут­ри меж­ду собой сер­висы обща­ются по GRPC, и все их внеш­ние методы лежат в proto-фай­лах. Сер­висы, которые что‑то пишут в базу Postgres, хра­нят SQL-схе­мы в пап­ке миг­раций. И что­бы знать, что где содер­жится, нам нуж­но уметь пар­сить Swagger, proto и схе­мы таб­лиц в каком‑то еди­нооб­разном виде.

Ес­ли, пред­положим, у нас добави­лось новое поле «СНИЛС» в объ­екте поль­зовате­ля, оно добавит­ся в Swagger на гей­твее, и в proto-кон­трак­те, и в схе­ме базы сер­виса вла­дель­ца поль­зователь­ских дан­ных. Мы, срав­нив два сос­тояния на сегод­ня и на вче­ра, уви­дим на дифе это новое поле.

Итак, теперь мы уме­ем вынимать из кода сер­висов Swagger и Protobuf, а срав­нив сос­тояния сер­висов за вче­ра и за сегод­ня, зна­ем, какие поля поменя­лись.

Скоринг на минималках

Опыт­ный аппсек‑инже­нер может сра­зу заметить, что в боль­шом про­дук­те ежед­невно про­исхо­дит огромное количес­тво изме­нений в сер­висах. Даже если мы будем сле­дить толь­ко за изме­нени­ями во внеш­них кон­трак­тах (proto, QraphQL, сваг­геры и схе­мы БД), нас все рав­но может завалить десят­ками сооб­щений об этих изме­нени­ях. Нуж­но как‑то филь­тро­вать поток.

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

Те­перь некото­рые поля наших объ­ектов обре­ли уро­вень кри­тич­ности и тег, опре­деля­ющий тип дан­ных.

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

Так­же в потоке изме­нений мы можем реаги­ровать толь­ко там, где в схе­мах добави­лись или поменя­лись кри­тич­ные поля. Зачем нам знать, что у поль­зовате­ля появи­лось поле «Любимый фильм»? А вот если у него добави­лось поле для вво­да ИНН или номера пас­порта — неп­лохо бы обра­тить на это вни­мание.

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

С базовы­ми пра­вила­ми мы разоб­рались, но оста­ется ощу­щение, что мы не усле­дим, если где‑нибудь в нашем про­дук­те появит­ся новый тип дан­ных, для которо­го мы не при­дума­ли пра­вила заранее. Уже сей­час в при­мерах пра­вил мы видим, что неп­лохо бы было раз­метить и СНИЛС, и email, а в базовых пра­вилах их нет.