feat(triage-security): add deployment context classification

docs/constraints.md

@@ -86,6 +86,8 @@ existing instruction in a SKILL.md or CLAUDE.md file.
 | 1.74 | `plan-feature` MUST inherit priority and fixVersions from the parent Feature issue when set. | `plan-feature/SKILL.md` — Step 1, Step 6 |
 | 1.75 | `plan-feature` MUST respect `fixVersion scope` from Jira Field Defaults configuration — only propagating fixVersions to tasks when the scope includes "task" or "both". | `plan-feature/SKILL.md` — Step 6 |
 | 1.76 | `plan-feature` MUST NOT set priority on created tasks when the parent Feature has priority "Undefined" or unset. | `plan-feature/SKILL.md` — Step 1, Step 6 |
+| 1.77 | `triage-security` MUST extract the Deployment Context column from the Source Repositories table in Security Configuration and use it to annotate remediation task descriptions with context-appropriate coordination guidance (internal, upstream, or customer-shipped). | `triage-security/SKILL.md` — Step 0, `triage-security/remediation-templates.md` — Coordination Guidance |
+| 1.78 | `triage-security` MUST default all repositories to `upstream` deployment context when the Deployment Context column is absent from the Source Repositories table (backward compatibility). | `triage-security/SKILL.md` — Step 0 |
 
 ### Prior Art — Cross-phase integrity (§1.33–1.35)
 
@@ -179,7 +181,7 @@ Each constraint above references its source. The full source files are:
 - `plugins/sdlc-workflow/skills/define-feature/SKILL.md` — Guardrails (§1.7–1.8), Important Rules (§1.9), Step 3.5 Select Priority and Fix Version (§1.72), Step 6.2 Create Feature Issue (§1.73)
 - `plugins/sdlc-workflow/skills/report-bug/SKILL.md` — Guardrails (§1.50–1.51), Step 4 Preview and Confirm (§1.52)
 - `plugins/sdlc-workflow/skills/triage-bug/SKILL.md` — Guardrails (§1.53–1.54), Step 5 Front-load reproducer test (§1.55), Step 4 Post root cause comment (§1.56), Step 6 Decomposition Guard (§1.57)
-- `plugins/sdlc-workflow/skills/triage-security/SKILL.md` — Guardrails (§1.37, §1.38, §1.47), Step 0 (§1.49, §1.68), Step 1 Ecosystem detection (§1.48), Step 1 Data Extraction (§1.49), Step 1.5 External CVE Data Enrichment (§1.62), Step 1.7 Embargo Check (§1.70, §1.71), Discovery mode (§1.69), Step 2.1 (§1.47), Step 2.2 (§1.42), Step 2.3 (§1.48), Step 2.4 (§1.44), Step 8 (§1.43), Step 8 Case B (§1.61), Post-Triage Summary (§1.67), Important Rules (§1.38–§1.43, §1.45, §1.46), Remediation Task Creation (§1.46, §1.66)
+- `plugins/sdlc-workflow/skills/triage-security/SKILL.md` — Guardrails (§1.37, §1.38, §1.47), Step 0 (§1.49, §1.68), Step 0 Deployment Context (§1.77, §1.78), Step 1 Ecosystem detection (§1.48), Step 1 Data Extraction (§1.49), Step 1.5 External CVE Data Enrichment (§1.62), Step 1.7 Embargo Check (§1.70, §1.71), Discovery mode (§1.69), Step 2.1 (§1.47), Step 2.2 (§1.42), Step 2.3 (§1.48), Step 2.4 (§1.44), Step 8 (§1.43), Step 8 Case B (§1.61), Post-Triage Summary (§1.67), Important Rules (§1.38–§1.43, §1.45, §1.46), Remediation Task Creation (§1.46, §1.66)
 - `plugins/sdlc-workflow/skills/triage-security/version-impact-analysis.md` — Step 2.3 enriched fix threshold (§1.62)
 - `plugins/sdlc-workflow/skills/triage-security/remediation-templates.md` — Jira Issue Creation digest comment (§1.66)
 - `plugins/sdlc-workflow/skills/triage-security/jira-triage-operations.md` — Step 3 ProdSec @mention (§1.68), Step 4.2 Idempotent sibling linking (§1.58), Step 4.3 Cross-CVE overlap detection (§1.59), Step 4.3 ProdSec @mention (§1.68), Step 4.4 Proactive reconciliation (§1.61)

evals/triage-security/evals.json

@@ -279,6 +279,30 @@
         "The analysis proceeds directly to Case A/B/C branching without a concurrent triage warning",
         "The output does not present wait/skip/proceed options since no conflict exists"
       ]
