А, значит, пора вспомнить теорию вычислений.

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

1. Определения

Программа P — частично-рекурсивная функция φ_P : Σ* ⇀ Σ* над конечным алфавитом Σ. Расширенная модель (для анализа состояний и трасс): P порождает множество бесконечных последовательностей состояний Executions(P) ⊆ Σ\_ω.

Уязвимость (определение A, поточечное) есть разрешимый предикат Bad ⊆ Σ* × Σ*, где Bad(x, y) истинно, если выход y на входе x составляет «нежелательное поведение» в терминах модели угроз (аварийное завершение, выход за границы буфера, запуск вредоносного кода и т.д.). Предикат Bad фиксирован моделью угроз и не зависит от текста программы — он определяет, какие пары вход-выход считаются опасными, безотносительно того, какая именно программа этот выход произвела.

Уязвимость (определение B, трассовое): нарушение свойства безопасности (safety property) в смысле Алперна и Шнайдера: множество «плохих» конечных префиксов, таких что если префикс содержит «плохое событие», то любое продолжение также его содержит. Формально: свойство Φ является safety-свойством, если ∀σ ∉ Φ, ∃i < |σ| : ∀τ, σ|\_i · τ ∉ Φ.

Уязвимость (определение C, семантическое): нарушение произвольного нетривиального семантического свойства S программ (т.е. S зависит только от вычисляемой функции, а не от текста программы). По теореме Райса, такие свойства неразрешимы — не существует алгоритма, определяющего по тексту программы, обладает ли она свойством S. Однако неразрешимость распознавания свойства и невозможность конструирования программы с заданным свойством — это разные утверждения, и второе требует отдельного доказательства.

Устранение уязвимости. Говорим, что в программе Q устранена уязвимость программы P, если:

• ∀x ∉ Vuln\_P : φ\_Q(x) ≃ φ\_P(x) — идентичное поведение на безопасных входах (включая расхождение: если φ_P(x) не определено и x ∉ Vuln_P, то φ_Q(x) тоже не определено);
• ∀x ∈ Vuln_P : φ_Q(x) определено ∧ ¬Bad(x, φ_Q(x)) — на уязвимых входах Q останавливается с безопасным выходом;

где Vuln_P = {x | φ_P(x) определено ∧ Bad(x, φ_P(x))}.

Символ ≃ означает совпадение частичных функций (по Клини): обе стороны одновременно определены и равны, или обе не определены.

2. Теорема 1 (о поточечных уязвимостях)

Поточечные уязвимости всегда устранимы

Формулировка. Пусть уязвимость задана разрешимым предикатом Bad(x, y), и пусть safe : Σ* → Σ* — вычислимая тотальная функция «безопасного ответа», удовлетворяющая условию ∀x : ¬Bad(x, safe(x)). Тогда существует вычислимая программа Q такая, что в Q устранена уязвимость P.

Доказательство. Определим Q следующим алгоритмом:

Q(x):
  y ← P(x)
  if Bad(x, y):
    return safe(x)
  else:
    return y

Поскольку P вычислима (частично-рекурсивна) и Bad разрешим, композиция этих операций также вычислима. Покажем, что Q удовлетворяет определению устранения уязвимости:

• Вычислимость: Q — частично-рекурсивная функция как композиция вычислимых операций.
• Совпадение с P на безопасных входах: если x ∉ Vuln_P, то либо φ_P(x) не определено (тогда Q(x) расходится на шаге y ← P(x), т.е. φ_Q(x) тоже не определено), либо φ_P(x) = y и ¬Bad(x, y) (тогда Q возвращает y). В обоих случаях φ_Q(x) ≃ φ_P(x).
• Безопасность на уязвимых входах: если x ∈ Vuln_P, то φ_P(x) определено, значит y ← P(x) завершается. Далее Bad(x, y) истинно, и Q возвращает safe(x). По условию на safe: ¬Bad(x, safe(x)), значит ¬Bad(x, φ_Q(x)). ∎

