Basic Github Information

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

Basic Structure

큰 회사의 기본 github 환경 구조는 **엔터프라이즈(enterprise)**가 여러 **조직(organizations)**을 소유하고, 각 조직은 여러 **저장소(repositories)**와 여러 **팀(teams)**을 가질 수 있는 형태입니다. 작은 회사는 하나의 조직만 소유하고 엔터프라이즈가 없을 수도 있습니다.

사용자 관점에서 **사용자(user)**는 **다른 엔터프라이즈와 조직의 멤버(member)**일 수 있습니다. 그 안에서 사용자는 **엔터프라이즈, 조직, 저장소에 대한 서로 다른 역할(roles)**을 가질 수 있습니다.

또한 사용자는 서로 다른 엔터프라이즈, 조직 또는 저장소 역할을 가진 여러 팀의 일원일 수 있습니다.

마지막으로 저장소에는 특별한 보호 메커니즘이 있을 수 있습니다.

Privileges

Enterprise Roles

  • Enterprise owner: 이 역할을 가진 사람은 관리자 관리, 엔터프라이즈 내 조직 관리, 엔터프라이즈 설정 관리, 조직 전반의 정책 강제 등을 할 수 있습니다. 다만 조직 소유자이거나 조직이 소유한 저장소에 직접 접근 권한을 부여받지 않았다면 조직 설정이나 콘텐츠에는 접근할 수 없습니다.
  • Enterprise members: 엔터프라이즈가 소유한 조직의 구성원은 자동으로 엔터프라이즈의 멤버가 됩니다.

Organization Roles

조직 내에서 사용자는 여러 역할을 가질 수 있습니다:

  • Organization owners: 조직 소유자는 조직에 대한 완전한 관리 접근권한을 가집니다. 이 역할은 제한되어야 하며, 조직 내에서는 최소 두 명 이상이 맡아야 합니다.
  • Organization members: 조직 내 사람들의 기본(non-administrative) 역할은 조직 멤버입니다. 기본적으로 조직 멤버는 여러 권한을 가집니다.
  • Billing managers: 청구 관리자는 조직의 결제 정보 같은 청구 설정을 관리할 수 있는 사용자입니다.
  • Security Managers: 조직 소유자가 조직의 어떤 팀에 할당할 수 있는 역할입니다. 적용되면 해당 팀의 모든 구성원에게 조직 전반의 보안 경고 및 설정을 관리할 수 있는 권한과 조직 내 모든 저장소에 대한 읽기 권한을 부여합니다.
  • 조직에 security team이 있으면, security manager 역할을 사용해 팀 구성원에게 조직에 필요한 최소한의 접근만 부여할 수 있습니다.
  • Github App managers: 조직이 소유한 GitHub Apps를 관리할 추가 사용자를 허용하려면, 소유자가 그들에게 GitHub App manager 권한을 부여할 수 있습니다.
  • Outside collaborators: 외부 협력자는 조직의 한 개 이상의 저장소에 접근 권한은 있으나 조직의 명시적 멤버는 아닌 사람입니다.

이 역할들의 권한을 이 표에서 비교할 수 있습니다: https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles

Members Privileges

in https://github.com/organizations/<org_name>/settings/member_privileges 에서 조직의 구성원으로서 사용자들이 가질 권한을 확인할 수 있습니다.

여기서 구성되는 설정은 조직 구성원 권한에 대해 다음 항목들을 결정합니다:

  • 조직의 모든 저장소에 대해 admin, writer, reader 또는 권한 없음
  • 멤버가 private, internal 또는 public 저장소를 생성할 수 있는지 여부
  • 저장소의 포크(forking)가 가능한지 여부
  • 외부 협력자를 초대할 수 있는지 여부
  • public 또는 private 사이트를 게시할 수 있는지 여부
  • 관리자(admin)가 저장소에 대해 가지는 권한
  • 멤버가 새 팀을 생성할 수 있는지 여부

Repository Roles