+    },
+    {
+      "id": 23,
+      "prompt": "Triage Vulnerability issue TC-8001. The issue details are in vuln-issue-standard.md, the security matrix is in security-matrix-mock.md, and the project CLAUDE.md is in claude-md-security-config-deploy-ctx.md. Note that the CLAUDE.md Source Repositories table includes a Deployment Context column with the value 'customer-shipped' for rhtpa-backend. Do NOT actually call Jira MCP, git show, or any external tools. Instead, write your triage analysis to the workspace outputs/ directory: write outputs/data-extraction.md with the parsed CVE data table from Step 1 including the deployment context lookup result, and write outputs/remediation.md with the remediation task descriptions including the coordination guidance section.",
+      "expected_output": "A triage analysis where Step 0 extracts the Deployment Context column from the Source Repositories table, Step 1 looks up the deployment context for the affected repository (rhtpa-backend → customer-shipped), and Step 8 remediation task descriptions include a Coordination Guidance subsection with customer-shipped guidance text.",
+      "files": ["files/vuln-issue-standard.md", "files/security-matrix-mock.md", "files/claude-md-security-config-deploy-ctx.md"],
+      "assertions": [
+        "Step 0 extracts the Deployment Context column from the Source Repositories table and parses rhtpa-backend as customer-shipped (§1.77)",
+        "Step 1 looks up the deployment context for the affected repository and records customer-shipped as part of the CVE metadata",
+        "Remediation task descriptions include a Coordination Guidance subsection in Implementation Notes with customer-shipped guidance text",
+        "The customer-shipped guidance mentions coordinating with Product Security for CVE assignment, advisory preparation, and formal disclosure"
+      ]
+    },
+    {
+      "id": 24,
+      "prompt": "Triage Vulnerability issue TC-8001. The issue details are in vuln-issue-standard.md, the security matrix is in security-matrix-mock.md, and the project CLAUDE.md is in claude-md-security-config.md. Note that the CLAUDE.md Source Repositories table does NOT have a Deployment Context column. Do NOT actually call Jira MCP, git show, or any external tools. Instead, write your triage analysis to the workspace outputs/ directory: write outputs/data-extraction.md with the parsed CVE data table from Step 1, and write outputs/remediation.md with the remediation task descriptions.",
+      "expected_output": "A triage analysis where Step 0 detects the absence of the Deployment Context column in the Source Repositories table, defaults all repositories to upstream, and Step 8 remediation task descriptions do NOT include a Coordination Guidance subsection (backward compatibility).",
+      "files": ["files/vuln-issue-standard.md", "files/security-matrix-mock.md", "files/claude-md-security-config.md"],
+      "assertions": [
+        "Step 0 detects the absence of the Deployment Context column in the Source Repositories table and defaults all repositories to upstream (§1.78)",
+        "Remediation task descriptions do NOT include a Coordination Guidance subsection — the section is omitted entirely when no Deployment Context column exists",
+        "The triage proceeds normally through all steps without errors from the missing Deployment Context column",
+        "Backward compatibility is maintained — existing eval behavior is unaffected by the absence of the Deployment Context column"
+      ]
     }
   ]
 }

evals/triage-security/files/claude-md-security-config-deploy-ctx.md

@@ -0,0 +1,64 @@
+<!-- SYNTHETIC TEST DATA — mock CLAUDE.md with Security Configuration including Deployment Context for triage-security eval testing -->
+
+# rhtpa
+
+## Documentation
+
+- [docs/architecture.md](docs/architecture.md) — System architecture overview
+
+# Project Configuration
+
+## Repository Registry
+
+| Repository | Role | Serena Instance | Path |
+|---|---|---|---|
+| rhtpa-backend | Rust backend service | serena_backend | /home/dev/repos/rhtpa-backend |
+
+## Jira Configuration
+
+- Project key: TC
+- Cloud ID: 2b9e35e3-6bd3-4cec-b838-f4249ee02432
+- Feature issue type ID: 10142
+- Git Pull Request custom field: customfield_10875
+- GitHub Issue custom field: customfield_10747
+
+## Code Intelligence
+
+Serena MCP servers provide code intelligence for repository analysis.
+
+### Tool naming convention
+
+Tools are called as `mcp__<serena-instance>__<tool>`.
+
+### Configured instances
+
+| Serena Instance | Repository | Language Server |
+|---|---|---|
+| serena_backend | rhtpa-backend | rust-analyzer |
+
+### Limitations
+
+- rust-analyzer may take 30-60 seconds to index on first use
+
+## Security Configuration
+
+### Product Lifecycle
+
+- Product pages URL: https://access.example.com/product-life-cycle/rhtpa
+- Jira version prefix: RHTPA
+- Vulnerability issue type ID: 10024
+- Component label pattern: pscomponent:
+- VEX Justification custom field: customfield_12345
+
+### Version Streams
+
+| Stream | Konflux Release Repo | Local Path |
+|--------|----------------------|------------|
+| 2.1.x | git.example.com/rhtpa/rhtpa-release.0.3.z | /home/dev/repos/rhtpa-release.0.3.z |
+| 2.2.x | git.example.com/rhtpa/rhtpa-release.0.4.z | /home/dev/repos/rhtpa-release.0.4.z |
+
+### Source Repositories
+
+| Repository | URL | Local Path | Deployment Context |
+|------------|-----|------------|--------------------|
+| rhtpa-backend | https://github.com/rhtpa/rhtpa-backend | /home/dev/repos/rhtpa-backend | customer-shipped |

