Adding a boilerplate security policy.

.github/workflows/close-inactive-issues.yml

@@ -0,0 +1,37 @@
+name: Close inactive issues
+
+on:
+  schedule:
+    # Cron is UTC
+    - cron: "15 6 * * *"
+  workflow_dispatch: {}
+
+permissions:
+  issues: write
+
+jobs:
+  stale:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Mark stale and close
+        uses: actions/stale@v10
+        with:
+          repo-token: ${{ github.token }}
+
+          # "No activity for 28 days" -> mark stale at 21 days,
+          # then close 7 days after being marked stale
+          days-before-issue-stale: 21
+          days-before-issue-close: 7
+          days-before-pr-stale: -1
+          days-before-pr-close: -1
+
+          stale-issue-label: stale
+          close-issue-message: >
+            Closing due to 28 days of inactivity. If this is still relevant,
+            please comment to reopen.
+          stale-issue-message: >
+            No activity for 28 days. Closing automatically unless updated.
+
+          # Prevent closing important issues
+          exempt-issue-labels: "keep-open,pinned,security"
+          exempt-all-milestones: true

SECURITY.md

@@ -0,0 +1,35 @@
+# Security Guidance
+
+## Sensitive Material Handling
+
+- Do not commit secrets, passwords, API keys, tokens, certificates, private
+  keys, connection strings, or authentication artifacts.
+- Do not commit production customer data, employee personal data, regulated
+  data, or incident details that are not explicitly approved for repository
+  storage.
+- Use redaction and sanitization before adding evidence samples. Remove or mask
+  account names, email addresses, hostnames, IP addresses, tenant identifiers, ticket links, and any data that is not required to demonstrate the point.
+- Prefer representative templates or scrubbed examples over live artifacts.
+
+## Evidence And Audit Integrity
+
+- Never fabricate evidence, screenshots, approvals, test records, or audit
+  outcomes.
+- Never alter evidence in a way that changes its substantive meaning.
+- If a sample is redacted, note that it is sanitized or representative.
+- Preserve references to owners, approvers, dates, and source systems when they
+  are needed for audit traceability.
+
+## Reporting Security Issues
+
+If you identify a security weakness in repository content, proposed changes, or
+automation:
+
+- Do not publish sensitive exploit details in a public issue unless the repo
+  owner explicitly requests that workflow.
+- Notify the designated repository owner, security contact, or maintainers
+  through the approved internal reporting path.
+- Include enough detail to reproduce and assess the issue without attaching
+  secrets or sensitive data.
+- If the issue affects documented controls or evidence expectations, update the
+  relevant documentation only after maintainers confirm the correct handling.