file-security-defect

name	file-security-defect
description	Use when the user wants to file a Jira ticket for a security vulnerability found in an audit report — populating the defect from the audit finding with full description, affected code, and remediation, and setting the Security Level to Embargoed Security Issue.

File Security Defect

Create an embargoed Jira defect for one or more Critical/High security vulnerabilities from a team's security audit findings package. The skill populates the defect from the audit report finding — preserving the full description, affected code, and remediation verbatim — and sets the Security Level to "Embargoed Security Issue."

Input

$ARGUMENTS is two parts:

1. A path to a findings file or folder — either:

   • A specific audit report Markdown file, e.g. compliance-operator/compliance-operator-security-audit.md
   • A findings folder containing component subdirectories and a README, e.g. compliance-operator-findings/

2. One or more finding identifiers — e.g. FIND-001, FIND-001 FIND-003, or all-critical / all-high to select by severity — or --hardening to file the component's hardening backlog (see "Hardening path" below).

The user has access to only their own team's findings folder (a single directory under progress-tracker/processed-results/). All paths are relative to the user's working directory unless absolute.

Examples

/file-security-defect compliance-operator/compliance-operator-security-audit.md FIND-001

/file-security-defect compliance-operator-findings/ FIND-001 FIND-003

/file-security-defect loki-operator-findings/ all-critical

/file-security-defect pac-downstream/pac-downstream-security-audit.md all-high

/file-security-defect compliance-operator-findings/ --hardening

---

Hardening path (non-embargoed, harness ≥ 0.31.0)

Hardening-verdict findings (accurate defense-in-depth/benchmark gaps with no demonstrated exploit path — docs/disposition-ledger.md §7) are engineering hygiene work, not security defects. With --hardening:

1. Collect the component's hardening backlog from <component>-triage.json (verdict: "hardening") or <component>-findings-current.json (validation_status: "hardening").
2. File ONE regular Jira issue per component (issue type Story or Task, ask the user which their project uses) titled Security hardening backlog: <component> (<N> items), batching the items as a checklist — each with title, location, category, and the finding's remediation text verbatim.
3. Do NOT set the Embargoed Security Issue security level — these are deliberately non-embargoed: there is no exploit to protect, and hiding hygiene work reduces the chance it gets scheduled. Do not attach CVSS.
4. Priority: Normal (or the project's default). Note in the description that the backlog is λ-weighted in the portfolio risk index (findings-trends hardening burndown) and that closing these items also de-amplifies co-located confirmed findings (unhardened blast radius).
5. Everything else (project prompt, assignee Rover check, verbatim extraction, redaction) follows the standard procedure below.

The disposition gate still applies in reverse: never include confirmed vulnerabilities, false positives, or undetermined findings in a hardening issue.

---

Procedure

Step 1 — Locate the Audit Report(s)

Given the input path, resolve the audit report file(s):

• If a .md file is given, use it directly.
• If a folder is given, read the folder's README.md to identify components with Critical/High findings, then locate the corresponding <component>/<component>-security-audit.md files within the folder.
• If all-critical or all-high is specified, scan all *-security-audit.md files in the folder and select those containing findings at the requested severity level.

Disposition gate (harness ≥ 0.27.0). Before filing, check the finding's current disposition — prefer the sibling *-findings-current.json (ledger view), falling back to the sibling *-triage.json verdict:

• validation_status/verdict false_positive or hardening → do not file a defect. Hardening findings are posture backlog, not defects (they are risk-weighted in findings-trends and belong in engineering hygiene work, per docs/disposition-ledger.md §7); false positives are refuted. If a filing is explicitly requested for such a finding anyway, surface the disposition to the user and require confirmation.
• undetermined → do not file; flag for human review instead.
• disposition.resolution resolved/risk_accepted → do not file; note the existing resolution.
• No triage/ledger artifacts present → proceed on audit severity as before, and note in the defect that the finding is not_verified.

Step 2 — Extract Finding Data (Verbatim)

For each requested finding in the report, extract all of the following fields. Preserve the full text — do not summarize or truncate any section.

Field	How to Extract	Required
Finding ID	FIND-NNN (or variant like FIND-101, FIND-201)	Yes
Title	Finding heading text after the ID and dash	Yes
Severity	From severity field (Critical/High/Medium)	Yes
CVSS Score	From CVSS v3.1: field — capture the full score and vector	Yes
CWE	From CWE: or CWE-NNN identifiers (may be multiple)	Yes
Framework References	ASVS section, K01–K10 ID, CIS section, STIG ID — all that are listed	If present
File Paths	All file:line locations from Files: list	Yes
Evidence / Code	The complete code block(s) under Evidence: — preserve formatting, comments, and surrounding explanation	If present
Attack / Exploit Scenario	The complete Attack: paragraph and any attack-chain YAML/code blocks	If present
Mitigation Status	Any existing mitigations noted (Mitigation status: or Mitigations in place:)	If present
Description	The full root-cause explanation — this is the prose between the metadata fields and the attack section. Preserve all technical detail.	Yes
Remediation / Recommendation	The complete Recommendation: text including any code blocks	Yes
Impact	Impact statement if listed separately from description	If present
Repository URL	From the report's Executive Summary metadata table	Yes
Branch/Commit	From the report's Executive Summary metadata table (Requested ref or Audited ref)	Yes
Audit Date	From the report's Executive Summary metadata table	Yes
Products	From the report's Products or Used by field	If present

Critical rule: The description, evidence/code, and remediation sections must be included in full in the Jira ticket. These sections contain the technical detail that the receiving engineer needs to understand and fix the vulnerability. Never summarize them.

Step 3 — Ask the User for Jira Project Information

The user belongs to the product team that owns these findings. Ask them for:

1. Jira project key (e.g. ACM, SRVKP, OCPBUGS)
2. Jira component (if their project uses components)
3. Assignee (optional) — a Jira username, Red Hat Kerberos ID, or GitHub username to assign the defect to

If the user has already provided this information (e.g. in the conversation or as part of the arguments), use it without asking again.

Step 4 — Verify Assignee via Rover (if provided)

If the user provides an assignee, verify that they are a Red Hat employee before assigning the Jira ticket. Use the following resolution chain:

1. If a Kerberos ID or Red Hat email is provided, look up the person on Rover at https://rover.redhat.com/people/profile/<kerberos_id> to confirm they are an active Red Hat employee.
2. If a GitHub username is provided, resolve it to a Red Hat identity:
   • Fetch the Rover profile page at https://rover.redhat.com/people/profile/<github_username> — some users have their Kerberos ID matching their GitHub handle.
   • If that fails, search Rover by name: look up the GitHub user's display name via the GitHub API (GET /users/<username>), then search https://rover.redhat.com/people/?q=<display_name> to find matching Red Hat employees.
   • If a match is found, confirm with the user: "GitHub user <username> appears to map to <name> (<kerberos>@redhat.com). Should I assign the defect to them?"
   • If no match is found, inform the user and ask them for the correct Kerberos ID or Jira username.

Important: Never assign an embargoed security defect to someone who cannot be verified as a Red Hat employee. If Rover verification fails or is ambiguous, ask the user to provide the correct Jira username directly.

Step 5 — Determine Priority

Map the finding severity to Jira priority:

CVSS Score	Severity	Jira Priority
≥ 9.0	Critical	Critical
7.0–8.9	High	Major
4.0–6.9	Medium	Major
< 4.0	Low	Minor

Step 6 — Populate the Defect Template

Load the template from templates/embargoed-security-defect.md (in this skill's directory) and substitute all {{PLACEHOLDER}} values with the extracted data. Every section that has content in the source finding must appear in the populated template — do not omit sections.

Step 7 — Create the Jira Issue

Use the Jira MCP tool jira_create_issue with:

project_key:       <user-provided Jira project>
summary:           "[Security] <FINDING_ID>: <SHORT_TITLE> — <REPO_NAME>"
issue_type:        "Bug"
description:       <populated template body>
additional_fields:  {
                      "security": {"name": "Embargoed Security Issue"},
                      "labels": ["security", "embargoed", "ai-security-audit", "ProjectGlasswing", "ProjectLightwell"],
                      "priority": {"name": "<resolved priority>"}
                    }
components:        <user-provided Jira component, if any>
assignee:          <Rover-verified Jira username, if provided>

Jira API notes:

• The security field accepts {"name": "Embargoed Security Issue"} to set the Security Level.
• The description must use Markdown — ## for headings, | col | col | for tables, triple-backtick fences for code blocks, [text](url) for links, **bold** for bold, > quote for blockquotes.
• Always use real newlines in the description string passed to jira_create_issue. Do NOT pass literal \n escape sequences — the MCP tool does not interpret them.
• The Jira MCP tool auto-converts Markdown to Jira wiki markup during both create_issue and update_issue.

If the create fails due to missing required fields, show the user the exact error and ask them what value to use. Common examples:

• A project may require a Severity custom field, an Affects Version/s field, an Activity Type field, or other project-specific fields.
• The user knows their project's requirements — ask them rather than guessing.
• Retry the create with the additional fields the user provides.

If the Security Level is not available for the project, inform the user — not all Jira projects have the "Embargoed Security Issue" level configured. Ask how they would like to proceed.

Step 8 — Report Results

After filing, output a summary table:

| # | Jira Key | Finding | Component | Severity | CVSS | Title |
|---|----------|---------|-----------|----------|------|-------|
| 1 | PROJ-123 | FIND-001 | compliance-operator | Critical | 9.9 | Arbitrary cluster-object creation via ComplianceRemediation |

If any filings failed, list them with the error reason and the action needed.

The filed Jira keys become disposition sources for the findings ledger: once the ticket is worked, /track-findings <product>/<repo> <JIRA-KEY> folds its status and resolution back into the cumulative findings report.

Engineering Next Steps (included in every defect)

The defect template includes an "Engineering Next Steps" section with a checklist that guides engineering teams through the post-filing workflow. This section is always included in the Jira description and covers:

1. Triage — SMEs review privately, assess exploitability, document the exploit as a comment or attached script, and confirm or supply mitigations. The goal is a validated assessment before disclosure.
2. Fix Development — If serious and exploitable, develop the fix privately per Product Security's embargo procedure. Keep work off public branches.
3. Formal Disclosure — If the finding is a legitimate CVE, add Product Security contacts to the issue first ([e-mail]), then coordinate with them on upstream disclosure. Product Security can assist with the upstream disclosure process.
4. Embargo Determination — Work with Product Security to determine if a formal embargo is necessary. Embargoes requiring incidents are orchestrated through Product Security.

These steps are owned by the engineering managers and team leads who receive the defect. The checklist items use Markdown task list syntax (- [ ]) so progress is trackable directly in the Jira description.

---

Deduplication

Before filing, check for existing defects:

1. Search Jira with: project = <PROJECT> AND summary ~ "<FINDING_ID>" AND summary ~ "<REPO_NAME>" AND labels = "ai-security-audit"
2. If a matching issue exists, skip filing and note the existing key in the results table.

---

Batch Mode

When processing multiple findings (e.g. all-critical):

1. Group findings by component/report.
2. Process each finding sequentially.
3. Pause and confirm with the user before filing if more than 5 defects would be created in a single run.
4. Produce a final summary table of all filed defects.

---

Notes

• Embargo discipline: Never include finding details in commit messages, PR descriptions, or public channels. The Jira Security Level restricts visibility to authorized personnel only.
• One defect per finding: Each FIND-NNN gets its own Jira issue, even if multiple findings exist in the same report. This enables independent tracking, assignment, and remediation timelines.
• Verbatim content: The description, evidence, and remediation from the audit report must be included in full. These are the primary value of the defect — the receiving engineer needs the complete technical detail.
• Cross-component findings: Some findings appear as "inherited" entries (e.g. FIND-101, FIND-201) across components. File the defect once and note all affected components in the description.
• Labels cannot contain spaces — use "ProjectGlasswing" not "Project Glasswing".

---

Description Formatting

• Always use real newlines in the description string passed to jira_create_issue. Do NOT pass literal \n escape sequences — the MCP tool does not interpret them, and they render as broken text in Jira.
• The Jira MCP tool auto-converts Markdown to Jira wiki markup (h2., {{monospace}}, [text|url], {code}, {quote}, etc.) during both create_issue and update_issue.