# Optional repository security hardening

These practices are recommended for public Omarchy plugin repositories, but they are not marketplace eligibility requirements and must not block submission when the owner declines them.

Refresh GitHub's current documentation before changing repository settings:

- Security policy: https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository
- Private vulnerability reporting: https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository

## Security policy

Prefer `.github/SECURITY.md` so GitHub recognizes the repository policy. Adapt this template to the actual project and reporting channel:

```markdown
# Security Policy

## Supported versions

Security fixes are made against the latest release and the `main` branch.

## Reporting a vulnerability

Please report suspected vulnerabilities through [GitHub's private vulnerability reporting](https://github.com/OWNER/REPOSITORY/security/advisories/new). Do not open a public issue for an undisclosed security problem.

Include the affected version, impact, reproduction steps, and any suggested mitigation. Please avoid including sensitive personal data that is not needed to investigate the report.
```

Before adding it:

1. Replace `OWNER/REPOSITORY` with the exact public repository.
2. Confirm the supported-version statement matches the project's maintenance policy.
3. Do not promise response times or remediation guarantees the maintainer has not approved.
4. Return to `omarchy-plugin-development` to add or edit the policy, rerun release-readiness checks, and produce a new exact candidate. The publisher must not mutate the reviewed source snapshot.

## Private vulnerability reporting

GitHub permits owners and administrators of public repositories to enable private vulnerability reporting. Finish repository preparation while private, then make the repository public only with explicit owner approval.

After it is public, check the current state:

```bash
gh api repos/OWNER/REPOSITORY/private-vulnerability-reporting
```

A successful response includes an `enabled` boolean. A `404` while the repository is private does not prove the feature is unavailable after publication.

Immediately before changing the setting, obtain explicit owner approval. Enable it with:

```bash
gh api \
  --method PUT \
  repos/OWNER/REPOSITORY/private-vulnerability-reporting
```

Verify afterward:

```bash
gh api repos/OWNER/REPOSITORY/private-vulnerability-reporting
```

Expect `{"enabled":true}`. Also verify that the repository's **Security** area offers **Report a vulnerability** and that the policy link resolves to `/security/advisories/new`.

Repository administrators should watch the repository for **Security alerts** or otherwise configure notifications so private reports are not missed.

## Approval and reporting

Treat this as a separate repository-hardening decision, not part of marketplace approval:

- Ask before enabling or disabling the setting.
- Never include vulnerability details or credentials in public issues, screenshots, or logs.
- If the owner declines, continue marketplace preparation and report the feature as optional and not enabled.