Allstar GitHub App: self-hosted security policy enforcement

Allstar's GitHub policy enforcement scope

Allstar addresses a specific gap between having security guidance in a repository and continuously checking whether GitHub's actual configuration follows that guidance. It is intended for GitHub organization administrators, repository maintainers, and security teams that want policy checks to run without relying on the retired OpenSSF-hosted service.

The project continuously monitors selected GitHub organizations or repositories. When it detects a security policy violation, Allstar creates an issue for the repository or organization owner. For some policies, it can also modify the GitHub setting that caused the violation and return it to the expected state. This makes Allstar closer to a policy controller than a documentation scanner. A violation can produce an alert, an automatic correction, or another action defined by the selected policy configuration, although the README excerpt does not enumerate every action or correction.

Allstar was developed as part of the OpenSSF Scorecard project. Its intended scope is the set of files and GitHub settings covered by its policies, not general source-code vulnerability analysis. The documentation presents policy choice as configurable at both organization and repository levels. Administrators can decide which repositories participate, while repository maintainers may receive limited control over their own enforcement when the organization permits repository overrides.

The operational assumption is important. Allstar needs access to GitHub through a GitHub App that the operator creates, and its process must now be run by the adopting organization. It is therefore aimed at organizations prepared to own authentication, configuration, execution, and ongoing policy management.

Organization, repository, and policy configuration in Allstar

Allstar uses three control levels. Organization administrators configure scope in the organization's `.allstar` repository. Repository maintainers use a `.allstar` directory in an individual repository. Policy decisions then determine which checks are enabled and what happens after a violation.

The first organization-level decision is whether Allstar follows an opt-in or opt-out model. With `optOutStrategy = false`, no repository is enabled by default, and repositories must be added through `optInRepos`. This suits a limited rollout, including trying Allstar on one repository before broader use. The README states that globs are supported since v4.3, allowing related repository names to be selected together.

With `optOutStrategy = true`, all repositories are enabled by default. Administrators can use `optOutRepos` to exclude selected repositories, `optOutPrivateRepos` to exclude private repositories, or `optOutPublicRepos` to exclude public repositories. The corresponding opt-in list is ignored. This model fits an organization that wants organization-wide enforcement with a small number of exceptions. The README labels this strategy as recommended, but the correct choice still depends on whether default coverage or explicit approval is safer for the organization.

Repository-level controls operate only when `Repo Override` is allowed. In opt-out mode, an allowed repository can opt out of organization enforcement. In opt-in mode, it can opt in even when the organization configuration does not include it. When overrides are disabled, repository maintainers cannot change the organization decision. Admins and maintainers also control policies through YAML files, but the README does not show their full schema. Reviewers should consult `README.md` and the configuration definitions before assuming a policy supports a particular response.

Allstar installation and first deployment choices

The hosted OpenSSF Allstar GitHub App has been retired. The README does not provide a usable hosted installation path. It directs adopters to create their own GitHub App, create an `.allstar` control repository, and then run Allstar either as a GitHub Action or as a service daemon.

That direction is necessary but not a complete command-level tutorial. The README does not show an exact action reference, daemon build command, required environment variable, permission list, or first-run verification command.

A first real deployment starts by deciding how broadly Allstar should run. An organization wanting a small trial can use opt-in mode and select one repository. An organization expecting broad coverage can use opt-out mode and carefully define exceptions. The operator must then create a GitHub App with suitable access, place organization policy configuration in the `.allstar` repository, and choose one execution model. A GitHub Action fits deployment tied to GitHub workflow execution, while a service daemon fits a separately managed process.

After deployment, the first observable behavior documented by the project is issue creation when a policy violation is detected. Automatic setting changes apply only to supported policies. The README does not document a dry-run mode, rollback command, or a single readiness endpoint, so those properties should be checked in `operator.md`, `manual-install.md`, or the relevant repository files before production use.

Allstar issue creation and automatic setting changes

Allstar's enforcement model begins with a detected policy violation. The project then creates an issue to alert the relevant owner. This gives administrators a visible record even when the selected response does not change the underlying GitHub setting.

For supported policies, Allstar can update the setting that caused the problem. The README describes this as reverting the project setting to its expected state. This avoids relying on a maintainer to notice an issue and manually repair repository configuration. However, automatic correction also makes scope and permissions central adoption concerns. The organization must grant only the access required for selected policies, and maintainers need a clear understanding of whether repository overrides can weaken organization enforcement.