plugins/sdlc-workflow/skills/setup/SKILL.md

@@ -543,6 +543,9 @@ for CVE analysis. For each repository, collect:
 
 1. **Repository name** — short name (e.g., `backend`, `frontend-ui`)
 2. **URL** — the repository URL
+3. **Deployment context** — one of `internal`, `upstream`, or `customer-shipped`. Default to `upstream` if the user skips.
+
+> "Deployment context for this repository (internal / upstream / customer-shipped)?"
 
 ### Step 10.4 – Scaffold Security Configuration
 

plugins/sdlc-workflow/skills/setup/security-config.template.md

@@ -97,8 +97,13 @@
 
      Example:
        | backend | https://github.com/my-org/backend |
-       | frontend-ui | https://github.com/my-org/frontend-ui | -->
+       | frontend-ui | https://github.com/my-org/frontend-ui |
 
-| Repository | URL |
-|---|---|
-| {{source-repo-name}} | {{source-repo-url}} |
+     Deployment Context (optional, defaults to upstream):
+     - internal: Private repos, internal tools/services. No public disclosure needed.
+     - upstream: Public upstream components. Coordinate with upstream maintainers.
+     - customer-shipped: Products shipped to customers. Full Product Security coordination required. -->
+
+| Repository | URL | Deployment Context |
+|---|---|---|
+| {{source-repo-name}} | {{source-repo-url}} | {{deployment-context}} |

plugins/sdlc-workflow/skills/triage-security/SKILL.md

@@ -139,7 +139,10 @@ Extract the following from the configuration for use in later steps:
   used in Step 1.7 to present an embargo warning gate for Critical/Important severity CVEs.
   If not configured, Step 1.7 is skipped entirely.
 - **Version Streams** — Konflux release repo URLs and local paths from Security Configuration
-- **Source Repositories** — source repo names and URLs from Security Configuration
+- **Source Repositories** — source repo names, URLs, and deployment contexts from Security
+  Configuration. Parse each row into a mapping: repository name → { url, deployment_context }.
+  If the Deployment Context column is absent (backward compatibility), default all repos to
+  `upstream`.
 
 ## Step 0.3 – Matrix Staleness Check
 
@@ -385,6 +388,16 @@ flowchart TD
     G --> I
 ```
 
+### Deployment context lookup
+
+After identifying the affected repository from the component label pattern, look up its
+deployment context from the Source Repositories mapping extracted in Step 0. Record the
+deployment context as part of the extracted CVE metadata for use in Step 8 (Remediation)
+when generating coordination guidance in remediation task descriptions.
+
+If the affected repository is not found in the Source Repositories table, default to
+`upstream`.
+
 ## Step 1.5 – External CVE Data Enrichment
 
 After extracting data from the Jira description, query external CVE databases for

plugins/sdlc-workflow/skills/triage-security/remediation-templates.md

@@ -187,6 +187,24 @@ Remediate CVE-YYYY-XXXXX: update [package-name] to [fixed-version].
 These depend on repository structure that the triage skill does not have context for —
 `implement-task` discovers them via code analysis.
 
+## Coordination Guidance
+
+When the affected repository has a deployment context configured in Security Configuration
+(see Step 0), append a `### Coordination Guidance` subsection to the Implementation Notes
+of each remediation task description. The content varies by deployment context:
+
+- **internal**: "This component is deployed internally. Develop and merge the fix within
+  the repository. No public advisory or upstream coordination required."
+- **upstream**: "This component is public upstream. Coordinate fix with upstream maintainers
+  if the vulnerability is not yet public. Follow your organization's embargo policy before
+  discussing in public channels or PRs."
+- **customer-shipped**: "This component is shipped to customers. Coordinate with Product
+  Security for CVE assignment, advisory preparation, and formal disclosure. Fix must be
+  released via a security advisory with explicit CVE-to-component mapping."
+
+When the Deployment Context column is absent from the Source Repositories table (backward
+compatibility), omit the coordination guidance entirely — do not add the subsection.
+
 ## Jira Issue Creation
 
 After creating each remediation task, post a description digest comment per