SAST для 1С: статический анализ безопасности кода

SAST для 1С это статический анализ исходного кода BSL на предмет уязвимостей без запуска конфигурации. В MCP-1C анализ безопасности 1С выполняет инструмент bulk_analyze: он проходит по всей кодовой базе сразу и среди прочего выдаёт аудит безопасности. Это возможность Профессиональной редакции, на карточке инструмента стоит соответствующий бейдж.

Аудит безопасности BSL опирается на 11 правил SEC: SQL-инъекции, небезопасные вызовы, утечки данных. Каждая находка привязана к объекту и строке кода, получает приоритет по CVSS и выгружается в SARIF для CI.

Что делает bulk_analyze

bulk_analyze это массовый анализ всей кодовой базы, в отличие от разбора одного модуля. У инструмента несколько действий:

Действие security помечено как устаревший алиас. Рекомендуемый способ запросить аудит безопасности это action: findings с category: security.

Какие уязвимости 1С ищет анализатор

Каждое SEC-правило размечено CWE-кодом, чтобы находку можно было связать с публичной классификацией слабостей. Несколько примеров из размеченных правил:

Сопоставление с CWE ведётся в коде, а не из внешней базы. Поэтому отчёт работает офлайн и не зависит от доступности NVD или MITRE. CWE (Common Weakness Enumeration) это список типовых слабостей ПО под управлением MITRE при поддержке CISA, OWASP это некоммерческий фонд по безопасности приложений. Рядом с находками приводятся ссылки на обе классификации.

Граница честности: правило SEC006 в версии v2.23.0 переработано так, чтобы давать меньше ложных срабатываний. Ложные срабатывания есть у любого статического анализатора, инструмент видит код, а не намерение, и каждое правило приходится калибровать отдельно.

Приоритизация по CVSS

Список из сотни находок без приоритета бесполезен. Поэтому начиная с v2.23.0 каждая SEC-находка получает CVSS 3.1 Base Score, severity и vector string. Vector привязан к правилу в YAML-метадате, а score вычисляется из vector по формуле CVSS 3.1 Base, без Temporal и Environmental. Если у правила vector не размечен, score не появляется, но находка остаётся с базовой severity по уровню правила.

Качественная шкала severity совпадает с официальной шкалой FIRST:

Используется именно 3.1, а не 4.0. Причина практическая: многие публичные реестры уязвимостей, статанализаторы и SIEM по-прежнему работают с 3.1-вектором.

Формат отчёта по находкам безопасности задаётся параметром cvss_format при action: findings и category: security:

Подавление находок

Когда находка разобрана и признана неактуальной, её можно подавить прямо в коде комментарием:

// audit:ignore SEC009 -- параметр приходит из константы, конкатенация безопасна
Запрос.Текст = "ВЫБРАТЬ * ИЗ " + ИмяТаблицы;

Поддерживается блочная форма // audit:ignore-begin ... // audit:ignore-end и срок действия [expires ГГГГ-ММ-ДД]. Подавленные находки по умолчанию не учитываются в сводках. В SARIF они помечаются массивом suppressions[], а по флагу include_suppressed возвращаются в ответе отдельной помеченной секцией, то есть не скрываются совсем, а показываются как осознанно отключённые. Подавление находок появилось в v2.23.0 и доступно в Профессиональной редакции.

Использование suppressions[] соответствует стандарту: SARIF 2.1.0 это формат OASIS, и свойство suppressions на объекте result как раз предназначено для метаданных о намеренно подавленных находках.

Соответствие требованиям: справочно

В аудите безопасности рядом со ссылками на CWE и OWASP приводятся справочные сопоставления находок с мерами ГОСТ Р 57580.1 и приказа ФСТЭК России N 21. ГОСТ Р 57580.1-2017 это национальный стандарт по защите информации финансовых организаций, приказ ФСТЭК N 21 утверждает состав мер по безопасности персональных данных в ИСПДн.

Важно понимать рамки: это справочная информация для оценки и приоритизации, она не является сертификацией или подтверждением соответствия. Сопоставление появилось в v2.22.0 и уточнено в v2.23.0.

SARIF и CI

В SARIF-файле свойство security-severity со строковым значением CVSS Base Score ставится на объект правила. GitHub Code Scanning читает это поле и сам определяет критичность результата, без дополнительной настройки CI. CWE и OWASP попадают в SARIF не отдельными свойствами, а тегами таксономии, например external/cwe/cwe-94 и owasp-top10-2021/a03-injection. Поля cvss_vector и cwe относятся к JSON-ответу с находками, а не к SARIF-файлу.

{
  "properties": {
    "security-severity": "9.8",
    "tags": [
      "security",
      "external/cwe/cwe-94",
      "owasp-top10-2021/a03-injection"
    ]
  }
}

Как запустить

bulk_analyze не работает без предварительно построенного кэша. На карточке инструмента прямо указано требование: --dump плюс --build-bulkanalysis. Поскольку аудит безопасности это функция Профессиональной редакции, запускается он бинарником mcp-1c-pro.

1. Построить кэш массового анализа один раз:

mcp-1c-pro --dump /path/to/config-dump --build-bulkanalysis

2. Подключить сервер к MCP-клиенту по stdio. Транспорт по умолчанию это stdio: клиент сам запускает бинарник и общается с ним через stdin и stdout, отдельные порты и HTTP не нужны. Формат конфига для Claude Desktop:

{
  "mcpServers": {
    "mcp-1c": {
      "command": "/usr/local/bin/mcp-1c-pro",
      "args": [
        "--base", "http://localhost:8080/hs/mcp-1c",
        "--dump", "/path/to/config-dump",
        "--user", "Администратор",
        "--password", ""
      ]
    }
  }
}

После этого в чате доступен bulk_analyze: запрос аудита это action: findings с category: security, группировку задаёт cvss_format, подавленные находки достаются флагом include_suppressed.

Граница честности: точная CLI-сигнатура --build-bulkanalysis со всеми дополнительными флагами и путём SARIF-файла в наших публичных доках раскрыта не полностью, и отдельного флага экспорта SARIF именно для аудита безопасности там не названо. Конкретные пути и имена флагов сверяйте с актуальной документацией или выводом самого бинарника, не подставляйте наугад.

Один модуль и переиспользование результата

Если нужен глубокий разбор не всей базы, а одного модуля, есть action: explain в инструменте code_analyze с шестью анализаторами: сложность, ошибки, стиль, производительность, безопасность, совместимость.

Результаты аудита безопасности переиспользуются для тестов: команда --build-testgen формирует Vanessa .feature сценарии для taint-находок с критичностью CVSS не ниже Medium по правилу TG020. Это тоже возможность Профессиональной редакции.

Где это в редакциях

В прайсе строка аудита безопасности отмечена для Профессиональной редакции (и для Корпоративной, которая в разработке), у Открытой и Расширенной стоит прочерк. Отдельными строками идут справочные меры ГОСТ Р 57580 и ФСТЭК-21 в аудите, а также подавление находок через audit:ignore, и обе строки доступны в тех же редакциях.

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