CodeGraph can collect project evidence and calculate an engineering assessment for the 25 process identifiers in section 5 of GOST R 56939-2024. Use the result as input to a compliance review; certification, an FSTEK conclusion, and organizational-control effectiveness require their own assessments.
Supported surface
The report workflow is currently CLI-based:
- 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
The live REST surface contains /api/v1/compliance/heatmap for dashboard visualization. Generate the
report, checklist, history, and traceability output through the documented CLI surfaces.
Reproducible assessment
Use an explicit project name and its DuckDB path. Do not rely on the fallback project name derived from the current directory.
$ProjectName = "my-project"
$CpgDb = "D:\codegraph-data\my-project.duckdb"
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 en --include-traceability
The first command shows available and missing artifacts. The second writes the report to stdout by default. To create an artifact deliberately, pass –output:
python -m src.cli compliance gost-56939 --project $ProjectName --db $CpgDb --format gost --language en --include-traceability --output "gost-56939-report.md"
Use –auto-collect only when the assessment is authorized to generate missing inputs. –force-collect ignores the collection cache and can take longer. Record those flags because they change how evidence was obtained.
History and comparison
History is written only when –save-history is passed:
python -m src.cli compliance gost-56939 --project $ProjectName --db $CpgDb --format json --save-history
python -m src.cli compliance history --project $ProjectName --limit 10
python -m src.cli compliance delta --old <older-report-id> --new <newer-report-id>
Generate a standalone traceability matrix when it is needed separately:
python -m src.cli compliance traceability --project $ProjectName --db $CpgDb --format markdown --output "gost-56939-traceability.md"
A delta compares stored assessments. Record the source revision, configuration, collection mode, and manual evidence with both report identifiers so the change has its full context.
Process registry
The registry below describes evaluation type and coverage. Actual status is derived from available artifacts and evaluator behavior at runtime.
| Process | Type | Evaluation boundary |
|---|---|---|
| 5.1 | organizational | Planning evidence; manual and collected inputs |
| 5.2 | organizational | Staff training requires manual assessment |
| 5.3 | mixed | Security requirements evidence |
| 5.4 | automated | Configuration-management artifacts |
| 5.5 | mixed | Defect-management artifacts |
| 5.6 | automated | Architecture artifacts |
| 5.7 | automated | Threat-model artifacts |
| 5.8 | automated | Coding-standard artifacts |
| 5.9 | automated | Code-review artifacts |
| 5.10 | automated | Static-analysis artifacts |
| 5.11 | external | Dynamic-analysis evidence from integrated tools |
| 5.12 | mixed | Secure-build evidence |
| 5.13 | mixed | Build-environment evidence |
| 5.14 | automated | Access-control artifacts |
| 5.15 | automated | Secret-protection artifacts |
| 5.16 | external | Composition-analysis evidence |
| 5.17 | external | Supply-chain evidence |
| 5.18 | mixed | Functional-test evidence |
| 5.19 | mixed | Non-functional-test evidence |
| 5.20 | mixed | Release-security evidence |
| 5.21 | automated | Delivery artifacts |
| 5.22 | organizational | Support process requires organizational evidence |
| 5.23 | mixed | Vulnerability-response evidence |
| 5.24 | automated | Vulnerability-search artifacts |
| 5.25 | organizational | Decommissioning requires manual assessment |
Status and score
Each process is classified as FULL, PARTIAL, GAP, or N/A.
- FULL contributes 1.0.
- PARTIAL contributes 0.5.
- GAP contributes 0.
- N/A is excluded from the denominator.
The report percentage is the sum of applicable points divided by the count of applicable processes. A high percentage reflects the evidence recognized by the configured evaluators; certification uses the applicable certification process.
manual_overrides can request a status for a process. A FULL override is guarded by the completion threshold and requires the associated completion evidence. Keep the override rationale, approver, and source artifact outside the generated report when governance requires it.
Configuration
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 controls the feature.
- auto_evaluate_on_audit allows audit integration to request an assessment.
- store_history and history_db_path configure stored assessment history.
- organizational_processes_status is the default organizational status setting.
- sarif_search_paths limits where SARIF evidence is searched.
- manual_overrides supplies explicit per-process requests.
- content_check_min_bytes and content_check_read_limit bound content-presence checks.
Use installation-owned absolute or approved relative paths. Review generated reports before sharing them outside the organization because evidence locations, findings, and project metadata may be sensitive.
Traceability and evidence
The traceability output connects recognized requirements and CWE-related evidence to code, tests, findings, and fixes when those relations are available. An empty relation records that the collected evidence contains no link; evaluate the control through its configured sources.
For an auditable run, record:
- source revision and project identity;
- DuckDB identity and freshness;
- configuration revision;
- exact CLI command and exit code;
- collection flags and input directories;
- generated report and traceability hashes;
- manual evidence and reviewer decision;
- known missing or unavailable sources.
Failure and recovery
- Unknown/current-directory project: rerun with –project and –db.
- Missing artifacts: inspect checklist, correct input paths, then recollect.
- Unexpected FULL or PARTIAL: inspect process artifacts and manual_overrides.
- History missing: confirm –save-history and history_db_path.
- Two reports cannot be compared: verify both report identifiers exist in the same history store.
- Runtime command succeeds but evidence is incomplete: keep the assessment open and complete the compliance review before recording the verdict.
Source contracts
- src/cli/security_suite/compliance_commands.py — CLI arguments, output, history, and collection flags
- src/compliance/gost_56939/artifact_collector.py — evidence collection
- src/compliance/gost_56939/process_evaluator.py — 25-process registry and status decisions
- src/compliance/gost_56939/models.py — statuses and score
- src/compliance/gost_56939/report_renderer.py — markdown, JSON, and GOST rendering
- src/compliance/gost_56939/compliance_store.py — history and delta
- src/compliance/gost_56939/traceability.py — traceability matrix
- src/config/runtime_sections/unified_config_runtime_models.py — configuration fields