The control hierarchy determines who can change behavior. Organization administrators define participation and policy settings in the `.allstar` repository. A repository maintainer's `.allstar` directory affects enforcement only if `Repo Override` is permitted. With overrides disabled, a repository cannot opt out of organization enforcement in opt-out mode or opt in when omitted in opt-in mode.

This hierarchy gives administrators a way to establish baseline controls while retaining delegated repository configuration where appropriate. It also creates a governance decision that cannot be deferred to implementation. If repository overrides are too permissive, individual repositories can diverge from organizational policy. If overrides are too restrictive, routine exceptions become organization configuration changes. The documentation provides the switch, but it does not supply a recommended review workflow for exceptions.

Allstar self-hosting limits and policy failure cases

Allstar is the wrong tool when an organization wants a ready-to-use hosted GitHub App. The OpenSSF-hosted service has been retired, and the README explicitly says adopters must run the project themselves. Self-hosting means accepting responsibility for the GitHub App, its runtime, policy configuration, repository selection, and future upgrades.

It is also a poor fit for repositories that do not want issues or automatic GitHub configuration changes, unless the selected policy response is disabled. The project's documented mechanism is to alert through an issue and, where supported, change the setting that caused a violation. The README does not describe quiet reporting, external ticketing, or a universal simulation mode.

Configuration mistakes can produce unintended coverage. In opt-in mode, Allstar does not run when no repositories are specified. In opt-out mode, all repositories are enabled by default, which can expose legacy or intentionally exempt projects to enforcement unless they are listed or covered by the public and private exclusion settings. Globs add convenience for related names, but they also make it important to inspect the resulting selection before treating coverage as correct.

Policy support is another boundary. The README explains that Allstar can act on policy violations and can change some settings, but it does not claim universal remediation. An unsupported setting may therefore produce an issue without being corrected. The README also does not document rollback behavior for an automatic change. Operators who need reversible remediation should verify that property in the relevant policy documentation before deployment.

Allstar maintenance, dependencies, and licensing

The repository is not archived, and the last push was on 2026-10-12. Recent releases include v4.6 on 2026-08-31, v4.5 on 2025-10-01, and v4.4 on 2025-05-20. Those facts support recent project activity, but they do not remove the cost of operating the service independently.

The Go module declares Go 1.25.9 and depends on libraries for GitHub API access, YAML handling, semantic versions, Git operations, logging, caching, expression evaluation, and cloud-backed integrations. The visible `go.mod` includes direct dependencies such as `github.com/google/go-github/v84`, `github.com/bradleyfalzon/ghinstallation/v2`, `github.com/ossf/scorecard/v5`, and `sigs.k8s.io/yaml`. An operator will therefore need to account for the Go toolchain, transitive dependency updates, GitHub API integration, and the security of the chosen deployment environment.

Choosing between a GitHub Action and a service daemon changes the upgrade path. An Action can follow repository workflow deployment, while a daemon requires an independently operated process. The README does not provide exact upgrade or rollback commands, so it does not support claims about zero-downtime upgrades or automatic rollback.

The repository is licensed under Apache-2.0. That identifier permits use and modification under the license's conditions, including preservation of its notices and patent provisions. This is a licensing summary, not legal advice. Organizations should review the actual `LICENSE` file and their compliance obligations before redistribution or modification.

Allstar and manual Scorecard review

The clearest documented comparison is between Allstar's enforcement and a manual review process based on Scorecard. Allstar is developed as part of the OpenSSF Scorecard project and directly imports `github.com/ossf/scorecard/v5` in the visible Go module. That connection supports related security signals, but the README describes Allstar's output as policy monitoring, issue creation, and setting changes.

Allstar adds an execution and control layer around selected policies: it runs against an organization, tracks repository participation, opens issues, and may modify settings.

This difference makes Allstar more suitable for repeated enforcement and organization-wide governance. Manual review remains relevant where policies are irregular, exceptions require human judgment, or automatic repository changes would be inappropriate. The drawback is that self-hosted enforcement introduces a process that must be authenticated, configured, monitored, and upgraded. Allstar does not eliminate those operational tasks; it assigns them to the adopting organization.

Editorial conclusion

Organizations that want centralized GitHub security policy checks should evaluate Allstar, while small projects needing a hosted service should choose another approach. Verify first that your GitHub permissions, opt-in or opt-out strategy, repository override rules, and self-hosting path match the intended enforcement model.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. ossf/allstar on GitHub
4. README
5. Releases