Add public-repo guardrails: .gitignore, CONTRIBUTING, disable blank issues - #2
Add public-repo guardrails: .gitignore, CONTRIBUTING, disable blank issues#2taylormade7978 wants to merge 2 commits into
Conversation
…ssues The repo is public and will receive reviewer-authored issues and screenshots. Audit of tree + full history found nothing sensitive; these are preventive. - .gitignore: env/secret/key/kubeconfig files plus raw image and data captures, so evidence cannot be committed by accident. - .github/ISSUE_TEMPLATE/config.yml: blank_issues_enabled: false, so every defect goes through the form carrying the confidentiality checkbox. - CONTRIBUTING.md: screenshot redaction guidance (the main UAT leak vector) and what to do after an accidental sensitive post. - README: link CONTRIBUTING; note that filing issues needs a GitHub account. Refs #1
The platform-uat course that generates the scenario issues here was corrected in edgent-lms#266, so this page has to say the same thing rather than a second, slightly different thing. The gap this closes is the security-control paradox. CONTRIBUTING listed "security findings" among the things never to post but gave no instruction for the case reviewers will actually hit: a Fail on tenant scoping, the audit ledger, ReBAC or masking, where the failure report is itself a vulnerability disclosure and, on masking, a data disclosure on top of it. A new section says what to do - report the observable behavior, never the workaround, never the data the control was hiding, and no reproduction steps for an access-control defect, because those are a recipe. Screenshots: the page already led with "prefer words", but the scenario issues used to make an image mandatory. Both now say the same thing - never mandatory, and on the security-control scenarios attach nothing at all. Redaction wording strengthened in place. It already said solid boxes and not blur, which is what the course was corrected TO; it now also offers cropping the region out, matching the scenario issues word for word. One private channel, one name: the page said "your Edgent point of contact" while the course and the issues say "your product lead". Both now name the same person in the same breath, so a reviewer is never left wondering whether these are two different escalation paths.
Reconciled with the corrected course guidance — 469228dThe audit finding in #1 traced the unsafe reporting guidance to the Not merged — this is yours to review and merge. What I changed1. Added the missing case: "When the defect is the security control". This was the real gap. The page listed security findings among the never-post categories, but gave no instruction for the situation reviewers will actually hit — a Fail on tenant scoping, the audit ledger, ReBAC or masking, where the failure report is itself a vulnerability disclosure and, on masking, a data disclosure on top of that. The new section says: report the observable behavior and stop; never write down a way around the control; never write down the data the control was hiding; and no reproduction steps for an access-control defect, because those are a recipe rather than a bug report. 2. Screenshots — removed the conflict. This page already led with "prefer describing what you saw in words", but every scenario issue simultaneously demanded "attach at least one image of the screen you were on". Two instructions, and the mandatory one wins. Both sides now say a screenshot is never mandatory, and that on the security-control scenarios the right answer is to attach nothing at all. 3. Redaction wording — strengthened, not corrected. Your version was already right (solid boxes, never blur or pixelate) — it is what the course was corrected to, and 4. One private channel, one name. The page said "your Edgent point of contact"; the course and the issues say "your product lead". A reviewer could reasonably read those as two different escalation paths, and pick neither. Both now name the same person in the same breath. On duplicationI deliberately did not deduplicate. The layering is right: the per-issue 🔐 note fires at the point of temptation, the issue footer is the standing reminder, and this page is the reference that explains why. What was wrong was that the three disagreed — not that there were three. Issue One thing worth your judgment
|
1 participant
Closes #1
Preventive guardrails for a public repo that will receive reviewer-authored issues and screenshots. The security audit itself came back clean — this PR adds no fixes, only prevention.
What changed
.gitignore.env, keys, certs, kubeconfigs, service-account JSON, and raw image/CSV/PDF captures from being committed by accident..github/ISSUE_TEMPLATE/config.ymlblank_issues_enabled: false. This was a real gap —defect.ymlhas a required confidentiality checkbox, but a reviewer could open a blank issue and skip it entirely. Also adds a contact link routing sensitive reports away from public issues.CONTRIBUTING.mdREADME.mdAlready done outside this PR
Secret scanning, push protection, and non-provider pattern scanning are now enabled on the repo. Backfill over the full history returned zero alerts.
Note on the screenshot rules
.gitignoreignores image files, and CONTRIBUTING tells reviewers to link governed storage rather than paste. This does not affect issue attachments (GitHub hosts those outside the repo) — it only stops captures being committed to the tree. Issue attachments stay governed by the template checkbox and the CONTRIBUTING guidance.Redaction guidance says solid boxes, not blur or pixelation — both are reversible.