ossf/allstar보안 정책을 설정하고 시행하는 GitHub 앱
[](https://api.scorecard.dev/projects/github.com/ossf/allstar)
<img align="right" src="https://assets.kitploit.com/production/public/readmes/4605/56f8714eef22fa31a6956e341013b069f09b7dd1b45c374eec1e6987c911ed49.png" width="300" height="400">
# **Allstar**
> [!IMPORTANT]
> **OpenSSF에서 호스팅하던 Allstar GitHub App은 서비스가 종료되었습니다.**
> OpenSSF Scorecard의 하위 프로젝트인 Allstar 자체는 계속
> 유지 관리되고 있습니다. 이제는 직접 실행해야 하며,
> [GitHub Action으로 실행](#running-allstar-as-a-github-action)하거나
> [서비스 데몬으로 실행](#running-allstar-as-a-service-daemon)할 수 있습니다.
>
> 자세한 내용은 [ossf/allstar#881](https://github.com/ossf/allstar/issues/881)을
> 참조하세요.
>
> 조직에서 호스팅 앱에 의존하고 있었다면
> [호스팅 앱에서 마이그레이션하기](#migrating-off-the-hosted-app)를 참조하세요.
## 개요
- [Allstar란 무엇인가요?](#what-is-allstar)
## Allstar의 새로운 기능
- [whats-new.md](https://github.com/ossf/allstar/blob/main/whats-new.md)
## 원하지 않는 이슈 비활성화하기
- [도와주세요! Allstar가 생성한 이슈를 받고 있는데 원하지 않습니다!](#disabling-unwanted-issues-1)
## 시작하기
- [배경](#background)
- [조직 수준 옵션](#org-level-options)
- [설치 옵션](#installation-options)
- [GitHub App 생성하기](#create-your-github-app)
- [`.allstar` 제어 저장소 생성하기](#create-your-allstar-control-repository)
- [Allstar를 GitHub Action으로 실행하기](#running-allstar-as-a-github-action)
- [Allstar를 서비스 데몬으로 실행하기](#running-allstar-as-a-service-daemon)
- [호스팅 앱에서 마이그레이션하기](#migrating-off-the-hosted-app)
## 정책 및 액션
- [액션](#actions)
- [정책](#policies)
## 고급
- [구성 정의](#configuration-definitions)
- [구성 예시](#example-config-repository)
- [자체 Allstar 인스턴스 실행하기](https://github.com/ossf/allstar/blob/main/operator.md)
## 기여하기
- [기여하기](#contributing)
________
________
## 개요
### Allstar란 무엇인가요?
Allstar는 GitHub 조직 또는 저장소가 보안 모범 사례를 준수하는지 지속적으로
모니터링하는 GitHub App입니다. Allstar가 보안 정책 위반을 감지하면
저장소 또는 조직 소유자에게 알리기 위해 이슈를 생성합니다. 일부 보안 정책의
경우 Allstar가 위반을 일으킨 프로젝트 설정을 자동으로 변경하여 예상 상태로
되돌릴 수도 있습니다.
Allstar의 목표는 프로젝트 보안에 영향을 미치는 파일과 설정을 세밀하게
제어할 수 있도록 하는 것입니다. 조직 수준과 저장소 수준 모두에서 모니터링할
보안 정책과 정책 위반 처리 방법을 선택할 수 있습니다. 새로운 정책을 개발하거나
기여할 수도 있습니다.
Allstar는 [OpenSSF Scorecard](https://github.com/ossf/scorecard) 프로젝트의 일부로 개발됩니다.
## [Allstar의 새로운 기능](https://github.com/ossf/allstar/blob/main/whats-new.md)
## 원하지 않는 이슈 비활성화하기
Allstar가 생성하는 원하지 않는 이슈를 받고 있다면 [이 안내](https://github.com/ossf/allstar/blob/main/opt-out.md)에 따라 옵트아웃하세요.
## 시작하기
### 배경
Allstar는 구성 가능성이 매우 높습니다. 주요 제어 수준은 세 가지입니다:
- **조직 수준**: 조직 관리자는 다음 경우에 Allstar를 활성화하도록 선택할 수 있습니다:
- 조직의 모든 저장소;
- 일부 옵트아웃된 저장소를 제외한 대부분의 저장소;
- 옵트인된 소수의 저장소만.
이러한 구성은 조직의 `.allstar` 저장소에서 수행됩니다.
- **저장소 수준:** Allstar를 사용하는 조직의 저장소 관리자는
자신의 저장소를 조직 수준 적용에 옵트인 또는 옵트아웃하도록 선택할 수 있습니다.
참고: 이러한 저장소 수준 제어는 조직 수준 설정에서 "repo
override"가 허용된 경우에만 작동합니다. 이러한 구성은
저장소의 `.allstar` 디렉터리에서 수행됩니다.
- **정책 수준:** 관리자 또는 유지 관리자는 특정 저장소에서 어떤 정책이
활성화되는지, 정책 위반 시 Allstar가 어떤 조치를 취하는지 선택할 수 있습니다.
이러한 구성은 조직의 `.allstar` 저장소(관리자) 또는 저장소의
`.allstar` 디렉터리(유지 관리자)에 있는 정책 yaml 파일에서 수행됩니다.
### 조직 수준 옵션
Allstar를 조직 수준에서 설치하기 전에, Allstar를 실행할 저장소의 대략적인 수를 결정해야 합니다. 이는 Opt-In과 Opt-Out 전략 중에서 선택하는 데 도움이 됩니다.
- Opt In 전략을 사용하면 Allstar를 실행할 저장소를 수동으로 추가할 수 있습니다. 저장소를 지정하지 않으면 Allstar는 설치되어 있어도 실행되지 않습니다. 전체 저장소 중 소수에만 정책을 적용하려는 경우, 또는 더 많은 저장소에서 활성화하기 전에 단일 저장소에서 Allstar를 시험해 보려는 경우 Opt In 전략을 선택하세요. v4.3 릴리스부터는 유사한 이름의 여러 저장소를 쉽게 추가할 수 있도록 glob이 지원됩니다.
- Opt Out 전략(권장)은 모든 저장소에서 Allstar를 활성화하고, Allstar 적용에서 제외할 저장소를 수동으로 선택할 수 있게 합니다. 모든 공개 저장소 또는 모든 비공개 저장소를 제외하도록 선택할 수도 있습니다. 조직의 모든 저장소에서 Allstar를 실행하려는 경우, 또는 소수의 저장소만 또는 특정 유형(즉, 공개 vs. 비공개)의 저장소만 제외하려는 경우 이 옵션을 선택하세요. v4.3 릴리스부터는 유사한 이름의 여러 저장소를 쉽게 추가할 수 있도록 glob이 지원됩니다.
<table>
<thead>
<tr>
<th></th>
<th><strong>Opt Out (권장)</strong><br>
<strong>optOutStrategy = true</strong></th>
<th><strong>Opt In</strong><br>
<strong>optOutStrategy = false</strong></th>
</tr>
</thead>
<tbody>
<tr>
<td>기본 동작 </td>
<td>모든 저장소가 활성화됨</td>
<td>어떤 저장소도 활성화되지 않음 </td>
</tr>
<tr>
<td>저장소 수동 추가</td>
<td>저장소를 수동으로 추가하면 해당 저장소에서 Allstar가 비활성화됨</td>
<td>저장소를 수동으로 추가하면 해당 저장소에서 Allstar가 활성화됨</td>
</tr>
<tr>
<td>추가 구성</td>
<td>optOutRepos: 나열된 저장소에서 Allstar가 비활성화됨<br>
<br>
optOutPrivateRepos: true인 경우 모든 비공개 저장소에서 Allstar가 비활성화됨
<br>
<br>
optOutPublicRepos: true인 경우 모든 공개 저장소에서 Allstar가 비활성화됨<br>
<br>
(optInRepos: 이 설정은 무시됨)</td>
<td>optInRepos: 나열된 저장소에서 Allstar가 활성화됨 <br>
<br>
(optOutRepos: 이 설정은 무시됨)</td>
</tr>
<tr>
<td>저장소 재정의 </td>
<td>true인 경우: 저장소는 자체 저장소 파일의 설정을 사용하여 조직의 Allstar 적용에서 제외할 수 있습니다. 해당 저장소에 적용되는 조직 수준의 opt-in 설정은 무시됩니다. <br>
<br>
false인 경우: 저장소는 조직 수준에서 구성된 Allstar 적용에서 제외할 수 없습니다. </td>
<td>true인 경우: 저장소는 조직 수준에서 해당 저장소에 대해 구성되지 않았더라도 조직의 Allstar 적용에 참여할 수 있습니다. 해당 저장소에 적용되는 조직 수준의 opt-out 설정은 무시됩니다.<br>
<br>
false인 경우: 저장소는 조직 수준에서 구성되지 않은 경우 Allstar 적용에 참여할 수 없습니다. </td>
</tr>
</tbody>
</table>
### 설치 옵션
Allstar는 GitHub App으로서 조직에서 작동합니다. 앱을 생성하고, 해당 앱으로 인증하는 프로세스를 실행합니다. 따라서 설정은 모든 배포에 공통된 두 단계 — [앱 생성](#create-your-github-app) 및 [제어 저장소 생성](#create-your-allstar-control-repository) — 와, 그다음 실행 방법 선택으로 이루어집니다:
| | [GitHub Action](#running-allstar-as-a-github-action) | [서비스 데몬](#running-allstar-as-a-service-daemon) |
|---|---|---|
| **실행 방식** | `.allstar` 저장소의 예약된 작업 | 직접 호스팅하는 상시 프로세스 |
| **제공해야 할 것** | GitHub 외에는 없음 | 서버 또는 컨테이너 오케스트레이터 |
| **주기** | `cron`에 설정한 대로 | 연속 실행, 결과는 5-10분 내에 |
| **설정 노력** | 보통 | 높음 |
| **적합한 경우** | 인프라 부담이 가장 낮은 옵션을 원할 때 | 가장 많은 제어를 원하거나 이미 서비스를 운영 중일 때 |
Action은 둘 중 오버헤드가 더 낮으며 대부분의 조직이 시작해야 하는 방법입니다. 정책 구성을 변경하지 않고 나중에 데몬으로 전환할 수 있습니다.
#### GitHub App 생성
앱은 조직 내에서 일련의 권한을 가진 사용자와 유사한 신원입니다.
Allstar는 규정 준수를 감지하기 위해 대부분의 설정과 파일 내용에 대한 읽기
권한이 필요하며, 이슈를 제기하고 `block` 작업을 지원하기 위해 이슈와 검사에
대한 쓰기 권한이 필요합니다.
[운영자 지침 - GitHub 앱
생성](https://github.com/ossf/allstar/blob/main/operator.md#create-a-github-app)을 따르고, 앱 ID와 개인 키를 기록하세요.
두 실행 모드 모두 이들이 필요합니다.
#### `.allstar` 제어 저장소 생성
Allstar는 조직 내 `.allstar`라는 이름의 저장소에서 구성을 읽습니다.
가장 빠르게 생성하는 방법은 샘플에서 시작하는 것입니다:
1. [샘플 저장소를 열고](https://github.com/ossf/dot-allstar-quickstart)
"Use this template" 버튼을 클릭합니다
1. Repository Name 필드에 `.allstar`를 입력합니다
1. "Create repository from template"을 클릭합니다
이렇게 하면 Opt Out 전략을 사용하여 모든 저장소에서 현재의 모든 Allstar
[정책](#policies)이 `issue` 작업과 함께 활성화됩니다. 나중에 언제든지 변경할
수 있습니다.
처음부터 세밀한 제어를 원한다면 — Opt In 또는 Opt Out 전략을 선택하고 개별
정책 파일을 직접 작성하려면 — 대신 [수동 설치
지침](https://github.com/ossf/allstar/blob/main/manual-install.md)을 따르세요.
#### GitHub Action으로 Allstar 실행
이 옵션은 GitHub Actions를 사용하여 Allstar를 예약된 작업으로 실행하므로,
GitHub 자체 외에 운영할 인프라가 없습니다.
[GitHub Actions 설치
지침](https://github.com/ossf/allstar/blob/main/github-action-installation.md)을 따라 `.allstar` 저장소에 반복 실행되는
Action을 설정하고, 이를 강화하고, 결과를 모니터링하세요.
#### 서비스 데몬으로 Allstar 실행
이 옵션은 Allstar를 지속적인 프로세스로 실행하여, 예약된 일정이 아닌 지속적으로
위반 사항을 감지하고 해결합니다.
프로세스 실행, 시크릿 관리, 규모 산정, 사용 가능한 환경 변수에 대해서는
[운영자 지침](https://github.com/ossf/allstar/blob/main/operator.md)을 참조하세요.
### 호스팅 앱에서 마이그레이션
조직에서 OpenSSF 호스팅 앱을 사용했다면, **구성은 그대로 이어집니다**.
`.allstar` 제어 저장소, `allstar.yaml`, 그리고 모든 정책 파일은 변경 없이 계속
작동합니다. 교체하는 것은 이를 읽는 프로세스뿐입니다.
마이그레이션하려면:
1. [자체 GitHub 앱을 생성](#create-your-github-app)하고, 호스팅 앱이 가졌던
것과 동일한 저장소 접근 권한으로 조직에 설치합니다.
1. 기존 `.allstar` 저장소를 그대로 유지합니다.
1. Allstar를 [Action으로](#running-allstar-as-a-github-action) 또는
[데몬으로](#running-allstar-as-a-service-daemon) 실행합니다.
1. Settings -> GitHub Apps 아래에 여전히 표시된다면, 조직에서 `allstar-app`을
제거합니다.
호스팅 앱이 이전에 제기한 이슈는 저장소에 그대로 남습니다. 자체 인스턴스는
동일한 `allstar` 레이블(또는 구성한 `issueLabel`)로 이슈를 식별하므로, 중복
이슈를 제기하는 대신 위반이 해결되면 해당 이슈를 인수하여 닫습니다.
## 정책 및 작업
## **작업**
각 정책은 Allstar가 저장소가 규정을 준수하지 않는 것을 감지했을 때 취할 작업으로
구성할 수 있습니다.
- `log`: 기본 작업이며, 실제로 모든 작업에 대해 발생합니다. 모든 정책 실행
결과와 세부 정보가 기록됩니다. 로그는 현재 앱 운영자에게만 표시되며, 이를
공개할 계획은 논의 중입니다.
- `issue`: 이 작업은 GitHub 이슈를 생성합니다. 정책당 하나의 이슈만 생성되며,
텍스트는 정책 위반의 세부 사항을 설명합니다. 이슈가 이미 열려 있으면 업데이트
없이 24시간마다 댓글로 핑됩니다(현재 사용자 구성 불가). 정책 결과가 변경되면
이슈에 새 댓글이 남고 이슈 본문에 링크됩니다. 위반이 해결되면 Allstar가 5-10분
이내에 이슈를 자동으로 닫습니다.
- `fix`: 이 작업은 정책에 따라 다릅니다. 정책은 정책 위반을 수정하기 위해 GitHub
설정을 변경합니다. 모든 정책이 이를 지원할 수 있는 것은 아닙니다(아래 참조).
제안되었지만 아직 구현되지 않은 작업입니다. 정의는 향후 추가될 예정입니다.
- `block`: Allstar는 [GitHub 상태 검사](https://docs.github.com/en/github/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)를 설정하고 검사가 실패할 경우 저장소의 모든 PR이 병합되지 않도록 차단할 수 있습니다.
- `email`: Allstar는 저장소 관리자에게 이메일을 보냅니다.
- `rpc`: Allstar는 일부 조직별 시스템에 rpc를 보냅니다.
### **액션 구성**
이슈 액션을 구성하는 데 두 가지 설정을 사용할 수 있습니다:
- `issueLabel`은 조직 및 저장소 수준에서 사용할 수 있습니다. 이를 설정하면 Allstar가 자체 이슈를 식별하는 데 사용하는 기본 `allstar` 레이블을 재정의합니다.
- `issueRepo`는 조직 수준에서 사용할 수 있습니다. 이를 설정하면 조직에서 생성되는 모든 이슈가 지정된 저장소에 생성되도록 강제합니다.
## **정책**
Allstar 앱 활성화 구성과 마찬가지로, 모든 정책은 조직의 `.allstar` 저장소 또는 저장소의 `.allstar` 디렉터리에 있는 yaml 파일로 활성화 및 구성됩니다. 앱과 마찬가지로 정책은 기본적으로 옵트인 방식이며, 기본 `log` 액션은 눈에 보이는 결과를 생성하지 않습니다. 모든 정책을 활성화하는 간단한 방법은 각 정책에 대해 다음 내용으로 yaml 파일을 만드는 것입니다:
```yaml
optConfig:
optOutStrategy: true
action: issue
```
각 정책에 대해 `fix` 액션이 어떻게 작동하는지에 대한 세부 사항은 아래에 설명되어 있습니다. 아래에 생략된 경우 `fix` 액션은 적용할 수 없습니다.
### Branch Protection
이 정책의 구성 파일 이름은 `branch_protection.yaml`이며, [구성 정의는
여기](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/branch#OrgConfig)에
있습니다.
branch protection 정책은 GitHub의 [branch protection
설정](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)이
지정된 구성에 따라 올바르게 설정되어 있는지 확인합니다. 이슈 텍스트에는
어떤 설정이 잘못되었는지 설명됩니다. 설정을 수정하는 방법은 [GitHub
문서](https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/about-protected-branches)를
참조하세요.
`fix` 액션은 branch protection 설정을 지정된 정책 구성에 부합하도록 변경합니다.
### Binary Artifacts
이 정책의 구성 파일 이름은 `binary_artifacts.yaml`이며, [구성 정의는
여기](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/binary#OrgConfig)에
있습니다.
이 정책은 [scorecard의
검사](https://github.com/ossf/scorecard/#scorecard-checks)를 통합합니다. 규정을
준수하려면 저장소에서 바이너리 아티팩트를 제거하세요. scorecard 결과가
장황할 수 있으므로, 모든 세부 정보를 확인하려면 [scorecard
자체](https://github.com/ossf/scorecard)를 실행해야 할 수도 있습니다.
### CODEOWNERS
이 정책의 구성 파일 이름은 `codeowners.yaml`이며, [구성 정의는
여기](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/codeowners#OrgConfig)에
있습니다.
이 정책은 저장소에 [`CODEOWNERS` 파일](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)이 있는지 확인합니다.
### Outside Collaborators
이 정책의 구성 파일 이름은 `outside.yaml`이며, [구성 정의는
여기](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/outside#OrgConfig)에
있습니다.
이 정책은 [Outside
Collaborators](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/adding-outside-collaborators-to-repositories-in-your-organization)가
저장소에 대해 관리자(기본값) 또는 push(선택 사항) 권한을 가지고 있는지
확인합니다. 이 권한은 조직 구성원만 가져야 합니다. 그렇지 않으면 신뢰할 수
없는 구성원이 관리자 수준 설정을 변경하고 악성 코드를 커밋할 수 있습니다.
### SECURITY.md
이 정책의 구성 파일 이름은 `security.yaml`이며, [구성 정의는
여기](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/security#OrgConfig)에
있습니다.
이 정책은 저장소에 `SECURITY.md`에 보안 정책 파일이 있고 비어 있지 않은지
확인합니다. 생성된 이슈에는 저장소에 보안 정책을 커밋하는 데 도움이 되는
[GitHub
탭](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository)으로
연결되는 링크가 포함됩니다.
### Secret Scanning
이 정책의 구성 파일 이름은 `secret_scanning.yaml`이며, [구성 정의는
여기](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/secretscanning#OrgConfig)에
있습니다.
이 정책은 secret scanning에 대한 GitHub 저장소 설정을 확인합니다. GitHub가
비활성화되었다고 보고하면, 생성된 이슈는 저장소 보안 설정으로 직접
연결됩니다. API가 secret-scanning 상태를 반환하지 않으면, 정책은 이를
비활성화된 것으로 처리하지 않고 상태를 사용할 수 없는 것으로 기록합니다.
`fix` 액션은 아직 활성화되지 않은 저장소에 대해 GitHub secret scanning을
활성화합니다. Allstar GitHub App에는 GitHub API가 이 설정을 읽거나 변경할 수
있도록 저장소 관리 권한이 필요합니다.
### Dangerous Workflow
이 정책의 구성 파일 이름은 `dangerous_workflow.yaml`이며, [구성 정의는
여기](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/workflow#OrgConfig)에
있습니다.
이 정책은 **모든** 브랜치에 대해 실행됩니다. 근거는 [여기](https://github.com/ossf/allstar/issues/569)를 참조하세요.
이 정책은 GitHub Actions 워크플로 구성 파일
(`.github/workflows`)에서 알려진 위험 동작과 일치하는 패턴이 있는지
검사합니다. 이 검사에 대한 자세한 내용은 [OpenSSF Scorecard
문서](https://github.com/ossf/scorecard/blob/main/docs/checks.md#dangerous-workflow)를
참조하세요.
### 일반 Scorecard 검사
이 정책의 구성 파일 이름은 `scorecard.yaml`이며, [구성 정의는
여기](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/scorecard#OrgConfig)에
있습니다.
이 정책은 `checks` 구성에 나열된 모든 scorecard 검사를 실행합니다. 실행되는
모든 검사는 `threshold` 설정과 같거나 높은 점수를 받아야 합니다. 각 검사에
대한 자세한 내용은 [OpenSSF Scorecard
문서](https://github.com/ossf/scorecard/blob/main/docs/checks.md)를
참조하세요.
#### SARIF 업로드
Scorecard 정책은 선택적으로 결과를
[SARIF](https://sarifweb.azurewebsites.net/)로 각 저장소의
**Security > Code Scanning** 탭에 업로드할 수 있습니다. 이를 통해 조직
관리자는 저장소별 워크플로 설정 없이도 다른 보안 도구(CodeQL,
Dependabot 등)와 함께 Scorecard 결과를 확인할 수 있습니다.
SARIF 업로드를 활성화하려면 `scorecard.yaml`에 `upload` 필드를 추가하세요:
```yaml
optConfig:
optOutStrategy: true
action: issue
checks:
- Binary-Artifacts
- Signed-Releases
threshold: 8
upload:
sarif: true
```
**요구 사항:**
- Allstar GitHub App은 **Code scanning alerts** 저장소 권한이 **Read & write**로 설정되어 있어야 합니다(API 범위: `security_events`). 이는 Allstar가 일반적으로 필요로 하는 권한에 포함되지 않으므로, SARIF 업로드를 활성화하기 전에 앱에 추가해야 합니다.
- SARIF 업로드는 비차단 방식입니다. 업로드가 실패하더라도(예: 권한 누락) 정책 검사는 정상적으로 계속됩니다.
- 변경 감지는 저장소 HEAD 커밋 SHA를 비교하며, 마지막 업로드 이후 저장소에 푸시가 없었다면 스캔과 업로드를 건너뜁니다.
SARIF 업로드는 Allstar를 실행하는 두 가지 방식 모두에서 작동합니다: [서비스 데몬](https://github.com/ossf/allstar/blob/main/operator.md) 또는 [GitHub Action](https://github.com/ossf/allstar/blob/main/github-action-installation.md).
### GitHub Actions
이 정책의 구성 파일 이름은 `actions.yaml`이며, [구성 정의는 여기](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/action#OrgConfig)에 있습니다.
이 정책은 각 저장소의 GitHub Actions 워크플로 구성 파일(`.github/workflows`)(경우에 따라 워크플로 실행도 포함)을 검사하여, 정책의 조직 수준 구성에 정의된 규칙(예: require, deny)과 일치하는지 확인합니다.
### 저장소 관리자
이 정책의 구성 파일 이름은 `admin.yaml`이며, [구성 정의는 여기](https://pkg.go.dev/github.com/ossf/allstar/pkg/policies/admin#OrgConfig)에 있습니다.
이 정책은 기본적으로 모든 저장소에 관리자로 지정된 사용자 또는 그룹이 있어야 함을 검사합니다. 선택적으로 사용자가 (팀이 아닌) 관리자가 될 수 있는지 여부를 구성할 수 있습니다.
### 향후 정책
- dependabot이 활성화되어 있는지 확인합니다.
- 의존성이 고정/동결(pinned/frozen)되어 있는지 확인합니다.
## **예제 구성 저장소**
Allstar 구성이 사용되는 예시로 [이 저장소](https://github.com/GoogleContainerTools/.allstar)를 참고하세요. 조직 관리자라면, 조직에서 Allstar가 어떻게 사용되는지에 대한 정보를 담은 README.md를 작성하는 것을 고려하세요.
## 고급
### 구성 정의
- [조직 수준 활성화 구성](https://pkg.go.dev/github.com/ossf/allstar/pkg/config#OrgOptConfig)
- [저장소 재정의 활성화 구성]( https://pkg.go.dev/github.com/ossf/allstar/pkg/config#RepoOptConfig)
### 보조 조직 수준 구성 위치
기본적으로 위의 `allstar.yaml` 파일과 같은 조직 수준 구성 파일은 `.allstar` 저장소에 있어야 합니다. 이 저장소가 존재하지 않으면 `.github` 저장소의 `allstar` 디렉터리가 보조 위치로 사용됩니다. 명확히 하자면, `allstar.yaml`의 경우:
| 우선순위 | 저장소 | 경로 |
| - | - | - |
| 기본 | `.allstar` | `allstar.yaml` |
| 보조 | `.github` | `allstar/allstar.yaml` |
이는 아래에서 설명하는 개별 정책의 조직 수준 구성 파일에도 동일하게 적용됩니다.
### 조직 저장소 내 저장소 정책 구성
Allstar는 조직의 `.allstar` 저장소에서 저장소 이름과 동일한 이름의 디렉터리 아래에 있는 저장소 수준 정책 구성도 찾습니다. 이 구성은 "저장소 재정의"가 비활성화되어 있더라도 사용됩니다.
예를 들어, Allstar는 특정 저장소 `myapp`의 정책 구성을 다음 순서로 조회합니다:
| 저장소 | 경로 | 조건 |
| - | - | - |
| `myapp` | `.allstar/branch_protection.yaml` | "저장소 재정의"가 허용된 경우. |
| `.allstar` | `myapp/branch_protection.yaml` | 항상. |
| `.allstar` | `branch_protection.yaml` | 항상. |
| `.github` | `allstar/myapp/branch_protection.yaml` | `.allstar` 저장소가 존재하지 않는 경우. |
| `.github` | `allstar/branch_protection.yaml` | `.allstar` 저장소가 존재하지 않는 경우. |
### 조직 수준 기본 및 병합 구성 위치
조직 수준 Allstar 및 정책 구성 파일의 경우, 기본 Allstar 구성을 포함하는 다른 저장소를 지정하기 위해 `baseConfig` 필드를 지정할 수 있습니다. 이는 예시로 설명하는 것이 가장 좋습니다.
여러 GitHub 조직이 있지만 단일 Allstar 구성을 유지하고 싶다고 가정해 봅시다. 주 조직은 "acme"이고, `acme/.allstar` 저장소에는 `allstar.yaml`이 포함되어 있습니다:
```yaml
optConfig:
optOutStrategy: true
issueLabel: allstar-acme
issueFooter: Issue created by Acme security team.
```
또한 "acme-sat"이라는 위성 GitHub 조직이 있습니다. 메인 구성을 재사용하되, 특정 저장소에서 Allstar를 비활성화하여 일부 변경 사항을 적용하려고 합니다. `acme-sat/.allstar` 저장소에는 `allstar.yaml`이 포함되어 있습니다:
```yaml
baseConfig: acme/.allstar
optConfig:
optOutRepos:
- acmesat-one
- acmesat-two
```
이것은 `acme/.allstar`의 모든 구성을 기본 구성으로 사용하지만, 그런 다음 현재 파일의 변경 사항을 기본 구성 위에 적용합니다. 이것이 적용되는 방식은 [JSON Merge Patch](https://datatracker.ietf.org/doc/html/rfc7396)로 설명됩니다. `baseConfig`는 GitHub `<org>/<repository>`여야 합니다.
## **기여하기**
[CONTRIBUTING.md](https://github.com/ossf/allstar/blob/main/CONTRIBUTING.md)를 참조하세요.