Checkmarx auth into ADO for Feedback Apps needs work

31 Mar 2026 🔖 security devops azure integration
💬 EN

I recently learned about Checkmarx One Feedback Apps, which can open “please fix this bug” tickets in your software developers’ work-tracking software (e.g. JIRA, GitHub Issues, Azure DevOps Boards) whenever a static application security testing (“SAST”) scan fails. I love the way this can help developers remember what failed and get their usual work-tracking system’s nudges to doing the fix. However, I’m not thrilled about the security model of how Checkmarx One authenticates into Azure DevOps (ADO).

The ADO REST API’s work item create endpoint is perfectly happy to accept a short-lived bearer token owned by a Entra Service Principal corresponding to a nonhuman ADO user.

And yet, when configuring a Feedback App in Checkmarx One, the Credentials tab only offers pasting in a long-lived human ADO personal access token (“PAT”).

• (I say human PAT, because I’m 99.5% certain ADO won’t even let its nonhuman users generate long-lived PATs.)

Why impersonating humans is bad

Forcing the Checkmarx One to impersonate a human ADO user, rather than allowing it to act as a distinct nonhuman ADO user:

1. Hurts auditability. It becomes hard to tell whether a human actually created a malicious ADO Boards work item (yes, those are a thing now, thanks to LLMs!) or whether Checkmarx One was compromised and acted in the human’s name.
2. Widens the blast radius. The human account used may have broader ADO-work-item-writing permissions than an enterprise would have granted to a purpose-built nonhuman identity.
3. Breaks on employee changes. When the human leaves or changes roles, credential lifecycle and ownership become toilsome and fragile.

What Checkmarx should do ASAP

Short-term mitigations

Complain

Open a ticket with Checkmarx and ask them to get on fixing the Credentials tab of the ADO Feedback App to offer more than just human PATs – it needs to be able to be wired up to things like Entra Service Principals as well.

Roll your own

You don’t have to use the Checkmarx One web portal’s ADO feedback app. You could always roll your own imitation of it in-house.

Within whatever CI/CD pipeline kicks off a Checkmarx scan and watches for the results:

1. Have the next step authenticate the az CLI as your Entra Service Principal that happens to be a nonhuman ADO user.
2. Have the step after that (e.g. PowerShell or Bash script) parse the scan results and, as it sees fit, use commands like az boards query and like az boards work-item create to create work items in Azure Boards.

Accept the risk

(Note: this section was LLM-generated, but I generally agree with it.)

If you cannot live without the Azure Boards Feedback App within Checkmarx One, and if you’re not willing to roll your own in-house imitation of it, here are some mitigations you could consider:

• Use a dedicated, minimal‑privilege ADO integration account that corresponds to an Entra “human” but is not really human. (Do not use a broadly privileged personal account.)
• Limit the PAT scope to work‑item read/write only.
• Store the PAT in a hardened secrets vault and automate rotation.
• Add provenance metadata to created work items (e.g., “Created by Checkmarx Feedback App — svc-checkmarx”).
• Monitor and alert on unusual work‑item volumes, off‑hours activity, or suspicious content.
• Document the risk appropriately, and also document your need to upgrade to using an Entra Service Principal as soon as Checkmarx hopefully finally offers it.