기본적으로 저장소 역할은 다음과 같이 생성됩니다:

  • Read: 프로젝트를 보거나 논의하려는 코드 기여자가 아닌 사용자에 권장
  • Triage: 쓰기 권한 없이 이슈와 PR을 적극적으로 관리해야 하는 기여자에게 권장
  • Write: 프로젝트에 적극적으로 푸시하는 기여자에게 권장
  • Maintain: 민감하거나 파괴적인 작업에 접근하지 않고 저장소를 관리해야 하는 프로젝트 매니저에게 권장
  • Admin: 보안 관리나 저장소 삭제 같은 민감하고 파괴적인 작업을 포함해 프로젝트에 대한 전체 접근이 필요한 사람에게 권장

각 역할의 권한을 이 표에서 비교할 수 있습니다 https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

또한 https://github.com/organizations/<org_name>/settings/roles 에서 자체 역할을 생성할 수 있습니다.

Teams

https://github.com/orgs/<org_name>/teams 에서 조직에 생성된 팀 목록을 볼 수 있습니다. 다른 팀의 하위 팀(자식 팀)을 보려면 각 상위 팀에 접근해야 한다는 점을 유의하세요.

Users

조직의 사용자는 https://github.com/orgs/<org_name>/people. 에서 목록화할 수 있습니다.

각 사용자 정보에서 사용자가 속한 팀과 사용자가 접근 가능한 저장소를 확인할 수 있습니다.

Github Authentication

Github는 계정에 인증하고 사용자를 대신해 작업을 수행하기 위한 여러 방법을 제공합니다.

Web Access

github.com에 접근할 때 사용자 이름과 비밀번호(및 경우에 따라 2FA)로 로그인할 수 있습니다.

SSH Keys

계정에 하나 이상의 공개키(public keys)를 구성하여 관련 개인키(private key)가 사용자를 대신해 작업을 수행할 수 있도록 할 수 있습니다. https://github.com/settings/keys

GPG Keys

이 키들로는 **사용자를 사칭(impersonate)**할 수는 없지만, 서명 없는 커밋을 보낼 때 **발견(discover)**될 수 있으므로 사용하지 않으면 문제가 될 수 있습니다. vigilant mode에 대해 더 알아보기.

Personal Access Tokens

애플리케이션에 계정 접근을 허용하기 위해 personal access token을 생성할 수 있습니다. 토큰을 생성할 때 사용자는 토큰이 가질 **권한(permissions)**을 명시해야 합니다. https://github.com/settings/tokens

Oauth Applications

Oauth applications는 일부 github 정보에 접근하거나 사용자를 사칭해(impersonate) 작업을 수행하기 위한 권한을 요청할 수 있습니다. 흔한 예로는 여러 플랫폼에서 찾을 수 있는 login with github 버튼이 있습니다.

몇 가지 보안 권고사항:

  • OAuth App은 항상 지정된 scopes에 대해서만, 인증된 GitHub 사용자로서 GitHub 전반에서 동작해야 합니다(예: 사용자 알림 제공 등).
  • OAuth App은 “Login with GitHub“을 활성화하여 인증된 사용자의 identity provider로 사용될 수 있습니다.
  • 단일 저장소에만 작동하도록 애플리케이션을 만들려면 OAuth App을 사용하지 마세요. repo OAuth scope를 사용하면 OAuth Apps는 인증된 사용자의 모든 저장소에 대해 작동할 수 있습니다.
  • 회사나 팀용 애플리케이션으로 OAuth App을 만들지 마세요. OAuth Apps는 단일 사용자로 인증되므로, 한 사람이 회사용으로 OAuth App을 만들고 회사를 떠나면 다른 사람이 접근할 수 없게 됩니다.
  • More in here.

Github Applications

Github applications는 특정 리소스에 대해 github 정보에 접근하거나 사용자를 사칭해 특정 작업을 수행하도록 권한을 요청할 수 있습니다. Github Apps에서는 앱이 접근할 저장소를 명시해야 합니다.

  • GitHub App을 설치하려면 organization owner이거나 저장소에 대한 admin 권한이 있어야 합니다.
  • GitHub App은 개인 계정 또는 조직에 연결되어야 합니다.
  • 자체 Github application은 https://github.com/settings/apps 에서 생성할 수 있습니다.
  • 계정에 접근 권한이 있는 모든 Github applications는 https://github.com/settings/apps/authorizations 에서 볼 수 있습니다.
  • Github Applications용 API Endpoints는 다음에서 확인할 수 있습니다: https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. 앱 권한에 따라 일부 엔드포인트에 접근할 수 있습니다.
  • 조직에 설치된 앱은 https://github.com/organizations/<org_name>/settings/installations 에서 볼 수 있습니다.

