Оценка процессов ГОСТ Р 56939-2024 — Документация CodeGraph

Руководителю разработки и специалисту по информационной безопасности нужно видеть, какие материалы уже собраны для оценки безопасной разработки и что подготовить к следующей проверке. CodeGraph сопоставляет артефакты проекта с 25 процессами раздела 5 ГОСТ Р 56939-2024. Отчёт показывает статус каждого процесса и его доказательства, а история позволяет сравнить два запуска.

Начните с перечня артефактов, сформируйте отчёт и матрицу трассируемости, затем сохраните результаты в историю. Так команда получает общий список работ: дополнить материалы, проверить связи с кодом и тестами, сопоставить изменения с предыдущей оценкой.

Команды оценки

Отчёт помогает провести внутреннюю оценку. Он не выдаёт сертификат и не заменяет независимую оценку соответствия стандарту.

Сценарий отчёта сейчас доступен через CLI:

python -m src.cli compliance gost-56939
python -m src.cli compliance checklist
python -m src.cli compliance traceability
python -m src.cli compliance history
python -m src.cli compliance delta

CLI формирует отчёт, перечень артефактов и матрицу трассируемости, сохраняет историю и сравнивает оценки. Дашборд получает тепловую карту через /api/v1/compliance/heatmap.

Воспроизводимая оценка

Используйте PowerShell и Python-окружение установленного CodeGraph. Перейдите в корень оцениваемого проекта; команда python -m src.cli должна быть доступна из этого каталога. Сборщик и матрица трассируемости читают файлы относительно текущего каталога. --project задаёт только имя отчёта, а не каталог исходников. Передавайте путь к соответствующей DuckDB явно. Без --project имя берётся из имени файла базы; без базы оно равно unknown.

Для локального запуска включите security.local_cli_enabled: true в config.yaml этого проекта. Добавьте приведённые ниже настройки в существующий файл, сохранив остальные секции. Создайте каталог data для истории. Матрица обращается к CPG через работающий сервер GoCPG: настройте его адрес и доступ к выбранной базе по руководству gRPC.

Для локального сервера откройте отдельное окно PowerShell. Замените <GOCPG_BINARY> путём к установленному исполняемому файлу, а <CPG_DIRECTORY> — каталогом выбранной базы. Сохраните это окно открытым на время оценки:

$GoCPG = "<GOCPG_BINARY>"
$CpgDirectory = "<CPG_DIRECTORY>"
& $GoCPG serve --host 127.0.0.1 --port 50051 --data-dir $CpgDirectory

В приведённой конфигурации клиент использует тот же адрес 127.0.0.1:50051. Если ваша установка использует другой порт, измените его и в команде, и в grpc_port. Если адрес уже настроен в project_import.gocpg, измените поля этой секции: она имеет приоритет над верхнеуровневой gocpg.

В окне с активированным Python-окружением CodeGraph укажите корень его checkout (<CODEGRAPH_ROOT>) и корень оцениваемого проекта (<PROJECT_ROOT>). Замените путь базы в $CpgDb:

$CodeGraphRoot = "<CODEGRAPH_ROOT>"
$env:PYTHONPATH = $CodeGraphRoot + [System.IO.Path]::PathSeparator + $env:PYTHONPATH
$ProjectRoot = "<PROJECT_ROOT>"
Set-Location -LiteralPath $ProjectRoot
$ProjectName = "my-project"
$CpgDb = "D:\codegraph-data\my-project.duckdb"
New-Item -ItemType Directory -Path "data", "reports" -Force | Out-Null

python -m src.cli compliance checklist --project $ProjectName --db $CpgDb --format json

python -m src.cli compliance gost-56939 --project $ProjectName --db $CpgDb --format markdown --language ru --include-traceability

Перечень показывает найденные и недостающие артефакты для 23 процессов с настроенными сборщиками. Обучение сотрудников (5.2) и вывод из эксплуатации (5.25) оценивают по организационным материалам. Итоговый отчёт содержит все 25 процессов.

Проверьте имя проекта, число процессов и артефакты для каждого статуса. В JSON эти данные находятся в project_name, summary.total и processes. Вторая команда выводит отчёт в stdout. Для сохранения файла передайте --output:

python -m src.cli compliance gost-56939 --project $ProjectName --db $CpgDb --format gost --language ru --include-traceability --output "gost-56939-report.md"

Используйте --auto-collect только когда разрешено генерировать недостающие входные данные. --force-collect обходит кеш сбора только вместе с --auto-collect; сбор может работать дольше. Сохраняйте эти флаги: они меняют происхождение доказательств.

