Security fixes are applied to the latest published HawkOps release and the default branch. Older releases are unsupported unless a maintainer explicitly announces an extended support window.

Do not open a public issue for a vulnerability involving credentials, repository write access, token handling, or dependency-update execution.

Use the repository's private Security advisory reporting flow. Include the affected version, impact, safe reproduction steps, and any proposed mitigation. Do not test against repositories or organizations you do not own or have written authorization to assess.

• Initial acknowledgement: within 2 business days.
• Triage and severity decision: within 5 business days.
• Critical remediation target: 7 calendar days after confirmed triage.
• High remediation target: 30 calendar days after confirmed triage.
• Moderate and low findings: scheduled according to exploitability and maintenance risk.

If a target cannot be met, maintainers will document containment, owner, and the revised date in the private advisory.

Please allow maintainers to validate and release a fix before public disclosure. After remediation, the advisory should record affected versions, fixed versions, CVE information when applicable, credits, and any required key rotation or repository-owner action.

• Never commit a GitHub App private key.
• Store the App ID and client ID as Actions variables.
• Store the PEM private key as an Actions secret.
• Use short-lived installation tokens generated during each workflow run.
• Restrict the GitHub App installation to approved repositories.
• Review every permission change before accepting it.
• Use separate short-lived tokens for target inspection and central reporting.
• Keep Actions restricted to reviewed publishers and immutable commit SHAs.
• Require pull requests, passing checks, and resolved conversations on the default branch where the repository plan supports rulesets.
• Keep HAWK_KILL_SWITCH false during normal operation and require an organization owner to change it.

• HawkOps has no public event receiver or health endpoint.
• The scheduled HawkOps GitHub events workflow reads comments and dependency pull requests directly through the GitHub API.
• Commands are accepted only on trusted HawkOps dashboards, with exact command names, an allowed organization, and write, maintain, or admin access.
• App-authored reactions and check-run identifiers provide idempotency so the same comment or pull request is not processed twice.
• Workflow dispatch and App-authored comments use separate scoped tokens.
• Treat HawkOps PR verdicts as policy evidence, not as a replacement for repository CI or human review.

• Verify exported sensitive decision comments with npm run verify-audit.
• Keep tenant identifiers in authenticated GitHub installation context and reject cross-organization repository targets.
• Treat reachability, semantic-surface, and exploit evidence as untrusted until it comes from a protected branch or reviewed workflow.
• Treat an unavailable Dependabot alert count as unknown, not as zero.
• Never use a Safe verdict to bypass required checks, review, or a protected production environment.

HawkOps keeps approvals, reports, run history, alerts, commands, checks, and pull requests inside GitHub. Report artifacts use GitHub Actions retention and signed manifests; HawkOps does not maintain an external server, database, delivery journal, or dashboard snapshot store.

If a private key may have been exposed, revoke it immediately in the GitHub App settings, generate a new key, replace the Actions secret, and inspect recent workflow and audit logs.

Private repositories on GitHub Free cannot enable every repository ruleset or code-scanning feature. HawkOps reports an unsupported plan as a blocked control; it does not claim that the control is active. Enable GitHub Pro, Team, or Advanced Security as required before treating those checks as enforced.