feat(materials): record checkmarx engine types from SARIF via scan.types annotation#3296
Merged
Conversation
…pes annotation Enrich the SARIF crafter so a Checkmarx One report emits the shared chainloop.material.scan.types annotation, mirroring the native CHECKMARX_JSON crafter. Engine types are read from the (engine) ruleId suffix ast-cli appends to every rule, gated on Checkmarx detection, and normalized onto the canonical scan-type vocabulary via the existing checkmarxEngineToScanType map. Unrecognized engines are dropped so recognition fails closed and never over-claims for other tools. Assisted-by: Claude Code Signed-off-by: Javier Rodriguez <javier@chainloop.dev> Chainloop-Trace-Sessions: a306a5c2-d7a3-4c8c-b021-584300a909fe
Contributor
AI Session AnalysisMissing AI Coding SessionsWe detected commits in this PR that were AI-assisted, but the matching Chainloop Trace session(s) could not be found in Chainloop. Please make sure the AI coding session evidence has been sent by the Chainloop CLI, or add the Learn more about Chainloop Trace. Powered by Chainloop and Chainloop Trace |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 4 files
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
Address review feedback on the Checkmarx SARIF scan.types extraction: - Read the engine from each finding's ruleId instead of the driver's rule catalog, so a report carrying rule metadata without matching findings no longer overstates scan.types. This keeps the annotation findings-based, consistent with the native CHECKMARX_JSON crafter. - Detect and extract per run rather than gating on the whole document, so a multi-run SARIF that mixes a Checkmarx run with another tool's run no longer attributes the other tool's suffixed rule ids to Checkmarx. Assisted-by: Claude Code Signed-off-by: Javier Rodriguez <javier@chainloop.dev> Chainloop-Trace-Sessions: a306a5c2-d7a3-4c8c-b021-584300a909fe
migmartri
approved these changes
Jul 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Enriches the SARIF crafter so a Checkmarx One SARIF report advertises the engines that produced its findings through the shared
chainloop.material.scan.typesannotation, mirroring the nativeCHECKMARX_JSONcrafter (COM-372).Checkmarx One bundles every engine (sast, sca, kics, containers, sscs) under a single driver, so the driver name alone cannot tell attestation-level policies which analyses actually ran. The engine type is recovered from the
(engine)suffix ast-cli appends to every SARIF rule id, gated on Checkmarx detection (driver name or thecheckmarxrule tag), and normalized onto the canonical scan-type vocabulary using the same map the native crafter uses (kics→iac,containers→container,sscs→supply-chain). Engines that cannot be classified are dropped, so recognition fails closed and never over-claims for other tools.A Checkmarx SARIF and the equivalent native JSON report now yield the identical
scan.typesvalue, so the*-scan-presentcompliance policies can key on it uniformly regardless of material type once the compliance-manifests side ships.This contribution was assisted by Claude Code.