몇 가지 보안 권고사항:

  • GitHub App은 사용자와 독립적으로 행동해야 합니다(앱이 user-to-server 토큰을 사용하지 않는 한). user-to-server 접근 토큰을 보다 안전하게 유지하려면, 만료되는(8시간 후) access tokens과 새 access token으로 교환 가능한 refresh token을 사용할 수 있습니다. 자세한 내용은 “Refreshing user-to-server access tokens“를 참조하세요.
  • GitHub App이 특정 저장소와 통합되었는지 확인하세요.
  • GitHub App은 개인 계정 또는 조직에 연결되어야 합니다.
  • GitHub App이 사용자처럼 모든 것을 알고 모든 작업을 수행할 것이라고 기대하지 마세요.
  • “Login with GitHub” 서비스만 필요하다면 GitHub App을 사용하지 마세요. 다만 GitHub App은 사용자 로그인과 다른 작업을 동시에 수행하기 위해 user identification flow를 사용할 수 있습니다.
  • GitHub 사용자로서만 행동하고 그 사용자가 할 수 있는 모든 것을 하려면 GitHub App을 만들지 마세요.
  • 앱을 GitHub Actions와 함께 사용하고 workflow 파일을 수정하려면 workflow scope를 포함한 OAuth 토큰으로 사용자를 대리해 인증해야 합니다. 사용자는 해당 workflow 파일을 포함하는 저장소에 대해 admin 또는 write 권한을 가져야 합니다. 자세한 내용은 “Understanding scopes for OAuth apps“를 참조하세요.
  • More in here.

Github Actions

이 기능은 github에 인증하는 방법은 아니지만, 악의적인 Github Action은 unauthorised access to github를 얻을 수 있고, Action에 부여된 **권한(privileges)**에 따라 여러 종류의 공격이 가능할 수 있습니다. 아래에서 더 자세히 설명합니다.

Git Actions

Git actions는 이벤트가 발생할 때 코드를 자동으로 실행하게 합니다. 보통 실행되는 코드는 저장소의 코드와 관련된 작업(예: 도커 컨테이너 빌드 또는 PR에 비밀이 포함되어 있지 않은지 확인)입니다.

Configuration

https://github.com/organizations/<org_name>/settings/actions 에서 조직의 github actions 설정을 확인할 수 있습니다.

github actions의 사용을 완전히 금지하거나, 모든 github actions를 허용하거나, 특정 액션만 허용하도록 설정할 수 있습니다.

또한 누가 Github Action을 실행하려면 승인해야 하는지와 Action 실행 시 GITHUB_TOKEN의 권한을 구성할 수 있습니다.

Git Secrets

Github Action은 보통 github 또는 서드파티 애플리케이션과 상호작용하기 위해 비밀(secrets)이 필요합니다. 저장소에 평문으로 두는 것을 피하기 위해, github은 이를 Secrets로 저장할 수 있게 합니다.

이 비밀들은 저장소 단위 또는 조직 전체에 대해 구성할 수 있습니다. 그런 다음 Action이 비밀에 접근하려면 다음과 같이 선언해야 합니다:

steps:
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}

Bash 사용 예제 

steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"

Warning

Secrets는 선언된 Github Actions에서만 액세스할 수 있습니다.

repo나 조직에 한 번 구성되면 GitHub 사용자는 더 이상 이를 액세스할 수 없고, 단지 변경만 할 수 있습니다.

따라서, github secrets를 훔칠 수 있는 유일한 방법은 Github Action을 실행하는 머신에 접근할 수 있는 것입니다 (그 경우에는 Action에 선언된 secrets만 접근할 수 있습니다).

Git Environments

