You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: skills/pipeline/public-security-policy-pr.md
+22-6Lines changed: 22 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,11 +28,13 @@ Never include credentials, private reports, exploit details, or confidential vul
28
28
29
29
1. Confirm neither `SECURITY.md` nor `.github/SECURITY.md` exists.
30
30
2. Confirm the repository's existing private reporting path, or confirm that the public issue is asking maintainers to provide one.
31
-
3. Add a concise `SECURITY.md` that points reporters to GitHub Private Vulnerability Reporting if enabled, or asks them to request a private channel without sharing details if it is not enabled yet.
32
-
4. Warn reporters not to disclose vulnerabilities in public issues, discussions, or pull requests.
33
-
5. Keep scope to reporting guidance, disclosure etiquette, and update guidance.
34
-
6. Avoid unsupported claims about SLAs, bounties, supported versions, or guaranteed security response.
35
-
7. Open a small PR that references the source issue and states that no sensitive details are included.
31
+
3. Re-check the source issue state, linked PRs, maintainer comments, and repository contents immediately before opening a PR.
32
+
4. Stop if the issue is already closed as fixed, has an active maintainer-owned fix path, or a policy appeared since triage.
33
+
5. Add a concise `SECURITY.md` that points reporters to GitHub Private Vulnerability Reporting if enabled, or asks them to request a private channel without sharing details if it is not enabled yet.
34
+
6. Warn reporters not to disclose vulnerabilities in public issues, discussions, or pull requests.
35
+
7. Keep scope to reporting guidance, disclosure etiquette, and update guidance.
36
+
8. Avoid unsupported claims about SLAs, bounties, supported versions, or guaranteed security response.
37
+
9. Open a small PR that references the source issue and states that no sensitive details are included.
36
38
37
39
## Validation
38
40
@@ -59,14 +61,28 @@ Stop or revise when:
59
61
- the proposed text claims unsupported SLA, bounty, or version support
60
62
- the PR would expose vulnerability details or encourage public disclosure
61
63
- the repository asks security reports to use a different official channel
64
+
- the source issue is already resolved, assigned to a maintainer implementation, or has a linked maintainer fix in progress
62
65
63
66
## Evidence
64
67
65
-
This candidate is based on repeated public-safe documentation PRs:
68
+
This candidate is based on public-safe documentation attempts with mixed outcomes:
- Dify is positive PR validation because the docs change merged.
80
+
- Aider is unresolved evidence until maintainer action, merge, or closure.
81
+
- mem0 validates the trigger, not the PR path: the source issue closed as fixed after maintainers handled the private reporting channel, while the docs PR closed unmerged.
82
+
83
+
## Next Experiment Rules
84
+
85
+
- Prefer repositories where the issue is still open and explicitly asks for `SECURITY.md` or private reporting guidance.
86
+
- Only open a PR when no maintainer fix is visible after checking issue timeline, linked PRs, and repository contents.
87
+
- Treat a closed-unmerged PR with a fixed related issue as "need solved elsewhere," not as merged-proof evidence.
88
+
- Limit the next run to one carefully preflighted PR before promoting this candidate into a formal reusable skill.
0 commit comments