Improve the visibility, consistency, and synchronization of finding/vulnerability states and related triage information between Harness and Checkmarx CxOne. The goal is to ensure that developers and AppSec teams see a consistent and meaningful representation of a finding regardless of whether they are working in Harness or Checkmarx. REQUIRED IMPROVEMENTS STATE AND STATUS SYNCHRONIZATION The ongoing effort to implement synchronization between Harness and Checkmarx should cover all state-changing actions related to Checkmarx findings/vulnerabilities. Synchronization should include, where supported by the respective APIs: Finding state/status changes Comments and predicates/reasons Exemption requests Exemption approval or rejection Exemption expiration dates Other relevant triage metadata Synchronization should work in the required direction depending on the workflow: Checkmarx -> Harness Harness -> Checkmarx Changes performed in either platform should not result in conflicting or misleading finding states. STATUS MAPPING BETWEEN HARNESS AND CHECKMARX Harness-specific statuses and exemption reasons must be mapped to meaningful Checkmarx states or predicates. Examples of Harness exemption reasons include: False Positive Acceptable Risk Acceptable Use Fix Unavailable Compensating Controls Other The integration should define an explicit mapping between these values and the appropriate Checkmarx state/predicate. A generic Harness status such as "Remediated" must not be displayed when the underlying Checkmarx finding has not actually been remediated. EXEMPTION EXPIRATION Harness allows an exemption request to specify an expiration period through the "For how long?" option. If Checkmarx supports an equivalent expiration date or validity period through its APIs, this information should also be synchronized. Expiration should remain consistent between both systems so that a temporary exemption in Harness cannot become an indefinite state in Checkmarx, or vice versa. FINDING INFORMATION VISIBILITY In general, all useful information provided by Checkmarx for a particular finding/vulnerability should also be available in Harness, provided that the information is exposed through the Checkmarx APIs. This should especially include information that helps developers and AppSec teams: Understand the vulnerability Validate whether the finding is applicable Triage the finding Determine remediation options Understand previous triage decisions Review comments and reasoning Understand the current Checkmarx state Identify exemptions and their expiration Navigate back to the corresponding Checkmarx finding when deeper investigation is required Harness should provide enough Checkmarx context that users do not need to switch to Checkmarx for basic triage and remediation information. RBAC AND APPROVAL WORKFLOW The RBAC model for security findings in Harness needs to be clarified and potentially adjusted. Currently, even as an AppSec member, the available action appears to be limited to "Request Exemption". The expected workflow should distinguish between developer and AppSec responsibilities. Developers should be able to: Review findings Add relevant comments or justification Request an exemption or state change Propose an appropriate reason, such as False Positive or Acceptable Risk or Not Exploitable AppSec should be able to: Review developer requests Approve or reject exemption/state-change requests Perform security triage Update relevant finding states where appropriate Add or update security comments/predicates Manage or override exemptions according to the defined governance model A developer-requested risk acceptance, false-positive classification, or equivalent security decision should not become authoritative without the required AppSec approval. CONFIRMED / TO_VERIFY WORKFLOW Currently, AppSec members also appear unable to explicitly triage a finding and mark it as "Confirmed", which is possible in Checkmarx. This needs to be clarified. There are two possible approaches: Option 1 - Expose an explicit Confirmed action in Harness AppSec can review a TO_VERIFY finding and explicitly confirm that the vulnerability is valid. Option 2 - Treat the absence of an exemption as implicit confirmation If the Harness workflow intentionally does not require a separate Confirmed state, this behavior should be clearly defined and documented. The preferred solution should ensure that the Harness representation remains semantically consistent with the underlying Checkmarx finding lifecycle. EXPECTED OUTCOME Harness should provide a consistent security finding lifecycle in which: Checkmarx remains synchronized with relevant actions performed in Harness. Harness accurately represents the current Checkmarx state. Status labels cannot incorrectly imply that a vulnerability has been remediated. Triage comments, reasons, exemptions, and expiration dates remain synchronized. Developers can request security decisions. AppSec can review, approve, reject, and perform security triage. Sufficient Checkmarx finding information is available directly within Harness for effective triage and remediation.