Github는 environments를 생성해 secrets를 저장할 수 있게 합니다. 그런 다음, github action에 환경 내부의 secrets에 대한 액세스를 다음과 같이 부여할 수 있습니다:

jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name

You can configure an environment to be accessed by all branches (default), only protected branches or specify which branches can access it.
Additionally, environment protections include:

  • Required reviewers: gate jobs targeting the environment until approved. Enable Prevent self-review to enforce a proper four‑eyes principle on the approval itself.
  • Deployment branches and tags: restrict which branches/tags may deploy to the environment. Prefer selecting specific branches/tags and ensure those branches are protected. Note: the “Protected branches only” option applies to classic branch protections and may not behave as expected if using rulesets.
  • Wait timer: delay deployments for a configurable period.

환경은 모든 브랜치(기본), 보호된 브랜치만, 또는 접근 가능한 브랜치를 지정하도록 구성할 수 있습니다.
또한 환경 보호에는 다음이 포함됩니다:

  • Required reviewers: 환경을 대상으로 하는 job들을 승인될 때까지 차단합니다. 승인 과정에서 적절한 이중 승인(four‑eyes) 원칙을 강제하려면 Prevent self-review를 활성화하세요.
  • Deployment branches and tags: 어떤 브랜치/태그가 환경에 배포할 수 있는지 제한합니다. 특정 브랜치/태그를 선택하고 해당 브랜치들을 보호 상태로 유지하는 것이 좋습니다. 참고: “Protected branches only” 옵션은 클래식 브랜치 보호에 적용되며 rulesets를 사용하는 경우 예상대로 동작하지 않을 수 있습니다.
  • Wait timer: 배포를 구성 가능한 시간만큼 지연시킵니다.

It can also set a number of required reviews before executing an action using an environment or wait some time before allowing deployments to proceed.

또한 환경을 사용하는 action을 실행하기 전 필요한 검토 수를 설정하거나 배포 진행을 허용하기 전에 일정 시간을 대기하도록 설정할 수 있습니다.

Git Action Runner

A Github Action can be executed inside the github environment or can be executed in a third party infrastructure configured by the user.

Several organizations will allow to run Github Actions in a third party infrastructure as it use to be cheaper.

You can list the self-hosted runners of an organization in https://github.com/organizations/<org_name>/settings/actions/runners

The way to find which Github Actions are being executed in non-github infrastructure is to search for runs-on: self-hosted in the Github Action configuration yaml.

It’s not possible to run a Github Action of an organization inside a self hosted box of a different organization because a unique token is generated for the Runner when configuring it to know where the runner belongs.

If the custom Github Runner is configured in a machine inside AWS or GCP for example, the Action could have access to the metadata endpoint and steal the token of the service account the machine is running with.

Git Action Runner

Github Action은 github 환경 내부에서 실행되거나 사용자가 구성한 제3자 인프라에서 실행될 수 있습니다.

몇몇 조직은 비용 절감 등의 이유로 Github Actions를 제3자 인프라에서 실행하도록 허용합니다.

조직의 self-hosted runners 목록은 _https://github.com/organizations/<org_name>/settings/actions/runners_에서 확인할 수 있습니다.

어떤 Github Actions가 non-github 인프라에서 실행되는지 확인하려면 Github Action 설정 YAML에서 runs-on: self-hosted를 검색하면 됩니다.

다른 조직의 self-hosted 박스에서 한 조직의 Github Action을 실행하는 것은 불가능합니다. 러너가 어느 조직에 속하는지 알기 위해 구성 시 **러너용 고유 토큰(unique token)**이 생성되기 때문입니다.

예를 들어 맞춤 Github Runner가 AWS 또는 GCP 내부 머신에 구성된 경우, Action은 metadata endpoint에 접근할 수 있고 해당 머신이 사용 중인 서비스 계정의 토큰을 탈취할 수 있습니다.

Git Action Compromise

If all actions (or a malicious action) are allowed a user could use a Github action that is malicious and will compromise the container where it’s being executed.

Caution

A malicious Github Action run could be abused by the attacker to:

  • Steal all the secrets the Action has access to
  • Move laterally if the Action is executed inside a third party infrastructure where the SA token used to run the machine can be accessed (probably via the metadata service)
  • Abuse the token used by the workflow to steal the code of the repo where the Action is executed or even modify it.