История и сравнение

Сохраните первую оценку с --save-history. После изменения артефактов повторите команду и сохраните второй отчёт. Используйте два напечатанных идентификатора для сравнения:

python -m src.cli compliance gost-56939 --project $ProjectName --db $CpgDb --format json --save-history --output "gost-56939-before.json"

# Повторите после изменения артефактов проекта.
python -m src.cli compliance gost-56939 --project $ProjectName --db $CpgDb --format json --save-history --output "gost-56939-after.json"

python -m src.cli compliance history --project $ProjectName --limit 10

python -m src.cli compliance delta --old "<older-report-id>" --new "<newer-report-id>"

Замените оба шаблона report ID в кавычках идентификаторами, выданными при сохранении отчётов. С --save-history после отчёта в stdout появляется строка подтверждения. Для обработки JSON используйте --output: файл отчёта останется отделён от этой строки. История использует настроенное SQLite-хранилище; открытие отсутствующего хранилища может создать его.

Если матрица нужна отдельно, сформируйте её явной командой:

python -m src.cli compliance traceability --project $ProjectName --db $CpgDb --format markdown --output "gost-56939-traceability.md"

Сравнение показывает изменения статусов сохранённых оценок. Запишите рядом с обоими идентификаторами ревизию исходников, настройки, режим сбора и ручные доказательства: эти данные объясняют причину изменения.

После сохранения двух отчётов history показывает две новые строки с их идентификаторами и итоговыми процентами. Если артефакты и настройки между запусками одинаковы, delta выводит изменение +0.0% и Unchanged: 25 processes. После изменения входов изучите разделы Improved и Degraded: они перечисляют процессы, у которых изменился статус.

Пример входа для матрицы

Сохраните следующий учебный SARIF в reports/example.sarif относительно корня проекта. Он описывает входную находку docs-example-89, CWE-89 и строку source/sample.c:3. Матрица читает эти поля из SARIF; этот пример проверяет перенос данных внешнего инструмента.

{
  "version": "2.1.0",
  "runs": [
    {
      "tool": {
        "driver": {
          "name": "Traceability example",
          "rules": [
            {
              "id": "DOCS-CWE-89",
              "properties": {
                "tags": [
                  "CWE-89"
                ]
              }
            }
          ]
        }
      },
      "results": [
        {
          "ruleId": "DOCS-CWE-89",
          "message": {
            "text": "Example input for the traceability matrix"
          },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": {
                  "uri": "source/sample.c"
                },
                "region": {
                  "startLine": 3
                }
              }
            }
          ],
          "fingerprints": {
            "primaryLocationLineHash": "docs-example-89"
          }
        }
      ]
    }
  ]
}

Повторите команду compliance traceability выше. В gost-56939-traceability.md появится строка CWE-89 со ссылкой source/sample.c:3; столбец Findings покажет одну находку. Для этого входа без связанных тестов статус равен partial. Чтобы проверить идентификатор находки, сохраните матрицу в JSON:

python -m src.cli compliance traceability --project $ProjectName --db $CpgDb --format json --output "gost-56939-traceability.json"

В записи CWE-89 поле findings содержит docs-example-89, а code_references — source/sample.c:3. В рабочем проекте используйте SARIF своего инструмента: поля находок и расположения кода переносятся тем же способом.

Реестр процессов

Таблица описывает тип оценки и область покрытия. Итоговый статус зависит от фактически найденных артефактов и правил обработчиков оценки.

Тип automated обозначает программный сбор артефактов, external — материалы внешних инструментов, organizational — организационные данные, mixed — сочетание источников.

Реестр процессов
Процесс	Тип	Граница оценки
5.1	organizational	Планирование: ручные и собранные данные
5.2	organizational	Обучение требует ручной оценки
5.3	mixed	Доказательства требований безопасности
5.4	automated	Артефакты управления конфигурацией
5.5	mixed	Артефакты управления недостатками
5.6	automated	Архитектурные артефакты
5.7	automated	Артефакты модели угроз
5.8	automated	Артефакты правил кодирования
5.9	automated	Артефакты экспертизы кода
5.10	automated	Артефакты статического анализа
5.11	external	Динамический анализ из интегрированных инструментов
5.12	mixed	Доказательства безопасной сборки
5.13	mixed	Доказательства безопасности среды сборки
5.14	automated	Артефакты управления доступом
5.15	automated	Артефакты защиты секретов
5.16	external	Доказательства композиционного анализа
5.17	external	Доказательства supply chain
5.18	mixed	Доказательства функционального тестирования
5.19	mixed	Доказательства нефункционального тестирования
5.20	mixed	Доказательства безопасности выпуска
5.21	automated	Артефакты поставки
5.22	organizational	Поддержка требует организационных данных
5.23	mixed	Доказательства реагирования на уязвимости
5.24	automated	Артефакты поиска уязвимостей
5.25	organizational	Вывод из эксплуатации требует ручной оценки