Замечание о существовании safe. Условие ∀x : ¬Bad(x, safe(x)) не является ограничительным на практике: поскольку Bad разрешим и нетривиален (существуют безопасные выходы), для большинства моделей угроз такую safe можно предъявить явно — например, safe(x) = ε (пустая строка) или safe(x) = сообщение об ошибке, если модель угроз не считает аварийное завершение уязвимостью.

3. Теорема 2 (о трассовых уязвимостях)

Трассовые уязвимости устранимы через программу-монитор

Формулировка. Пусть уязвимость определена как нарушение safety-свойства Φ (в смысле Алперна–Шнайдера) на трассах исполнения, и пусть автомат безопасности A_Φ для данного свойства имеет вычислимое отношение перехода. Тогда существует вычислимое преобразование программ Rewrite : β → β такое, что для любой программы P, Rewrite(P) удовлетворяет Φ и согласуется с P на всех трассах, где P не нарушает Φ.

Автомат безопасности. Свойство безопасности Φ характеризуется автоматом безопасности — автоматом A_Φ со счётным (потенциально бесконечным) множеством состояний Q, алфавитом событий исполнения Σ_ev и вычислимой функцией перехода δ : Q × Σ_ev → Q ∪ {reject}. Автомат переходит в отвергающее состояние при наблюдении «плохого» события. Ключевое требование — вычислимость δ (по паре (состояние, событие) за конечное время получаем следующее состояние или reject), а не конечность Q.

В отличие от классических DFA, автоматы безопасности (по Шнайдеру и Хамлену и др.) допускают счётно-бесконечное множество состояний. Это позволяет представлять safety-свойства, не являющиеся ω-регулярными (например, «количество открытых файлов никогда не превышает n» для произвольных n).

Доказательство. Преобразование Rewrite работает следующим образом:

1. Встраивание: в код P вставляется симуляция автомата A_Φ — переменная текущего состояния q, инициализированная начальным состоянием q₀.
2. Перехват: перед каждым событием e ∈ Σ_ev (системный вызов, запись в память, и т.д.) вставляется проверка: вычисляется δ(q, e).
3. Ветвление: если δ(q, e) = reject, программа выполняет безопасную альтернативу (аварийное завершение или подмену действия). Если δ(q, e) = q', то действие e исполняется и q обновляется на q'.

Это определение предполагает, что все события из Σ_ev наблюдаемы и перехватываемы на уровне инструментации. В модели, где программа — это последовательность наблюдаемых действий (что стандартно для анализа безопасности), данное предположение выполняется.

Результирующая программа Rewrite(P):

• Вычислима: P вычислима, δ вычислима, добавление конечного числа вычислимых операций перед каждым шагом сохраняет вычислимость.
• Удовлетворяет Φ: по построению, ни один «плохой» префикс не может возникнуть — автомат отвергает его до исполнения.
• Согласуется с P на безопасных трассах: до первого момента, когда P нарушила бы Φ, программы Rewrite(P) и P производят одинаковую последовательность событий (в проекции на Σ_ev). Дополнительные вычисления (симуляция автомата) не влияют на наблюдаемое поведение, а лишь на внутреннее состояние. ∎

Связь с EM-принудимостью. Шнайдер доказал: все EM-принудимые (enforceable via execution monitoring) свойства являются safety-свойствами. Однако обратное неверно: Базин и др. показали, что класс EM-принудимых свойств — собственное подмножество safety в обобщённой модели с различением контролируемых и наблюдаемых действий. Конструкция program rewriting покрывает более широкий класс, чем чистый EM, поскольку допускает не только прерывание исполнения, но и подмену действий. Хамлен, Моррисетт и Шнайдер показали, что RW-принудимые свойства включают некоторые Π₂-трудные свойства, выходящие за пределы coRE-класса EM.

4. Теорема 3 (о неустранимых уязвимостях)

Существуют уязвимости, неустранимые вычислимыми средствами

Формулировка. Существует частично-рекурсивная функция φ_P и нетривиальное семантическое свойство S, такие что не существует вычислимой программы Q, одновременно удовлетворяющей S и согласующейся с P на всех входах из dom(φ_P), где P не нарушает S.

Доказательство. Пусть S = «тотальность»: программа Q удовлетворяет S тогда и только тогда, когда φ_Q — всюду определённая (тотальная) функция. Тотальность — нетривиальное семантическое свойство (существуют тотальные и нетотальные программы), неразрешимое по теореме Райса.