Git Action Compromise

모든 Action이 허용되어 있거나(또는 악성 Action이 포함된 경우) 사용자가 악의적인 Github Action을 실행하면 해당 Action이 실행되는 컨테이너를 침해할 수 있습니다.

Caution

악성 Github Action 실행은 공격자에 의해 다음과 같이 악용될 수 있습니다:

  • Action이 접근할 수 있는 모든 secrets를 탈취
  • Action이 제3자 인프라 내부에서 실행되어 머신을 실행하는 SA token에 접근할 수 있는 경우 수평 이동(lateral movement) 수행(대개 metadata service를 통해)
  • workflow에서 사용되는 토큰을 악용하여 Action이 실행되는 리포지토리의 코드를 탈취하거나 수정함

Branch Protections

Branch protections are designed to not give complete control of a repository to the users. The goal is to put several protection methods before being able to write code inside some branch.

The branch protections of a repository can be found in https://github.com/<orgname>/<reponame>/settings/branches

Note

It’s not possible to set a branch protection at organization level. So all of them must be declared on each repo.

Branch Protections

브랜치 보호(Branch protections)는 사용자에게 리포지토리에 대한 완전한 통제권을 주지 않도록 설계되었습니다. 목표는 특정 브랜치에 코드를 쓰기 전에 여러 보호 수단을 적용하는 것입니다.

리포지토리의 branch protections는 _https://github.com/<orgname>/<reponame>/settings/branches_에서 확인할 수 있습니다.

Note

조직 수준에서 브랜치 보호를 설정하는 것은 불가능합니다. 따라서 모든 리포지토리에서 개별적으로 선언해야 합니다.

Different protections can be applied to a branch (like to master):

  • You can require a PR before merging (so you cannot directly merge code over the branch). If this is select different other protections can be in place:
  • Require a number of approvals. It’s very common to require 1 or 2 more people to approve your PR so a single user isn’t capable of merge code directly.
  • Dismiss approvals when new commits are pushed. If not, a user may approve legit code and then the user could add malicious code and merge it.
  • Require approval of the most recent reviewable push. Ensures that any new commits after an approval (including pushes by other collaborators) re-trigger review so an attacker cannot push post-approval changes and merge.
  • Require reviews from Code Owners. At least 1 code owner of the repo needs to approve the PR (so “random” users cannot approve it)
  • Restrict who can dismiss pull request reviews. You can specify people or teams allowed to dismiss pull request reviews.
  • Allow specified actors to bypass pull request requirements. These users will be able to bypass previous restrictions.
  • Require status checks to pass before merging. Some checks need to pass before being able to merge the commit (like a GitHub App reporting SAST results). Tip: bind required checks to a specific GitHub App; otherwise any app could spoof the check via the Checks API, and many bots accept skip directives (e.g., “@bot-name skip”).
  • Require conversation resolution before merging. All comments on the code needs to be resolved before the PR can be merged.
  • Require signed commits. The commits need to be signed.
  • Require linear history. Prevent merge commits from being pushed to matching branches.
  • Include administrators. If this isn’t set, admins can bypass the restrictions.
  • Restrict who can push to matching branches. Restrict who can send a PR.

