get2knowio / get2knowio/hangar
Manual policy remediation: settings & org-level checks not fixable by PR
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- Avg merge
- 22h 46m
- Merged PRs (30d)
- 16
Description
Follow-up to #61, which remediated every Hangar policy check that can be
delivered as content. These remaining checks are **repo settings, org policy, or
a process decision** — Hangar itself classifies them as `link`/`report` tier and
deep-links the operator rather than "applying" them, so they can't ride in a PR.
Current state measured against `get2knowio/hangar` on 2026-07-22.
### Manual settings / org changes
- [ ] **`secret_scanning` — Secret scanning + push protection.** Currently
**disabled**. Enable at *Settings → Advanced Security → Secret scanning* (and
*Push protection*). Free on public repos.
- [ ] **`workflow_permissions` — default `GITHUB_TOKEN` to read-only.** Currently
**`write`**. Set at *Settings → Actions → General → Workflow permissions →
"Read repository contents and packages permissions"*. (#61 already adds
least-privilege `permissions:` blocks to the workflows, but this check reads
the repo-level default.)
- [ ] **`two_fa` — require 2FA for the `get2knowio` org.** Currently **off**.
Enable at *Organization → Settings → Authentication security → Require
two-factor authentication*.
- [ ] **`description` — repo topics.** Description is set, but **topics are
empty** (the check requires both). Add a few topics via the repo sidebar
(e.g. `fleet-management`, `repository-management`, `self-hosted`,
`devops`, `governance`).
- [ ] **Enable Dependency graph** *(prerequisite for the `dependency-review`
workflow added in #61).* The workflow currently fails with "Dependency review
is not supported on this repository." Enable at *Settings → Advanced Security →
Dependency graph*. Hangar's `dep_review` check passes on the workflow's
presence regardless, but the workflow itself only goes green once this is on.
### Decision item
- [ ] **`release_please` — no release-please config in the repo.** You ship
releases (v0.3.11) via another mechanism today. Either adopt release-please
(add `release-please-config.json` + `.release-please-manifest.json` + a
workflow) so the check passes natively, **or** add a `.hangar.json`
suppression documenting the alternative release process. Deferred out of #61
intentionally to avoid changing the release lifecycle without a decision.
### Note
- **`code_scanning`** will flip to passing on its own once the CodeQL workflow
added in #61 completes its first analysis on `main` after merge — no manual
action needed, just noted so it isn't mistaken for drift.
---
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Contributor guide
Research direction
Start with the checklist in issue #62 and inspect the existing .hangar.json and workflow files, then review the named GitHub Settings paths for secret scanning, workflow permissions, 2FA, topics, and dependency graph. For release_please, inspect the current release process and decide whether the proposed config and workflow or a documented suppression is appropriate; done means the selected checks and workflow pass.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, github-actions
- Domain
- ci-cd, devops, release, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 30/100