Определим программу P следующим образом:

P(n):
  simulate TM_n on input n
  if TM_n(n) halts with output k then
    return k + 1
  else
    diverge

Здесь {TM_i} — стандартная гёделева нумерация всех машин Тьюринга. Программа P частично-рекурсивна: φ_P(n) = φ_n(n) + 1, если φ_n(n) определено; иначе φ_P(n) не определено.

P не удовлетворяет S (P нетотальна — расходится на входах n, где TM_n(n) не останавливается). «Уязвимость» здесь — нетотальность: программа обязана давать ответ на всех входах, но на некоторых расходится.

Покажем, что не существует тотальной вычислимой Q, согласующейся с P на dom(φ_P).

Предположим от противного, что такая Q существует. Тогда:

1. φ_Q — тотальная вычислимая функция;
2. Для всех n, где φ_P(n) определено (т.е. где TM_n(n) останавливается): φ_Q(n) = φ\_P(n) = φ\_n(n) + 1.

Поскольку Q — программа, она имеет номер в стандартной нумерации: Q = TM_k для некоторого k. Рассмотрим вход n = k:

• TM_k — тотальная функция (по предположению), значит TM_k(k) определено, значит k ∈ dom(φ_P);
• Из согласованности: φ_Q(k) = φ_P(k) = φ_k(k) + 1;
• Но φ_Q(k) = φ_k(k) (поскольку Q = TM_k);
• Получаем: φ_k(k) = φ_k(k) + 1 — противоречие. ∎

Замечание о связи с теоремой Райса. Теорема Райса мотивирует постановку задачи: она говорит, что нельзя алгоритмически распознать, обладает ли программа нетривиальным семантическим свойством. Однако Теорема 3 — более сильное утверждение: она показывает, что для некоторых программ вообще не существует вычислимой замены с нужными свойствами, независимо от того, можем ли мы это распознать.

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

5. Заключение

Доказано следующее:

• Теорема 1: уязвимости, заданные разрешимым предикатом на парах вход-выход, устранимы всегда — достаточно обернуть программу фильтром с безопасным ответом.
• Теорема 2: нарушения safety-свойств с вычислимым автоматом безопасности устранимы через встраивание монитора (program rewriting). Это покрывает широкий класс практических уязвимостей: переполнения буфера, нарушения контроля доступа, нарушения протоколов и т.д.
• Теорема 3: существуют семантические свойства, для которых устранение «уязвимости» (в смысле достижения этого свойства при сохранении согласованности) доказуемо невозможно.

Разделительная линия проходит в том, устранима ли уязвимость ограничением поведения (отсечь плохое, оставив хорошее неизменным) или требует расширения области определения программы (заставить программу осмысленно отвечать там, где она раньше расходилась). Первое всегда возможно; второе — нет.

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

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

Говоря ещё проще: существуют неустранимые узявимости, относящиеся к классу уязвимостей логики приложения.

Литература

1. B. Alpern, F. B. Schneider. Defining Liveness. Information Processing Letters, 21(4), 1985.
2. F. B. Schneider. Enforceable Security Policies. ACM TISSEC, 3(1), 2000.
3. K. W. Hamlen, G. Morrisett, F. B. Schneider. Computability Classes for Enforcement Mechanisms. ACM TOPLAS, 28(1), 2006.
4. D. Basin, V. Jugé, F. Klaedtke, E. Zălinescu. Enforceable Security Policies Revisited. ACM TISSEC, 16(1), 2013.
5. H. G. Rice. Classes of Recursively Enumerable Sets and Their Decision Problems. Trans. AMS, 74, 1953.
   

- CVE‑2020‑16250 описан обход аутентификации в HashiCorp Vault: злоумышленник заставил сервер разобрать JSON там, где ожидался XML. Поскольку XML-парсер Go чрезвычайно терпим к формату (он извлекает любые XML-подобные фрагменты), подмена значения заголовка Accept на application/json привела к получению доступа без должной проверки.

