feat(materials): record checkmarx engine types via scan.types annotation#3292
Conversation
The Checkmarx crafter is the one place that sees report content, so have it record the distinct engine types present in a CHECKMARX_JSON report as a chainloop.material.scan.types annotation (lower-cased, sorted, comma-joined; e.g. "kics,sast,sca"). This lets attestation-level policies that match purely by annotation (the *-scan-present compliance policies) tell which engines actually produced findings without reading material content, avoiding over-claim on multi-engine reports. A clean or null report advertises no types, so the annotation is omitted rather than set empty and recognition fails closed. Assisted-by: Claude Code Signed-off-by: Javier Rodriguez <javier@chainloop.dev> Chainloop-Trace-Sessions: 23990771-b817-46fa-8543-353be0e9155a
AI Session Analysis
|
| Status | Attribution | File | Lines |
|---|---|---|---|
| modified | ai | pkg/attestation/crafter/materials/checkmarx.go |
+51 / -9 |
| modified | ai | pkg/attestation/crafter/materials/checkmarx_test.go |
+27 / -2 |
| modified | ai | pkg/attestation/crafter/materials/materials.go |
+25 / -4 |
| created | human | pkg/attestation/crafter/materials/testdata/checkmarx-extra-engines.json |
+21 / -0 |
Policies (4)
| Status | Policy | Material | Messages |
|---|---|---|---|
| ✅ Passed | ai-config-ai-agents-allowed |
ai-coding-session-239907 |
- |
| ✅ Passed | ai-config-no-dangerous-commands |
ai-coding-session-239907 |
- |
| ✅ Passed | ai-config-no-secrets |
ai-coding-session-239907 |
- |
| ✅ Passed | ai-config-mcp-servers-allowed |
ai-coding-session-239907 |
- |
Powered by Chainloop and Chainloop Trace
|
|
Yes it's weird but at the same time is how the tool outputs it. The weird thing is the tool mixes on the same report different angles, This is a real example: https://github.com/chainloop-dev/chainloop/blob/main/pkg/attestation/crafter/materials/testdata/checkmarx.json I'll try to come up with something different |
…cabulary Checkmarx names some engines by product (e.g. "kics") rather than by category, so emitting the raw values mixed vendor-specific names with generic scan types in the chainloop.material.scan.types annotation. Introduce a canonical ScanType* vocabulary (sast, sca, iac, container, supply-chain, secrets) in the shared materials package and map the Checkmarx engine identifiers onto it (kics -> iac, containers -> container, sscs -> supply-chain). The annotation now carries only generic scan types, so it stays consistent across material kinds and can be adopted by other multi-engine materials. An engine that maps to no canonical type is dropped from the annotation and logged, so recognition fails closed and no vendor-specific name leaks out. Assisted-by: Claude Code Signed-off-by: Javier Rodriguez <javier@chainloop.dev> Chainloop-Trace-Sessions: 23990771-b817-46fa-8543-353be0e9155a
Description
The Checkmarx One native JSON report (
CHECKMARX_JSON) is multi-engine: a single report can bundle SAST, SCA, KICS (IaC) and container findings. At the attestation level, the crafter previously injected onlychainloop.material.tool.name = checkmarx, so there was no way to tell which engines actually produced findings.This change has the Checkmarx crafter record the distinct engine types present in the report as a new
chainloop.material.scan.typesannotation (lower-cased, sorted, comma-joined; e.g.kics,sast,sca). Annotation-only consumers can then distinguish engines without reading material content. A clean or null report advertises no types, so the annotation is omitted rather than set empty.AI disclosure
This contribution was assisted by Claude Code.