Report To Jira

Report to Jira

Posts the completed CVE analysis report as a comment on the source Jira ticket — the same ticket the CVE details were read from (SOURCE_TICKET, set in Phase 0.5 from --jira=/--jql=). Always called as the last step of Phase 4, after the report has been generated. Also reused by create-fix-pr (Phase 6) for a short follow-up comment containing the PR URL.

If no Jira ticket was involved (direct <CVE-ID> mode), this skill is skipped entirely — there is nothing to post to.

Step 1: Confirm Report is Ready

Before posting, verify the following are available from the parent command:

• Final report content (full markdown from Phase 3)
• CVE ID (e.g. CVE-2024-45338)
• SOURCE_TICKET — the Jira ticket key from --jira=/--jql= (e.g. OCPBUGS-12345). This is the only ticket this skill writes to.
• jira_context — label snapshot from Phase 0.5 (jira_context["labels"]); used as a hint only — Step 4.5 re-fetches current labels before writing
• Risk level (HIGH / MEDIUM / LOW / NEEDS_REVIEW)
• AUTO_APPROVE (yes/no, default no) — governs the Step 3b visibility-downgrade fallback prompt

If SOURCE_TICKET is not available (direct CVE mode): return status: skipped with reason "no_source_ticket".

If the report is incomplete or Phase 3 did not finish, return status: skipped with reason.

Step 2: Build the Comment Body

Read ${AI_HELPERS_WORKSPACE:-.}/.work/compliance/analyze-cve/${CVE_ID}/report.md from Phase 3 and post it in full. The Jira comment is the report — do not pre-emptively shorten it or write a separate jira-comment.md.

Write standard Markdown — Jira Cloud renders Markdown natively when posted with contentFormat: "markdown" (see markdown-for-jira reference if that plugin is installed; the syntax is standard CommonMark either way). No wiki-markup conversion is needed.

Default body = attribution header + entire report.md. If Phase 4 produced a remediation plan not already under ## Remediation in the report, append it as ## Remediation Plan (Phase 4).

Prepend the following attribution header before the report:

> ⚠️ **This analysis was performed automatically by `/compliance:analyze-cve`.**
> Results should be reviewed by a human before acting on remediation steps.

---

Size limit handling

Jira comment bodies are capped at 32,767 characters. Apply these steps in order — only move to the next step if the comment is still over 32,000 chars:

1. Post in full (≤ 32,000 chars) — no changes.
2. Trim raw tool dumps only (> 32,000 chars) — inside fenced code blocks, replace full govulncheck scrollback, call-graph DOT, or megabyte grep output with a one-line pointer:

   _(Full output truncated — see `${AI_HELPERS_WORKSPACE:-.}/.work/compliance/analyze-cve/<CVE_ID>/govulncheck-source.txt`)_

   Keep executive summary, CVE context, evidence interpretations, call-graph results table, risk assessment, and remediation in full. Re-measure.
3. Shortened summary (last resort only) — if still > 32,000 chars after step 2, replace the body with a condensed summary derived from report.md. Retain: risk level, repository/branch/commit, dependency versions, govulncheck conclusion, four-algorithm call-graph table, manual verification findings, recommendation, and artifact paths. Omit repeated narrative and any remaining large code blocks. Note at the top:

   _(Full report exceeded Jira comment limit — summary below. See `${AI_HELPERS_WORKSPACE:-.}/.work/compliance/analyze-cve/<CVE_ID>/report.md`.)_

   Do not use a shortened summary unless steps 1–2 are insufficient.

Stripping rules (apply regardless of size)

• Remove internal email addresses — replace with the display name only.
• Do not include embargoed content — if somehow reached here with embargo_status: True, abort immediately.

Step 3: Post the Comment

Credential rule: Never print, echo, or log any token, key, or password value. Reference credentials only via environment variable names. Never interpolate a credential value into a logged string.

CVE analysis reports contain security-sensitive findings. Prefer restricted (internal-only) visibility when the Jira instance supports it.

Step 3a: Direct REST API with restricted visibility (attempt first, if credentials are configured)

If a token is available in the environment, try the REST API directly so the comment can carry a visibility restriction the MCP tool does not support. Try both auth schemes and let the HTTP response decide which one worked — credentials may be exposed differently depending on the runtime (a local shell with a bare token vs. a CI/RWS runner with a mounted service-account email+token pair):

1. Basic auth (email + API token) — the scheme most Jira Cloud instances actually expect for API tokens. Used when both JIRA_EMAIL and a token are available.
2. Bearer token only — fallback for runtimes that expose only a bare token env var with no associated email.

JIRA_API_TOKEN="${JIRA_API_TOKEN:-${JIRA_TOKEN:-${ATLASSIAN_API_TOKEN:-}}}"
JIRA_BASE_URL="${JIRA_URL:-}"
JIRA_EMAIL="${JIRA_EMAIL:-}"

