NO-JIRA: support: add redhat-support skill for CVE lookup and validation

[gkneighb]

Proposal and discussion in #25.

cluster-update/update-advisor references a redhat-support skill ("Never fabricate ... CVE numbers. Use the redhat-support skill to get real data.") but the skill doesn't exist yet. This adds it.

What's in this PR

• support/redhat-support/SKILL.md — wraps the public Red Hat Security Data API (https://access.redhat.com/hydra/rest/securitydata, no auth required). Covers CVE validation, severity / CVSS / Bugzilla lookup, affected-products checks, RHSA lookup for a product, and search by package / advisory / severity+date.
• support/redhat-support/references/security-data-api.md — field-by-field schema for the single-CVE and CVE-list responses, including filter parameters, package_state vs affected_release semantics, and what the API does not expose (CVRF/CSAF/errata bodies/KB solutions — out of scope; surface the public errata URL instead).

Format follows cluster-update/product-lifecycle.

Out of scope

CVRF/CSAF documents, direct advisory bodies, and KB solutions (/solutions/<id> requires auth) are not exposed by this public API. The skill documents this and points to access.redhat.com/errata/<RHSA> URLs for callers that need full advisory contents. KB lookup, in particular, would need a different access pattern and is left for a follow-up.

Location

Staged under support/redhat-support/ to align with @harche's planned support/jira/ (#9), since both are support-system integrations. Happy to move if a different parent fits better — support/OWNERS isn't created here; root OWNERS applies until #9 or a similar PR establishes one.

Verification

• Every curl + jq example in SKILL.md was executed against the live API and confirmed to produce the documented output.
• The skill was end-to-end tested by spawning an independent agent with no prior context, given two realistic CVE questions:
  1. "Is CVE-2024-3094 a concern on RHEL 9, and what's the severity?" — agent ran the validation + product-check examples, correctly returned "Not affected, severity Critical."
  2. "Which RHSA fixed CVE-2024-1086 on RHEL 9 proper, excluding EUS?" — agent ran the find-RHSA example.
• That test surfaced three real issues, all addressed in this PR:
  • A startswith ambiguity between Red Hat Enterprise Linux 9 and its EUS variants. Split into an exact-match recipe (RHEL 9 proper only) and a family-match recipe (includes EUS/AUS/E4S), with explicit guidance on which to use.
  • Undocumented duplicate (product_name, advisory) entries in affected_release[] (one per arch/sub-package). Examples now use unique_by(), and the schema reference documents the duplication.
  • cvss3 sub-fields were only in the JSON example, not the schema table. Added a dedicated cvss3 sub-fields section in the reference doc.

Type of change

• New feature

Related Tickets & Documents

• Closes Proposal: add redhat-support skill for CVE lookup and validation #25

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests. (End-to-end agent test described above.)

[openshift-ci-robot]

@gkneighb: This pull request explicitly references no jira issue.

Details

In response to this:

Proposal and discussion in #25.

cluster-update/update-advisor references a redhat-support skill ("Never fabricate ... CVE numbers. Use the redhat-support skill to get real data.") but the skill doesn't exist yet. This adds it.

What's in this PR

• support/redhat-support/SKILL.md — wraps the public Red Hat Security Data API (https://access.redhat.com/hydra/rest/securitydata, no auth required). Covers CVE validation, severity / CVSS / Bugzilla lookup, affected-products checks, RHSA lookup for a product, and search by package / advisory / severity+date.
• support/redhat-support/references/security-data-api.md — field-by-field schema for the single-CVE and CVE-list responses, including filter parameters, package_state vs affected_release semantics, and what the API does not expose (CVRF/CSAF/errata bodies/KB solutions — out of scope; surface the public errata URL instead).

Format follows cluster-update/product-lifecycle.

Out of scope

CVRF/CSAF documents, direct advisory bodies, and KB solutions (/solutions/<id> requires auth) are not exposed by this public API. The skill documents this and points to access.redhat.com/errata/<RHSA> URLs for callers that need full advisory contents. KB lookup, in particular, would need a different access pattern and is left for a follow-up.

Location

Staged under support/redhat-support/ to align with @harche's planned support/jira/ (#9), since both are support-system integrations. Happy to move if a different parent fits better — support/OWNERS isn't created here; root OWNERS applies until #9 or a similar PR establishes one.

Verification

• Every curl + jq example in SKILL.md was executed against the live API and confirmed to produce the documented output.
• The skill was end-to-end tested by spawning an independent agent with no prior context, given two realistic CVE questions:

1. "Is CVE-2024-3094 a concern on RHEL 9, and what's the severity?" — agent ran the validation + product-check examples, correctly returned "Not affected, severity Critical."
2. "Which RHSA fixed CVE-2024-1086 on RHEL 9 proper, excluding EUS?" — agent ran the find-RHSA example.

• That test surfaced three real issues, all addressed in this PR:
• A startswith ambiguity between Red Hat Enterprise Linux 9 and its EUS variants. Split into an exact-match recipe (RHEL 9 proper only) and a family-match recipe (includes EUS/AUS/E4S), with explicit guidance on which to use.
• Undocumented duplicate (product_name, advisory) entries in affected_release[] (one per arch/sub-package). Examples now use unique_by(), and the schema reference documents the duplication.
• cvss3 sub-fields were only in the JSON example, not the schema table. Added a dedicated cvss3 sub-fields section in the reference doc.

Type of change

• New feature

Related Tickets & Documents

• Closes Proposal: add redhat-support skill for CVE lookup and validation #25

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests. (End-to-end agent test described above.)

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: gkneighb
Once this PR has been reviewed and has the lgtm label, please assign harche for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Hi @gkneighb. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.