- CVE‑2017‑12635 в Apache CouchDB: различия JSON-парсеров Erlang и JavaScript позволяли создать пользователя с двумя полями roles, где второе содержало "_admin". В итоге атакующий мог выдать себе админ-права (и далее ещё и провести RCE благодаря CVE‑2017‑12636).

- CVE‑2024‑34155 показала, что парсер Go можно обрушить (DoS) чрезмерно вложенным вводом: отсутствие контроля глубины разбора вызывало переполнение стека и панику ядра.

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

- Python: библиотека PyYAML до версии 5.1 могла выполнить через десериализацию произвольный код при разборе YAML через функции yaml.load и yaml.load_all (CVE-2019-20477)

- Java: парсер SnakeYAML до 1.31 не ограничивал глубину структуры, позволяя DoS через глубоко вложенный YAML (CVE‑2022‑25857).

- JavaScript: где он, там и Prototype Pollution. CVE‑2024‑38984 в модуле `json-override` через ключ `__proto__` позволяла «загрязнить» прототип объекта, приводя к выполнению кода.

- C#: за прошлогодние DoS в Newtonsoft.Json (CVE-2024-21907 и ах, если бы это была её единственная CVE...) и в стандартном System.Text.Json (CVE-2024-43485) скромно промолчим.

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

Доступ к скрытым или игнорируемым полям при (де)сериализации

Python + PyYAML: в Python «приватные атрибуты» (начинающиеся с __) не защищены от сериализации. Например, PyYAML при сериализации объекта включает даже «приватные» поля:

import yaml

class User:
  def __init__(self, username, password):
    self.username = username
    self.__password = password

u = User("alice", "s3cr3t")
print(yaml.dump(u))

Получаем:

!!python/object:__main__.User
_User__password: s3cr3t
username: alice

Java + Gson: в Gson по умолчанию сериализуются все поля объекта, даже приватные. Например:

import com.google.gson.Gson;

class User {
  public String login = "admin";
  private String password = "secret";
}

User user = new User();
String json = new Gson().toJson(user);
System.out.println(json);

Получаем:

{"login":"admin","password":"secret"}

Игнорирование неизвестных полей

Java + Gson: при десериализации JSON, Gson по умолчанию пропускает неизвестные ключи без ошибок. Например, если есть класс:

class User { String name; }

и мы пытаемся распарсить в него JSON {"name": "Bob", "age": 30}, лишнее поле age будет тихо проигнорировано:

User u = new Gson().fromJson(jsonString, User.class);
System.out.println(u.name); 

Получаем: "Bob", без каких-либо ошибок / исключений

Python + Pydantic: библиотека Pydantic по умолчанию тоже игнорирует лишние поля во входных данных. Например:

from pydantic import BaseModel

class User(BaseModel):
  name: str

data = User.parse_obj({"name": "Bob", "admin": True})
print(data.dict())

Так же, по-тихому, получаем: {'name': 'Bob'}.

Дублирующиеся ключи в объектах

Здесь прямая аналогия с HTTP Parameter Pollution, и с примерно теми же последствиями при неправильно реализованной или отсутствующей семантической валидации.

JavaScript + JSON.parse: стандартный парсер JSON в JavaScript при дублировании полей оставляет последнее встреченное значение. Например:

let obj = JSON.parse('{"role": "user", "role": "admin"}');
console.log(obj); 

Получаем: { role: "admin" }

Python + `json`/PyYAML: аналогично, Python-парсер JSON и PyYAML берут последнее значение при повторе ключа:

import json, yaml
print(json.loads('{"x": 1, "x": 2}'))  # {'x': 2}
print(yaml.safe_load("x: 1\nx: 2\n"))  # {'x': 2}

Оба возвращают {'x': 2} без каких-либо ошибок.

Нечувствительность парсера к регистру ключей

А вот это — страх и ненависть уже синтаксической валидации.

.NET + Newtonsoft.Json: по умолчанию десериализует свойства класса независимо от регистра имени. Например, C# класс:

class User { public string Name {get;set;} }

