Hacker News 의견들
  • GitHub이 Actions의 불변 버전 관리(immutable versioning) 를 강제하지 않는 이유가 궁금함
    보안 가이드는 커밋 SHA로 고정(pin)하라고 하지만, 아예 고정하지 않으면 Action을 게시할 수 없게 만들면 이런 문제를 줄일 수 있을 것 같음

    • 이런 논의에는 항상 양면성이 있음
      보안팀 입장에서는 고정 버전이 안전하지만, 동시에 보안 업데이트 자동 반영이 안 되면 위험함
      결국 생산성을 해치지 않으면서 두 가지를 모두 만족시키는 해법이 필요함
      이걸 “Pinning의 역설”이라 부르고 싶음
    • GitHub Actions가 git 태그 모델을 따르고 있어서 지금 구조를 바꾸기 어렵다고 생각함
      그래도 언젠가는 바꾸는 작업을 시작해야 함
    • 만약 고정한 버전이 이미 오염된 상태였다면 어떨까?
      업데이트를 허용해야 오히려 보안이 강화될 수도 있음
      이건 정적 링크 vs 동적 링크 논쟁과 비슷한 문제임
      게다가 Trivy Action은 어차피 최신 버전을 가져오도록 되어 있었음
  • 이번 사건은 “공급망 보안(supply chain security)” 제품들이 실제로는 자신들이 보호하려는 스택만큼이나 취약할 수 있음을 보여주는 경고임
    특히 “모든 곳에서 실행되는(run us everywhere)” 보안 도구들은 한 번의 공격으로 수많은 사용자를 동시에 위험에 빠뜨릴 수 있는 새로운 공격 벡터를 제공함

  • 처음엔 Trivy가 자격 증명 회전(rotation) 을 제대로 하지 않은 줄 알았음
    하지만 그들은 “비원자적(non-atomic) 회전 과정에서 공격자가 새 토큰을 알아냈을 수도 있다”고 설명함
    GitHub은 발급 후 토큰을 다시 보여주지 않는데, 어떤 인증 방식을 썼는지에 따라 다를 수 있음

    • OpenClaw 제작자도 비슷한 경험을 했다고 함
      새 GitHub 조직을 만들자마자 이름이 탈취되어, GitHub 측에 원자적 생성 처리를 요청해야 했다고 함
  • 취약점을 스캔해야지, 취약점이 되면 안 된다”는 말이 절묘하게 들어맞는 사건임

    • 취약점을 들여다보면, 취약점도 너를 들여다본다”는 농담이 나올 정도임
  • 관련 사건으로 Trivy 공급망 일시적 침해 가 있었음

    • “일시적”이라는 표현은 너무 완곡한 표현 같음
  • 3월 22일 공격자는 탈취된 자격 증명으로 악성 Trivy v0.69.5, v0.69.6 DockerHub 이미지를 게시함
    (보안 공지 링크)
    3월 19일과 22일 두 번의 사건이 있었고, 공격자는 두 차례의 자격 증명 회전에도 불구하고 지속적으로 접근 권한을 유지한 것으로 보임

    • 실제로는 2월부터 이미 전체 리포지토리 침해가 있었고, 이번이 같은 공격자에 의한 세 번째 성공적인 공격임
  • “지난 2주가 최악이었음”
    Trivy가 털린 탓에 수많은 보안 보고서와 회의를 처리해야 하는 상황임

  • “보안 소프트웨어를 만든다고 해서 반드시 유능한 건 아니다”는 교훈임
    우리 보안팀도 매달 새로운 스캐너를 도입하려고 하지만, 그들이 요구하는 광범위한 접근 권한을 허용했다면 이미 여러 번 털렸을 것임

    • 예전에 Trivy의 GitHub Actions를 감사(audit) 해봤는데, setup-trivy Action이 메인 브랜치를 그대로 클론하고 쉘 스크립트를 실행하는 구조였음
      즉, 모든 CI 워크플로에서 임의 코드 실행이 가능했음
      Aqua는 이달 초 침해를 당했고, 두 번이나 격리 실패 후 Docker Hub 계정까지 뚫림
      이제는 외부 전문가의 도움이 필요하다고 생각함
    • “보안 도구”에 광범위한 접근 권한을 주는 건 위험 감소가 아니라 위험 확산임
      대부분은 시끄러운 리포트 생성기일 뿐이고, 공격자가 내부에 들어오면 아무런 방어도 못 함
      새로운 스캐너는 격리된 샌드박스에서 읽기 전용 데이터만 접근하게 하고, 충분히 검증될 때까지 프로덕션 권한을 주지 말아야 함
      그렇지 않으면 비밀키를 pastebin에 올리는 것과 다를 바 없음
    • 요즘 기업 보안은 모든 장비에 엔드포인트 보안 솔루션을 깔고, 모든 로그를 AI 대시보드로 보내는 식임
      “빠르게 움직이며 모든 걸 부수는” 보안 문화가 되어버림
    • 보안 부서에는 “시장에 쓸 만한 제품이 없으니 아무것도 쓰지 않겠다”는 선택지가 사실상 없음
      그래서 품질이 낮은 보안 소프트웨어라도 무조건 도입하는 문화가 생김
      Trivy 자체는 나쁘지 않다고 생각하고, 우리 회사도 사용 중임
      다만 우리는 Nix로 버전을 고정하고 직접 Actions 워크플로를 작성해서 이번 침해 영향을 받지 않았음
  • 공격자가 인증된 상태로 태그 강제 업데이트(force-update) 를 수행할 수 있었음
    GitHub의 오래된 설정인 “태그 덮어쓰기 금지”만 켜놨어도 막을 수 있었던 일임
    이런 사건이 반복될수록 소프트웨어 건축법(Software Building Code) 같은 표준이 필요하다는 생각이 강해짐
    2026년에 이런 이유가 몇 개나 더 생길지 궁금함