Статусы и расчёт

Каждый процесс получает статус FULL, PARTIAL, GAP или N/A.

FULL даёт 1,0.
PARTIAL даёт 0,5.
GAP даёт 0.
N/A исключается из знаменателя.

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

Поле manual_overrides задаёт запрошенный статус процесса. Для FULL обработчик проверяет порог полноты доказательств (completion_threshold) и соответствующие артефакты. Сохраните основание, согласование и исходный артефакт рядом с отчётом.

В JSON статусы записаны как full, partial, gap и n_a. Например, один FULL, один PARTIAL и один N/A дают (1 + 0,5) / 2 × 100 = 75%. Если все процессы имеют N/A, модель возвращает 0.0, а список применимых процессов остаётся пустым. FULL присваивается при достижении настроенного порога доказательств: по умолчанию 0.8. Откройте артефакты процесса, чтобы увидеть основание оценки. Код завершения 0 подтверждает создание отчёта; статусы GAP и ошибки сбора отображаются в самом отчёте.

Конфигурация

gocpg:
  grpc_host: 127.0.0.1
  grpc_port: 50051
security:
  local_cli_enabled: true
compliance:
  gost_56939:
    enabled: true
    auto_evaluate_on_audit: true
    store_history: true
    history_db_path: "data/compliance_history.sqlite"
    organizational_processes_status: "n_a"
    sarif_search_paths:
      - "data/"
      - "reports/"
    manual_overrides: {}
    content_check_min_bytes: 500
    content_check_read_limit: 8192

enabled включает функцию.
auto_evaluate_on_audit разрешает интеграции аудита запросить оценку.
store_history и history_db_path настраивают историю.
organizational_processes_status задаёт статус организационных процессов по умолчанию.
sarif_search_paths ограничивает поиск SARIF.
manual_overrides передаёт явные запросы статусов.
content_check_min_bytes и content_check_read_limit ограничивают проверки наличия содержимого.

Это общие настройки среды. Явный CLI-сценарий читает history_db_path, sarif_search_paths, manual_overrides и ограничения проверки содержимого. Он не использует enabled, auto_evaluate_on_audit, store_history и organizational_processes_status для управления этим вызовом. В частности, store_history: true не заменяет --save-history. Управляйте сохранением этого запуска через --save-history, а локальным доступом к CLI — через security.local_cli_enabled.

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

Трассируемость и доказательства

Матрица связывает распознанные требования и CWE-данные с кодом, тестами, находками и исправлениями, если такие отношения есть. Пустое поле связи означает, что собранные данные не содержат этой связи. Для оценки меры используйте настроенные источники доказательств.

Для аудируемого запуска сохраните:

ревизию исходников и идентичность проекта;
идентичность и актуальность DuckDB;
ревизию конфигурации;
точную CLI-команду и код завершения;
флаги сбора и входные каталоги;
хеш отчёта и матрицы;
ручные доказательства и решение проверяющего;
известные недоступные источники.

Ошибки и восстановление

Проект определился как unknown или имя файла базы: повторите с --project и --db.
Не хватает артефактов: изучите checklist, исправьте пути и повторите сбор.
Неожиданный FULL или PARTIAL: проверьте артефакты процесса и manual_overrides.
Нет истории: проверьте --save-history и history_db_path.
Delta не строится: проверьте оба идентификатора в одной истории. Для неизвестного идентификатора команда печатает Error: One or both report IDs not found и возвращает 1.
Команда прошла, но данных недостаточно: для закрытия оценки добавьте требуемые свидетельства и решение проверяющего.

Подготовка материалов для следующей оценки

Используйте статусы процессов как список подготовки. Для GAP соберите указанные в перечне материалы; для PARTIAL дополните доказательства и проверьте связи с кодом и тестами. Для FULL откройте артефакты и сохраните основание оценки. После обновления материалов повторите отчёт и сравните его с предыдущим запуском.

Архитектурный контроль — опишите компоненты и проверьте зависимости для процесса 5.6.
Модель угроз — подготовьте модель и диаграмму потоков данных для процесса 5.7.
Композиционный анализ и SBOM — соберите сведения о зависимостях для процесса 5.16.
Безопасность цепочки поставок — проверьте входы сборки и происхождение зависимостей для процесса 5.17.