и JSON: {"name": "Alice"} – будет корректно десериализован в User.Name = "Alice", хотя регистр не совпадает. Причем тут умножаем на вариацию предыдущей проблемы: если в JSON будет и "Name": "Eve", и "name": "Alice", то первая из них может быть перезаписана второй, т.к. парсер считает их одним свойством, а вот валидатор — далеко не факт.

Вложенные и «полиглотные» форматы данных

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

JSON внутри YAML: YAML является супермножеством JSON, поэтому любой JSON-документ валиден как YAML. Многие YAML-парсеры (PyYAML, js-yaml и др.) спокойно примут строку в формате JSON:

import yaml
yaml_data = yaml.safe_load('{"flag": false, "value": 42}')
print(yaml_data)

Получаем:

{'flag': False, 'value': 42}

Это значит, что если сервис ожидает YAML, то злоумышленник может отправить JSON, и парсер обработает его без ошибок. Если при этом в YAML-обработчике включены какие-то специфичные для YAML особенности (например, типизация строк), они не сработают на JSON-вводе, что может быть использовано для обхода валидации.

Ребята из Trail of Bits показали, как составить вход, который одновременно распознаётся и JSON-, и YAML-, и XML-парсером, но дает разные значения. Идея в том, чтобы использовать вышеперечисленные особенности:

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

– YAML-парсер (работающий в строгом регистре) проигнорирует ключ, не совпадающий точно с именем поля структуры, и возьмет другое значение.

– XML-парсер может найти спрятанный XML-тег внутри строки JSON.

В примере Go-полиглота из статьи, JSON содержал значение поля, начинающееся с <Action3>...</Action3>. Стандартный парсер XML пропустил весь окружающий текст, и извлек содержимое этого XML-тега. В результате один и тот же байтовый поток интерпретировался как действие 2 для JSON, действие 1 для YAML и действие 3 для XML. Такой трюк применим и в других экосистемах: например, если одно приложение читает конфиг как JSON, а другое ошибочно как YAML, или когда данные передаются через несколько сервисов с разными форматами. Злоумышленник может создать двойной формат – например, завернуть JSON в комментарий XML, либо вставить валидный XML-фрагмент в значение JSON – чтобы обмануть систему. Реальный пример – упомянутая уязвимость в HashiCorp Vault, где запрос, содержащий одновременно JSON и XML, обходил аутентификацию из-за разных трактовок на разных этапах.

Чрезмерно толерантный парсинг нестрогого формата

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

Trailing/leading garbage (лишние данные вне структуры): Некоторые парсеры принимают «мусор» до или после основного документа. Старые версии PHP json\_decode ранее допускали трailing символы после JSON, а браузеры принимали JSON с завершающим `)` или `;` как часть JSONP. Известный трюк с CSRF через JSON эксплуатировал толерантность парсеров: отправлялся JSON с лишним символом = в конце и заголовком Content-Type: application/x-www-form-urlencoded – некоторые серверы игнорировали Content-Type и разбирали тело как JSON, не замечая лишний знак =, что обходило ограничения простых запросов SOP.

Java + Jackson: Библиотека Jackson в стандартном режиме читает JSON-поток и может не ругаться, если после корректного JSON-объекта в потоке идут другие данные, пока не включён режим строгости.

Почему это является проблемой? Избыточно «всеядный» парсер открывает возможности для атак в обход протокола. Лишние данные в конце могут быть использованы для скрытия второго запроса или полезной нагрузки (например, JSON плюс SQL-инъекция после него, где JSON-парсер съест своё, а SQL – своё, если данные проходят через разные слои). Лишние данные в начале (пробелы, BOM, комментарии – что не по стандарту JSON) тоже могут игнорироваться некоторыми реализациями JSON5/YAML, что приводит к расхождениям. Кроме того, сверхтолерантность к формату зачастую сопровождается ещё и ошибками реализации. Парсеры на неуправляемых языках вроде C/C++ с подобной гибкостью также могут содержать off-by-one баги или переполнения, приводящие к DoS или RCE при специально сформированном неверном JSON.

Правило простое: если вход не соответствует ожидаемому (и строгому) формату – лучше немедленно отвергнуть его, чем пытаться корректировать или отбрасывать мусор.

А разработчикам делать-то что?

Авторы приводят в конце статьи дельный набор советов, немного его дополню:

1. Включать строгую проверку (strict mode) там, где это возможно

– JSON: явно запрещать все неизвестные поля (DisallowUnknownFields в Go, FAIL_ON_UNKNOWN_PROPERTIES в Jackson, strict=True в Pydantic).

– YAML: включать режим строгого сопоставления (KnownFields(true) в Go, safe_load в PyYAML), запрещать автозагрузку кастомных объектов.

– XML: валидировать по схеме (XSD/DTD).

2. Контролировать глубину и размер

Устанавливать лимиты на глубину вложенности, размер документа и число одновременно выделяемых сущностей. Многие парсеры позволяют отключить entity expansion либо настроить таймауты/лимиты. Btw, в Go (вроде и в некоторых других языках) YAML-парсеры уже начали отдавать ошибку при чрезмерном разворачивании ссылок.

3. Обеспечивать консистентность на всех интерфейсах

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

– Если сервис принимает JSON и YAML — необходимо четко определять ожидания, и не позволять смешивать форматы без необходимости и адекватной валидации. Да банально: если на входе ожидается YAML, проверять, не парсится ли он без ошибок JSON-парсером, и бить тревогу, если это оказалось так.

4. Валидировать результаты парсинга

– Не доверять структуре после parse(): объект не является безопасным только потому, что был создан в результате парсинга входных данных. Необходимо подвергать ео семантической валидации в соответствии с правилами бизнес-логики, а также проверять, что отсутствуют лишние ключи, пересечения с __proto__, значение null и т.п. там, где это не ожидается.

– В JavaScript проверять наличие свойств через Object.prototype.hasOwnProperty.call(...), чтобы избежать Prototype Pollution.

5. Отказывать на любой мусор в данных

– Парсер должен разобрать весь вход: не следует допускать trailing/leading garbage, комментариев в JSON, незакрытых структур и т.д.

– Любое несоответствие данных ожидаемому формату — выброшенное исключение или сообщение об ошибке.

6. Избегать автосериализации приватных/скрытых полей

– В Java/Gson, C#/Newtonsoft, Python/PyYAML отключать сериализацию приватных полей по умолчанию.

– Использовать явное указание разрешённых полей (@Expose, JsonProperty, IncludeFields, Config.allowed_fields) и не доверять ObjectMapper.

7. Использовать статический анализ и автоматические проверки

– Подключить Semgrep и другие SAST‑инструменты, правилом блокирующие omitempty, -‑теги, permissive parsing и ненужные entity в XML/YAML (пример такого правила приведен в оригинальной статье).

– Проводить fuzz‑тестирование используемых парсеров (даже сторонних) с глубокими и полиглотными входами.

8. Документировать форматы и внедрять схемы

– Для JSON использовать JSON Schema, для YAML – JSON Schema совместимую с YAML, для XML – XSD/DTD.

– Встроить автоматическую актуализацию используемых схем в CI/CD пайплайн.

На правах эпилога...

Кто-то сказал «статический анализ»?! 🤩 Но серьезно, что здесь может предложить SAST? Проверить корректность конфигурации парсера? Да, если в его правилах есть экспертиза по конкретной реализации конкретной версии. Но это дело наживное, ок. Убедиться, что контроль грамматики входных данных не позволяет пробросить XML внутри JSON под видом YAML? Ну, смогут (чисто теоретически), но уже далеко не все анализаторы. Зато поискать сомнительные теги в декларациях структуры, как предлагаемое авторами правило Semgrep – вообще легко.

Но почему тогда перед этим правилом авторы делают такую жирную оговорку о false-positive'ах? Да потому, что ни один анализатор не выведет по коду, что именно хотел реализовать разработчик: какова ожидаемая схема разбираемого документа и каким требованиям (и какой) бизнес логики должны соответствовать его сущности. Здесь нужны четкие спецификации того «как должно быть», которые не любят писать разработчики и не умеют читать классические анализаторы. И тут сама собой напрашивается мысль: «но ведь LLM-то уже – ого-го! Наверняка же смогёт, догадается из общего кодового контекста, ведь там AGI уже, ну... почти?».

И вот об этом – мы обязательно скоро поговорим...