GitHub에서 발견된 감염된 저장소 10만 개 이상

 (apiiro.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 2023년 중반 시작된 저장소 혼동(repo confusion) 캠페인이 재확산되며, GitHub에서 유사 악성 페이로드를 담은 저장소가 10만 개 이상 탐지됨
  • 공격자는 정상 저장소와 비슷한 악성 복제본을 만들어 개발자의 착오를 유도하고, 복제·로더 삽입·재업로드·대량 포크·은밀한 홍보를 조합함
  • 악성 저장소를 실행하면 7단계 난독화 뒤 Python 코드와 바이너리가 내려오고, 로그인 정보·브라우저 비밀번호·쿠키 등 민감 데이터가 탈취됨
  • GitHub가 대다수 포크를 자동 삭제해도 감지를 피한 저장소와 수동 업로드본은 남아, 전체의 1%만 생존해도 수천 개 악성 저장소가 유지됨
  • 공격 흐름이 PyPI 악성 패키지에서 GitHub 저장소로 옮겨가며, 패키지 매니저 밖의 소프트웨어 공급망도 직접적인 공격면이 됨

저장소 혼동 공격 방식

  • 저장소 혼동은 사용자가 정상 저장소 대신 악성 저장소를 내려받도록 유도한다는 점에서 dependency confusion과 닮아 있음
  • 차이는 악용 지점에 있음
    • dependency confusion은 패키지 매니저 동작 방식을 이용함
    • 저장소 혼동은 사람이 비슷해 보이는 저장소를 잘못 선택하는 상황에 의존함
  • 이번 캠페인은 GitHub에 악성 저장소를 대량으로 퍼뜨려 감염 가능성을 높임
    • TwitterFollowBot, WhatsappBOT, discord-boost-tool, Twitch-Follow-Bot 등 기존 저장소를 복제함
    • 복제본에 멀웨어 로더를 삽입함
    • 같은 이름으로 GitHub에 다시 업로드함
    • 각 저장소를 자동으로 수천 번 포크함
    • 포럼과 Discord 등에서 은밀히 홍보함

악성 저장소 실행 후 흐름

  • 사용자가 악성 저장소를 사용하면 숨겨진 페이로드가 7단계 난독화를 해제함
  • 이후 악성 Python 코드와 바이너리 실행 파일을 가져옴
  • 악성 코드는 주로 BlackCap-Grabber의 수정 버전에 기반함
  • 수집 대상은 여러 앱의 로그인 자격 증명, 브라우저 비밀번호와 쿠키, 기타 기밀 데이터임
  • 탈취된 데이터는 공격자의 C&C(command-and-control) 서버로 전송되고, 추가 악성 활동이 이어짐
  • 관련 코드 분석은 Trend Micro의 technical analysis에서 확인할 수 있음

GitHub 자동 삭제와 남는 저장소

  • GitHub는 자동화를 식별해 포크된 저장소 대부분을 빠르게 제거함
  • 다만 자동화 감지가 많은 저장소를 놓치고, 수동으로 업로드된 저장소는 살아남음
  • 공격 체인이 대규모로 자동화돼 있어 1%만 남아도 수천 개 악성 저장소가 됨
  • GitHub에서 🔥 2024 language:python을 검색하면 현재 확산 중인 일부 저장소를 볼 수 있음
  • 삭제된 저장소까지 포함하면 전체 규모는 수백만 개에 도달함
    • 삭제는 보통 업로드 후 몇 시간 뒤 일어나 문서화가 어려움
    • 원본 저장소 다수는 남아 있고, 삭제는 주로 fork bomb을 겨냥함
    • 예시로 Mattia69 저장소 목록에는 요약에서 수천 개 포크가 보이지만, 포크 상세에는 나타나지 않음
  • 일부 사용자가 악성 저장소를 모르고 포크하면서 2차 사회공학 네트워크 효과도 생김

캠페인 전개 시점

  • 2023년 5월: Phylum이 PyPI에 올라온 악성 패키지를 보고함
    • 이 패키지들은 현재 페이로드의 초기 부분을 포함함
    • chatgpt-api 같은 인기 GitHub 저장소의 포크에 심어진 os.system("pip install package") 호출로 확산됨
  • 2023년 7~8월: 여러 악성 저장소가 GitHub에 올라왔고, PyPI 패키지를 가져오는 대신 페이로드를 직접 전달함
    • PyPI가 악성 패키지를 제거하고 보안 커뮤니티의 관심이 높아진 뒤의 변화임
    • Trend Micro의 Aliakbar Zahravi와 Peter Girnus가 기술 분석을 공개함
  • 2023년 11월~현재: 유사한 악성 페이로드를 포함한 저장소 10만 개 이상이 탐지됐고, 수는 계속 증가함
  • 이 방식이 공격자에게 유리한 이유는 명확함
    • GitHub 규모가 커서 대량 인스턴스도 상대적으로는 작아 탐지하기 어려움
    • 이전과 달리 패키지 매니저가 개입하지 않아 명시적인 악성 패키지 이름이 지표로 남지 않음
    • 대상 저장소가 작은 틈새 영역이고 인기도가 낮아 개발자가 악성 사칭 저장소를 잘못 클론하기 쉬움

패키지 매니저에서 SCM으로 이동

  • PyPI 악성 패키지에서 GitHub 악성 저장소로의 이동은 여러 패키지 매니저와 SCM 플랫폼에서 관찰된 흐름과 맞닿아 있음
  • 보안 커뮤니티가 패키지 매니저에 더 집중하자, 공격 경로가 다른 곳으로 옮겨간 셈임
  • GitHub와 유사 플랫폼은 계정과 저장소를 자동 생성하기 쉽고, 편리한 API와 우회하기 쉬운 느슨한 rate limit을 제공함
  • 수많은 저장소 사이에 숨을 수 있어, SCM은 소프트웨어 공급망을 은밀히 감염시키기 좋은 표적이 됨
  • dependency confusion 캠페인, 패키지 레지스트리의 악성 코드, SCM을 통한 악성 코드 확산은 도구와 보안 메커니즘이 많아도 소프트웨어 공급망 보안이 취약하다는 점을 드러냄

감염 여부 확인 지표

  • Python 코드에서 다음 패턴을 검색하고, 일치 항목을 조사해야 함
    • exec(Fernet
    • exec(requests
    • exec(__import
    • exec(bytes
    • exec("""\nimport
    • exec(compile
    • __import__("builtins").exec(
  • 소셜 플랫폼 자동화, 봇, 게임 관련 저장소가 로컬에 있는지 확인하고 제거해야 함
  • 꼭 사용해야 한다면 다시 설치하되, 출처를 신중히 검증하거나 샌드박스에서 실행해야 함
  • 이런 유형의 저장소를 클론했을 가능성이 있다면 다음 쿠키, 자격 증명, 키가 탈취됐다고 보고 대응해야 함
    • 브라우저: 금융 서비스, 이메일 서비스, 암호화폐 서비스, Amazon, eBay, AliExpress, Facebook, Instagram, Twitter, Youtube, Discord, TikTok, Telegram, Twitch, Steam, Yahoo, ExpressVPN, Spotify, 스트리밍 서비스
    • 앱: Exodus, Atomic Wallet, Guarda, Coinomi, Ethereum
  • 파일 체크섬 전체 목록은 실용적으로 다루기 어렵지만, 일부 공통 항목은 VirusTotal graph에서 확인할 수 있음
  • Cloudflare는 통지를 받은 뒤 발견된 악성 주소의 DNS 레코드를 비활성화함

방어와 대응

  • GitHub는 통지를 받았고 악성 저장소 대부분을 삭제했지만, 캠페인은 계속되고 있음
  • 공급망에 악성 코드를 주입하려는 공격은 점점 더 널리 퍼지는 중임
  • 시스템·네트워크 수준에서 멀웨어를 잡는 솔루션은 많지만, 공급망은 공격자에게 여전히 크고 수익성 있는 공격면임
  • 악성 저장소를 발견하면 이번 캠페인의 일부인지와 관계없이 GitHub의 abuse or spam report를 통해 신고할 수 있음
  • Apiiro는 연결된 코드베이스를 모니터링하는 악성 코드 탐지 시스템을 구축함
    • LLM 기반 코드 분석
    • 전체 실행 흐름 그래프로의 코드 분해
    • 휴리스틱 엔진
    • 동적 디코딩, 복호화, 난독화 해제
  • 주입된 악성 페이로드를 모니터링하지 않으면 조직 보안은 개발자가 거의 동일한 잘못된 저장소를 선택하지 않는 능력, CI/CD 설정 오류가 전혀 없는 상태, 100% 안전한 서드파티 코드 같은 조건에 의존하게 됨
  • 일반적인 취약점 탐지와 수집을 넘어, 다음 세대의 소프트웨어 공급망·애플리케이션 리스크를 드러내는 접근이 필요함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 공개 저장소나 외부 소스에서 가져오는 코드는 조심하고 의존성 트리 검증을 해야 한다는 일반적인 경고를 넘어서, 공개 저장소에 악성 코드가 대량으로 있다면 그 내용으로 학습한 LLM과 자동화 도구에는 어떤 영향이 있을지 궁금함
    Copilot 같은 도구가 긴 코드 답변을 만들 때 악성 부분이 우연히 섞여 들어갈 가능성도 있어 보임
    단순한 주입 취약점 같은 건 이미 자주 목격됨

    • LLM 출력에 백도어가 우연히 들어가는 것보다, 정보기관이 LLM 출력에 백도어를 심는 쪽이 더 걱정됨
      지금은 아닐 수 있어도 몇 년 안에는 충분히 가능해 보임
    • LLM은 입력 데이터에 있던 취약 코드를 붙여 넣는 것뿐 아니라, 스스로 새 취약점도 만들어낼 것 같음
      AI는 정확성에 대해 아무 보장도 해주지 않음
    • Hugging Face의 safetensors 변환 봇을 탈취하는 LLM 관련 이슈를 막 올렸음: https://news.ycombinator.com/item?id=39549482
      공격자가 Hugging Face Safetensors 변환 공간과 연결된 서비스 봇을 장악할 수 있음을 보였고, 이는 생태계 내 안전하지 않은 머신러닝 모델을 더 안전한 버전으로 변환하는 인기 서비스임
    • 위험은 맞지만, 동료 PR을 검토 없이 받아들였을 때 어딘가에서 복사한 취약한 코드가 들어올 수 있는 위험과 비슷함
      LLM을 쓰려면 코드 리뷰에 더 많은 노력을 투자해야 하고, 그 절충은 가치 있다고 봄
    • 이 캠페인에서 탐지된 샘플 수가 워낙 많아서 생각보다 현실적인 위험임
      다만 실제 사고로 이어지려면 주로 두 장벽이 있음: 생성기가 그런 코드를 피하라는 내부 지시를 받는다는 점, 그리고 LLM 특성상 실제 공격자의 주소를 그대로 반복할 가능성은 낮다는 점
      그래도 바인드 셸, 서비스 거부, 현장 유출 같은 다양한 공격 벡터는 여전히 남음

  • GitHub는 Usenet이 실패한 방식과 비슷하게 실패하고 있음
    누구나 저장소를 만들 수 있고, 공식 저장소와 스팸 저장소를 구분해 주는 게 없음
    Amazon이 “모든 것의 상점”을 목표로 하다가 “모든 것의 90%는 쓰레기”에 맞아 대부분 쓰레기인 상점이 된 것처럼, GitHub도 제품이 “모두를 위한 저장소”인지 “믿을 수 있는 코드”인지 정해야 함
    예를 들어 공식 PG JDBC도 스패머가 재현하지 못할 요소가 없어 보이는데, 이게 감염 저장소가 아니라고 어떻게 신뢰할 수 있나: https://github.com/pgjdbc

    • GitHub는 16년 전 회사를 처음 시작했을 때 이미 모두를 위한 저장소를 선택한 것 같음
    • Java 라이브러리라면 보통 GitHub가 아니라 Maven Central에서 내려받게 됨
      Sonatype은 groupId에 쓰인 역방향 도메인 소유권 증명을 요구하고, 이 경우 org.postgresql임
      방법은 여기 있음: https://central.sonatype.org/faq/how-to-set-txt-record/
      더 안심하려면 Maven Central에 게시되는 모든 산출물이 서명되므로 GPG 서명도 확인할 수 있지만, Postgres가 서명에 쓰는 키를 Sonatype과 독립적인 경로로 구해야 한다는 단점이 있음
      PG의 경우 빠르게 검색해도 키를 찾지 못했음
    • 이 숫자가 얼마나 작은지 제대로 감이 안 오는 것 같음
      GitHub에는 약 5억 개 저장소가 있으니, 이 정도는 실제로 꽤 좋은 편임
    • 감염 저장소 10만 개 이상은 좋지 않지만, 그렇다고 GitHub가 실패했다는 뜻은 아님
      감염 저장소를 가져다 쓸 개발자라면 GitHub에 그런 저장소가 없어도 안전하지 않은 제품을 만들 다른 방법을 얼마든지 찾을 수 있음
    • 도메인 소유권을 증명하면 조직 페이지에 검증 배지를 받을 수 있고, 신뢰도를 꽤 높일 수 있음
      예시로 든 조직은 그냥 그걸 하지 않은 것으로 보임

  • 공급망 문제가 정말 골치 아픔
    npm 릴리스를 직접 대상으로 하진 않지만, BrowserBox라는 가벼운 가상화 웹브라우저 프로젝트를 모니터링하려고 npm 릴리스를 만들어 socket.dev를 사용 중임
    이 프로젝트도 전체 하위 의존성까지 약 800개, 최상위 의존성 19개만 쓰는데, 전체 스택 기준으로는 비교적 가벼운 편임
    이제 800개 의존성을 모두 npm의 @browserbox 네임스페이스로 스냅샷해 두고, 발견되는 취약점을 추적해 패치할까 고민 중임
    미친 소리처럼 들리지만 지금 상황이 그렇고, 최소한 그렇게 하면 Node/JS 쪽 공급망 취약점은 회사 보안 수준 내에서 직접 보장할 수 있음
    https://socket.dev
    https://github.com/BrowserBox/BrowserBox

    • npm에 같은 기능이 얼마나 있는지는 모르겠지만, crates.io와 cargo에는 cargo audit와 cargo deny처럼 파이프라인에서 의존성 트리의 CVE를 확인하는 도구가 있음
      잠금 파일이 트리 전체의 sha256을 유지하므로 저장소가 해킹되더라도 변경 방지를 위해 미러링할 필요는 없음
      최신보다 몇 달 뒤 버전에 고정하는 게 새 CVE를 피하면서도 너무 오래된 버전에 묶여 한꺼번에 크게 고치는 상황을 피하는 적절한 균형처럼 보임
      다운로드 수는 비슷한 목적의 최상위 의존성과 비교할 때 괜찮은 척도 같지만 주관적인 판단임
      Austral은 선형 타입으로 의존성에 세밀한 권한을 부여함
      그래픽 라이브러리에 파일 입출력이 필요 없고, 네트워크 전송 라이브러리에 마이크 접근이 필요 없다는 식임
      완화책일 뿐이지만 다른 언어에서도 보고 싶음
    • “의존성 약 800개만”이라는 표현이 살짝 소름 끼침
      10년쯤 전 .NET에서 Java로 옮긴 뒤 의존성 지옥에 들이는 시간이 크게 늘어 놀랐고, 요즘은 Java와 Python 프로젝트 모두에서 취약점 업데이트와 의존성 문제에 드는 시간이 무섭게 많음
      .NET에서 이 문제가 덜했던 이유는 자동 패키지 관리 도입이 상대적으로 늦었고 NuGet도 젊은 편이라, 당시엔 많은 프로젝트가 아직 채택하지 않아 거대한 전이 의존성 트리를 피하는 문화가 강했기 때문 같음
      Boeing의 최근 문제도 비슷하게 보임
      지난 수십 년간 생산을 외부 공급업체로 더 많이 넘기고 비용 최적화에 집중하면서 공급망 관리가 점점 어려워졌고, 큰 그림에서는 현대 소프트웨어 공학의 공급망 문화와 닮아 있음
      공급망 보안 때문에 패키지 관리자를 금지한 금융사에서 일했을 때 의존성 관리가 가장 덜 귀찮고 품질 문제도 가장 적었음
      명시적으로 바꾸지 않는 한 절대 바뀌지 않는 코드에는 장점이 있음
      남들이 패키지를 가져다 쓸 부분도 직접 많이 구현했는데, 필요한 것만 하고 더 높은 코드 기준을 적용하니 이해·디버깅·수정이 쉬웠음
      처음 작성하는 비용은 일회성이고 잘 상각되지만, 모두를 위해 모든 걸 하려는 코드를 다루는 반복 비용은 장기적으로 더 커지고 보통 누적됨
      Rich Hickey의 “Simple Made Easy”가 이 현상을 잘 보여줬고, 단순한 것과 쉬운 것은 다르며 단순한 선택지는 초반엔 더 어려워 보여도 2차 효과가 쌓이면 장기적으로 더 쉬워짐

  • 비슷한 저장소를 우연히 보면서 이런 걸 이미 알아차렸음
    원래도 아무 저장소 코드나 실행하지 않지만, 이제는 저장소와 소유자를 신뢰해도 샌드박스 VM을 띄움
    오늘날 개발자라면 업무, 취미, 개인용을 최소한 세 환경으로 확실히 분리해야 할 듯함

    • 개발자가 업무·취미·개인 환경을 분리해야 한다는 말 자체가, 디지털 생활의 복잡성이 장기적으로 지속 가능할지 의심하게 만들 정도로 커졌음을 보여줌
    • 해마다 Qubes가 더 합리적인 선택처럼 보임
    • 나도 지금은 잠재적 악성 소프트웨어 때문만이 아니라 이렇게 함
      악성은 아니어도 설계상 허술하거나 어리석게 작성된 프로젝트가 있음
      얼마 전 실행한 프로그램은 내가 아무 작업도 요청하기 전에 ~/.bashrc에 3줄을 추가했고, 며칠 뒤에야 알았음
      어떤 개발자가 이걸 좋은 생각이라고 보는지 이해할 수 없고, 그래서 이제 외부 코드를 실행할 때마다 샌드박스를 쓰게 됨
    • 모든 것이 기본적으로 VM에서 실행되는 Qubes OS를 쓸 좋은 이유처럼 들림
      내 일상용 OS임
    • 업무와 개인 환경을 섞지 않는 건 기본 중의 기본 아닌가 싶음
      이런 걸 허용하는 고용주가 실제로 있나?

  • 직장에서 이런 문제를 피하려고 어떤 도구를 쓰는지, 현재 구성에 만족하는지 궁금함
    꽤 작은 팀으로 주간 다운로드가 많은 SDK를 개발 중이고, snyk, aikido.dev, renovate 기반 솔루션 등을 평가해 봤지만 이런 문제에 도움이 되는지 명확하지 않음
    아직 작은 팀이라 snyk처럼 오탐이 많은 도구를 다루는 것도 부담임

    • GitHub 저장소를 직접 쓰기보다 NuGet, PyPI, npm 같은 일반 패키지 저장소의 공개 패키지를 쓰고, Sonatype의 Repository와 Firewall을 우리와 패키지 저장소 사이의 프록시로 둠
      Sonatype이 모든 패키지를 분석해 여러 메타데이터를 붙이고, Firewall에서 사용할 수 있는 정책을 정의해 나머지를 걸러냄
      공개된 의존성에만 통하지만 몇 년 써본 결과 꽤 잘 작동함
      지금까지 악성코드 문제는 없었고, 알려진 취약점이 있는 패키지는 코드베이스에 들어오지 못하며, 사용 중인 것에서 취약점이 발견되면 알림을 받음
    • 직장에서 Semgrep Supply Chain을 쓰고 있고 꽤 만족함
      발견한 공급망 취약점을 도달 가능, 도달 불가능, 미정으로 나눠 줘서 분류가 훨씬 쉬워졌고, 새 취약점을 평가하는 시간이 크게 줄었음
    • 이 하위 스레드에서 악성코드와 취약점을 많이 혼동하는 듯함
      언급된 벤더들은 악성 코드를 탐지하는 게 아니라 취약점만 탐지함
      취약점 탐지는 잘하더라도 코드베이스에 심어진 악성 코드로부터는 여전히 보호받지 못함
    • 공개적으로 악성인 패키지, 방치된 패키지, 오타 스쿼팅 패키지 등 위험한 PyPI/NPM/Ruby/PHP/Maven/Rust 패키지를 탐지하는 오픈소스 도구 Packj를 만들고 있음
      정적·동적·메타데이터 분석을 수행하고, 셸 실행, SSH 키 사용, 네트워크 통신, decode+eval 사용 등 40개 이상의 속성을 검사해 위험한 패키지를 표시함
      https://github.com/ossillate-inc/packj
    • Trivy를 살펴볼 만함
      지금까지는 꽤 잘 작동했음
      https://trivy.dev/

  • curl로 셸 설치 스크립트를 받아 sudo로 실행하는 관행이 곧 끝날지 궁금함
    “우리 소프트웨어를 설치하려면 curl [https://somesite/install.sh](<https://somesite/install.sh>;)' | sudo sh를 실행하세요” 같은 방식은 기사에서 언급한 감염 코드와 아주 잘 맞물릴 듯함

    • 이 연구의 저자로서 확인해 줄 수 있음
      우리 시스템은 매주 언급한 패턴을 약 100건 나열하고, 그중 약 3%가 악성임
      이 관행이 끝나는 걸 보고 싶음
    • 안타깝게도 npm i도 같은 권한을 가짐
      현재 흔한 의존성 다운로드 도구 중 설치나 빌드 시점에 적대적 코드가 실행되지 않는 건 go get 정도만 알고 있음
      적어도 폭발을 구획화하려면 샌드박스에서 작업하기 위한 더 나은 도구가 필요함
      ChromeOS의 “가상 머신이 메인 데스크톱에 Wayland 창을 열 수 있는” 방식은 깔끔하지만, 마지막으로 봤을 때 그 코드는 그다지 깨끗하거나 재사용 가능하지 않았음
    • 이런 예시에는 example.com을 쓰는 게 좋음
      그 목적으로 예약된 도메인임: https://www.rfc-editor.org/rfc/rfc2606.html#section-3
    • 현실적인 대안인 “배포판용 저장소를 추가하고 신뢰하세요”, “.deb/.rpm/설치 프로그램을 다운로드하세요”, 또는 최악으로 “게시자가 아니라 제3자가 패키징한 것을 신뢰하세요”보다 딱히 더 나쁘지는 않음

  • npm에서는 --ignore-scripts로 악성코드 실행을 완화할 수 있음
    https://blog.uirig.com/getting-rid-of-npm-scripts

    • 대신 내려받은 악성 코드가 운영 환경에서 실행될 수 있음
      운이 좋으면 CI에서 이상 행동을 해서 잡을 수도 있음
      진짜 해법은 https://github.com/crev-dev/cargo-crev 같은 평판 시스템인데, 안타깝게도 거의 쓰이지 않음
    • 보안 관점에서는 기본값이어야 함
      Makefile이 필요하다는 주석도 눈여겨봐야 함

  • 이런 보고가 계속 나오면서 지난 몇 달 동안 개발 환경 보안을 조금씩 개선하고 있음
    VSCode dev containers를 개발에 쓰고 있음: https://code.visualstudio.com/docs/devcontainers/create-dev-...
    한 번 만들어 두면 Docker 지식이 많지 않아도 쓰기 쉽고, 웹/콘솔 앱을 띄우기에는 좋지만 Flutter나 Electron 같은 것은 어려웠음
    작은 프로젝트에는 GitHub Codespaces도 익숙해졌음: https://github.com/codespaces
    예전에 면접에서 간단한 Node 프로젝트를 수정하는 라이브 코딩을 한 적이 있는데, 요즘이라면 그런 상황에는 컨테이너나 Codespaces를 반드시 쓸 것 같음: https://www.welivesecurity.com/en/eset-research/lazarus-luri...
    npm, Node, Docker 모범 사례는 OWASP 지침을 정기적으로 읽고, Docker는 가능한 작은 이미지와 명시적 이미지 태그를 쓰는 식으로 적용함: https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker...
    npm/python 패키지는 설치 전에 socket.dev로 환경 변수 접근, 네트워크 호출, 공급망 공격, 최근 코드 소유권 변경 등을 확인하고, OWASP가 권장하듯 postinstall 스크립트를 전역 비활성화할 수도 있음: https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_...

  • 1년도 안 된 사례로 트로이 목마 바이러스가 있는 저장소가 있었음: https://github.com/orgs/community/discussions/63603

    • 저장소가 비밀번호 탈취기라고 주장했고, 다운로드해서 압축을 풀었더니 개인 정보와 파일을 훔쳤다면 문제를 모르겠음
      저장소가 주장한 그대로 동작한 셈임

  • 공식 저장소임을 단순히 표시하는 것만으로도 어느 정도 주목을 끌 수 있음

    • 나중에는 GitHub가 그 파란 체크를 팔기 시작할 수도 있음
      대체 무슨 일이 생기겠나 /s
      그래도 GitHub가 어떤 저장소가 프로젝트의 공식 저장소인지 더 잘 보여줘야 한다는 점에는 동의함
답변달기