Add security label to triage and release notes (#3516)

.github/release.yml

@@ -8,12 +8,25 @@ changelog:
       labels:
         - feature
 
-    - title: Enhancements 🔧
+    - title: Breaking Changes ⚠️
+      labels:
+        - breaking change
+      exclude:
+        labels:
+          - contrib
+          - security
+
+    - title: Enhancements ✨
       labels:
         - enhancement
       exclude:
         labels:
           - breaking change
+          - security
+
+    - title: Security 🔒
+      labels:
+        - security
 
     - title: Fixes 🐞
       labels:
@@ -21,13 +34,7 @@ changelog:
       exclude:
         labels:
           - contrib
-
-    - title: Breaking Changes 🛫
-      labels:
-        - breaking change
-      exclude:
-        labels:
-          - contrib
+          - security
 
     - title: Docs 📚
       labels:
@@ -41,6 +48,9 @@ changelog:
     - title: Dependencies 📦
       labels:
         - dependencies
+      exclude:
+        labels:
+          - security
 
     - title: Other Changes 🦾
       labels:

.github/workflows/marvin-label-triage.yml

@@ -108,6 +108,7 @@ jobs:
           - http: HTTP transport or networking is the main issue
           - contrib: Specifically about community contributions in src/contrib/
           - tests: Issues primarily about testing infrastructure, CI/CD workflows, or test coverage
+          - security: Apply ONLY when the issue/PR addresses an exploitable vulnerability or hardens against one. Examples: SSRF, LFI, path traversal, injection, auth bypass allowing unauthorized access, scope escalation, open redirects. Do NOT apply for ordinary auth bugs (wrong scopes returned, token refresh logic, OAuth flow correctness) unless an attacker could exploit the bug to bypass access controls or escalate privileges. The key question: "Could a malicious actor exploit this?" If the answer is just "it breaks for legitimate users," that's a bug, not a security issue.
 
           IMPORTANT LABELING RULES:
           - Be selective - only apply labels that are clearly relevant