if [ -n "${JIRA_API_TOKEN}" ] && [ -n "${JIRA_BASE_URL}" ]; then
  case "${JIRA_BASE_URL}" in
    https://*) ;;
    *) echo "ERROR: JIRA_BASE_URL must use HTTPS (got: ${JIRA_BASE_URL})"; exit 1 ;;
  esac

  cat > /tmp/cve-report-comment.txt << 'COMMENT_EOF'
<constructed comment from Step 2>
COMMENT_EOF

  COMMENT_BODY=$(cat /tmp/cve-report-comment.txt)
  COMMENT_JSON_BODY=$(echo "${COMMENT_BODY}" | python3 -c "import json,sys; print(json.dumps(sys.stdin.read()))")

  post_comment() {
    # $1 = auth mode: "basic" (email+token) or "bearer" (token only)
    # Build the Authorization header inside this function after set +x so
    # credentials never appear in traced argv when post_comment is invoked.
    local auth_mode="$1" curl_cfg http_code auth_header
    curl_cfg=$(mktemp)
    chmod 600 "${curl_cfg}"
    trap 'rm -f "${curl_cfg}"' RETURN EXIT INT TERM
    [[ $- == *x* ]] && local _was_tracing=true || local _was_tracing=false
    set +x
    if [ "${auth_mode}" = "basic" ]; then
      auth_header="Basic $(printf '%s:%s' "${JIRA_EMAIL}" "${JIRA_API_TOKEN}" | base64 | tr -d '\n')"
    else
      auth_header="Bearer ${JIRA_API_TOKEN}"
    fi
    printf 'header = "Authorization: %s"\n' "${auth_header}" > "${curl_cfg}"
    unset auth_header
    $_was_tracing && set -x || true

    http_code=$(curl -s -o /tmp/jira-post-response.txt -w "%{http_code}" \
      --connect-timeout 15 \
      --max-time 60 \
      -X POST \
      -K "${curl_cfg}" \
      "${JIRA_BASE_URL}/rest/api/2/issue/${SOURCE_TICKET}/comment" \
      -H "Content-Type: application/json" \
      --data-binary @- << EOF
{
  "body": ${COMMENT_JSON_BODY},
  "visibility": {
    "type": "group",
    "value": "Red Hat Employee"
  }
}
EOF
)
    echo "${http_code}"
  }

  HTTP_STATUS=""
  if [ -n "${JIRA_EMAIL}" ] && [ -n "${JIRA_API_TOKEN}" ]; then
    echo "Attempting REST post with Basic auth (email + token)..."
    HTTP_STATUS=$(post_comment basic)
  fi

  # Only retry with the other auth scheme when Basic wasn't attempted at all
  # (no JIRA_EMAIL) or came back with an actual auth failure (401/403). This
  # POST is not idempotent: retrying it for every other status (400, 429,
  # 5xx, or curl's own "000") risks creating a duplicate comment if the first
  # request was actually accepted server-side but the response was lost or
  # malformed. Any other failure goes straight to Step 3b instead of retrying.
  if { [ -z "${HTTP_STATUS}" ] || [ "${HTTP_STATUS}" = "401" ] || [ "${HTTP_STATUS}" = "403" ]; } && [ -n "${JIRA_API_TOKEN}" ]; then
    echo "Attempting REST post with Bearer auth..."
    HTTP_STATUS=$(post_comment bearer)
  fi

  echo "Jira API HTTP status: ${HTTP_STATUS:-none attempted}"
  if [ "${HTTP_STATUS}" = "201" ]; then
    echo "✓ Comment posted with restricted visibility"
  else
    echo "✗ REST API failed (HTTP ${HTTP_STATUS:-n/a}) — will fall back to MCP tool"
    cat /tmp/jira-post-response.txt 2>/dev/null || true
  fi
fi

The visibility object above targets redhat.atlassian.net. On other Jira Cloud instances, adjust type/value to match an equivalent internal-only group, or omit visibility entirely if none exists.

• IF HTTP 201 (either scheme) → done. Skip Step 3b.
• IF credentials are not configured → continue to Step 3b.
• IF HTTP 401/403 on both schemes (or Basic wasn't attempted and Bearer also fails) → credentials not available or insufficient permissions; continue to Step 3b.
• IF Basic auth returns any other status (400, 429, 5xx, curl error 000) → do not retry with Bearer (the POST is not idempotent) — go directly to Step 3b.
• Never print JIRA_API_TOKEN, JIRA_EMAIL, the computed BASIC_AUTH value, or the contents of ${curl_cfg} — only the HTTP status code and response body (which contains no credentials).