브랜치(예: master)에 다양한 보호 설정을 적용할 수 있습니다:

  • 병합 전에 PR 요구: 브랜치에 직접 코드를 병합할 수 없습니다. 이 옵션을 선택하면 추가적인 보호들이 적용될 수 있습니다.
  • 필요한 승인 수 요구: 일반적으로 PR 승인에 1명 또는 2명 이상의 승인을 요구하여 단일 사용자가 직접 코드를 병합하지 못하게 합니다.
  • 새 커밋이 푸시되면 승인 무효화: 설정하지 않으면 사용자가 합법적인 코드에 승인한 뒤 악의적인 코드를 추가해 병합할 수 있습니다.
  • 가장 최근의 reviewable push에 대한 승인 요구: 승인 이후의 모든 새 커밋(다른 협력자의 푸시 포함)에 대해 재검토를 트리거하여 승인 후 변경사항을 푸시하고 병합하는 것을 방지합니다.
  • Code Owners의 리뷰 요구: 리포지토리의 최소 1명 이상의 Code Owner가 PR을 승인해야 합니다(따라서 임의 사용자가 승인할 수 없음).
  • 누가 pull request 리뷰를 취소(dismiss)할 수 있는지 제한: 리뷰 취소가 허용된 사람이나 팀을 지정할 수 있습니다.
  • 지정된 행위자가 pull request 요구사항을 우회할 수 있도록 허용: 해당 사용자들은 이전 제한을 우회할 수 있습니다.
  • 병합 전에 상태 검사(status checks) 통과 요구: 커밋을 병합하기 전에 통과해야 하는 검사들이 있습니다(예: SAST 결과를 보고하는 GitHub App). 팁: 필수 검사를 특정 GitHub App에 바인딩하세요. 그렇지 않으면 어떤 앱이라도 Checks API를 통해 검사를 위조할 수 있고, 많은 봇은 “@bot-name skip” 같은 건너뛰기 지시를 허용합니다.
  • 병합 전에 대화(conversation) 해결 요구: 코드상의 모든 댓글이 해결되어야 PR을 병합할 수 있습니다.
  • 서명된 커밋 요구: 커밋이 서명되어야 합니다.
  • 선형 히스토리 요구: 매칭되는 브랜치에 merge commit이 푸시되는 것을 방지합니다.
  • 관리자 포함: 설정하지 않으면 관리자는 제한을 우회할 수 있습니다.
  • 매칭되는 브랜치에 누가 푸시할 수 있는지 제한: 누가 PR을 보낼 수 있는지 제한합니다.

Note

As you can see, even if you managed to obtain some credentials of a user, repos might be protected avoiding you to pushing code to master for example to compromise the CI/CD pipeline.

Note

보시다시피, 사용자의 일부 자격 증명을 획득하더라도 예를 들어 CI/CD 파이프라인을 침해하기 위해 master에 코드를 푸시하는 것을 리포지토리 보호 설정이 막을 수 있습니다.

Tag Protections

Tags (like latest, stable) are mutable by default. To enforce a four‑eyes flow on tag updates, protect tags and chain protections through environments and branches:

  1. On the tag protection rule, enable Require deployments to succeed and require a successful deployment to a protected environment (e.g., prod).
  2. In the target environment, restrict Deployment branches and tags to the release branch (e.g., main) and optionally configure Required reviewers with Prevent self-review.
  3. On the release branch, configure branch protections to Require a pull request, set approvals ≥ 1, and enable both Dismiss approvals when new commits are pushed and Require approval of the most recent reviewable push.

This chain prevents a single collaborator from retagging or force-publishing releases by editing workflow YAML, since deployment gates are enforced outside of workflows.

Tag Protections

태그(latest, stable 등)는 기본적으로 변경 가능(mutable)합니다. 태그 업데이트에 이중 승인(four‑eyes) 흐름을 강제하려면 태그를 보호하고 환경(environment)과 브랜치를 통해 보호를 연쇄하세요:

  1. 태그 보호 규칙에서 Require deployments to succeed를 활성화하고 보호된 환경(예: prod)으로의 성공적인 배포를 요구합니다.
  2. 대상 환경에서 Deployment branches and tags를 릴리스 브랜치(예: main)로 제한하고, 선택적으로 Required reviewers를 설정하며 Prevent self-review를 활성화합니다.
  3. 릴리스 브랜치에서 브랜치 보호를 구성하여 Require a pull request를 요구하고 승인 수를 ≥1로 설정하며 **새 커밋 푸시 시 승인 무효화(Dismiss approvals when new commits are pushed)**와 **가장 최근의 reviewable push에 대한 승인 요구(Require approval of the most recent reviewable push)**를 모두 활성화합니다.

이 연쇄적 보호는 워크플로우 밖에서 배포 게이트가 강제되므로, 단일 협력자가 workflow YAML을 편집해 태그를 재지정하거나 강제로 릴리스를 퍼블리시하는 것을 방지합니다.

References

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기