🧩 Trellix 소스 코드 저장소 침해 공개

보안 업체를 노리는 공급망 공격이 더 위험한 이유

사이버보안 업체 Trellix가 최근
자사 소스 코드 저장소 일부에 무단 접근이 있었다고 공개했습니다.

공개된 내용은 매우 짧았습니다.
Trellix는 “소스 코드 저장소의 일부”가 침해됐다고 밝혔지만,
어떤 저장소였는지, 어떤 코드가 노출됐는지,
공격자가 어떤 방식으로 접근했는지에 대해서는
구체적인 설명을 내놓지 않았습니다.

다만 회사는 현재까지 조사 결과를 기준으로
소스 코드 배포 또는 릴리즈 프로세스가 영향을 받았다는 증거는 없으며,
소스 코드가 실제 공격에 악용됐다는 증거도 확인되지 않았다고 밝혔습니다.

이 말은 중요합니다.

단순히 소스 코드 일부를 읽힌 것과,
실제 고객에게 배포되는 제품 빌드·릴리즈 과정이 장악된 것은
위험 수준이 완전히 다르기 때문입니다.

하지만 그렇다고 해서 이번 이슈를 가볍게 볼 수는 없습니다.
특히 Trellix는 보안 제품을 제공하는 기업입니다.
보안 업체의 소스 코드가 노출됐다는 건,
공격자에게 “보안 제품의 내부 구조 지도”가 일부 넘어갔을 가능성을 의미합니다. 😥

---

🔍 핵심은 “무엇을 봤고, 어디까지 접근했느냐”입니다

이번 사건에서 가장 중요한 질문은 하나입니다.

공격자가 단순히 코드를 읽기만 했는가,
아니면 빌드·배포·서명 과정까지 건드릴 수 있었는가?

이 차이는 매우 큽니다.

소스 코드 일부를 읽은 경우에도 위험은 있습니다.
공격자는 제품의 탐지 로직, 예외 처리, 인증 구조,
취약한 코드 패턴을 분석할 수 있습니다.

하지만 빌드나 배포 과정까지 접근했다면
문제는 훨씬 심각해집니다.

그 경우 공격자는 정상 업데이트처럼 보이는 악성 코드를
고객 환경에 배포할 수 있습니다.
이건 전형적인 소프트웨어 공급망 공격입니다.

즉, 고객 입장에서는
“내가 신뢰하고 설치한 보안 제품이
오히려 공격 경로가 되는” 최악의 상황이 될 수 있습니다.

---

🏭 왜 보안 업체의 소스 코드 침해가 더 민감할까?

일반 소프트웨어 기업의 소스 코드 유출도 위험합니다.
하지만 보안 업체는 성격이 조금 다릅니다.

보안 제품은 고객 환경 안에서
매우 높은 권한으로 동작하는 경우가 많습니다.

예를 들어 보안 제품은 보통 다음과 같은 권한을 가집니다.

• 엔드포인트의 파일과 프로세스 감시
• 네트워크 통신 모니터링
• 악성 행위 차단
• 격리, 삭제, 정책 적용
• 클라우드 또는 중앙 관리 서버와 통신
• 조직 내 다수 시스템에 일괄 배포

이런 제품의 내부 구조를 공격자가 알게 되면
단순한 코드 유출을 넘어
탐지 회피 방법을 연구할 수 있는 자료가 됩니다.

공격자는 이런 질문을 던질 수 있습니다.

“이 제품은 어떤 행위를 악성으로 판단할까?”
“어떤 API 호출은 탐지하지 않을까?”
“어떤 경로의 파일은 예외 처리될까?”
“탐지 룰은 어디서 로드될까?”
“업데이트 검증은 어떻게 이뤄질까?”

이런 정보는 공격자에게 매우 유용합니다.
특히 APT나 랜섬웨어 조직처럼
보안 제품 우회를 중시하는 공격자에게는
상당히 가치 있는 자료가 될 수 있습니다. 😓

---

🧨 최근 보안 업계 공급망 사고 흐름과 연결해서 봐야 합니다

이번 Trellix 사건은
하나의 개별 사고로만 보기 어렵습니다.

최근 보안 업계에서는
보안 도구와 개발 파이프라인을 노리는 공격이 계속 이어지고 있습니다.

대표적으로 최근에는
오픈소스 보안 스캐너와 코드 분석 도구가
공격 대상이 된 사례가 있었습니다.

공격자들은 GitHub Actions 같은
CI/CD 워크플로를 노렸고,
정상 도구처럼 보이는 오염된 버전을
배포하려는 시도를 했습니다.

여기서 중요한 키워드는 CI/CD 시크릿입니다.

CI/CD 시크릿에는 보통 이런 것들이 포함될 수 있습니다.

• GitHub Actions 토큰
• SSH 키
• 패키지 배포용 인증 정보
• 릴리즈 서명 키
• 클라우드 접근 키
• 컨테이너 레지스트리 인증 정보
• 내부 저장소 접근 토큰

공격자가 이런 값을 얻으면
단순히 저장소 하나를 본 것에서 끝나지 않습니다.

하나의 저장소에서 얻은 키로
다른 저장소에 접근하고,
또 거기서 새로운 키를 얻고,
다시 다른 조직이나 프로젝트로 이동하는 식의
연쇄 침해가 가능해집니다.

이게 바로 공급망 공격이 무서운 이유입니다.

공격 범위가 “한 회사의 코드 저장소”에서 끝나지 않고,
그 회사의 고객, 파트너, 오픈소스 생태계까지
연결될 수 있기 때문입니다.

---

🔐 소스 코드 유출보다 더 위험한 것은 “배포 경로 장악”입니다

이번 Trellix 발표에서 그나마 중요한 방어선은
회사가 현재까지는
소스 코드 릴리즈 또는 배포 프로세스가 영향받았다는 증거가 없다고 밝힌 점입니다.

이 부분은 매우 중요합니다.

공급망 사고에서 가장 위험한 시나리오는
다음과 같습니다.

공격자가 소스 코드 저장소에 접근합니다.
그다음 CI/CD 설정을 수정합니다.
빌드 과정에 악성 코드를 삽입합니다.
정상 서명 키로 릴리즈를 서명합니다.
고객은 정상 업데이트로 믿고 설치합니다.

이렇게 되면 고객 입장에서는
전통적인 보안 탐지가 매우 어려워집니다.

왜냐하면 파일은 정상 공급업체에서 내려왔고,
서명도 정상이고,
업데이트 경로도 정상처럼 보이기 때문입니다.

그래서 보안 업체의 침해 사고에서는
“코드가 유출됐나?”보다 더 중요한 질문이 있습니다.

릴리즈 무결성이 유지됐는가?
서명 키는 안전한가?
배포 패키지가 조작되지 않았는가?
빌드 로그와 아티팩트가 검증됐는가?

이 질문에 명확히 답할 수 있어야
고객도 안심할 수 있습니다.

---

🧭 고객사 입장에서 봐야 할 리스크

Trellix 제품을 사용하는 조직이라면
지금 당장 과도하게 공포를 가질 필요는 없습니다.

현재 공개된 내용만 보면
고객 배포물이나 릴리즈 프로세스가 조작됐다는 증거는
아직 확인되지 않았다고 되어 있습니다.

하지만 보안팀은 다음 관점에서
상황을 계속 추적해야 합니다.

■ 벤더 공지 모니터링
Trellix가 후속 조사 결과를 공개하는지 확인해야 합니다.
특히 침해 범위, 영향 제품, 저장소 위치,
빌드·배포 영향 여부가 중요합니다.

■ 제품 업데이트 이력 확인
최근 업데이트된 Trellix 제품이나 에이전트가 있다면
해당 버전의 해시, 서명, 배포 경로가
정상인지 확인하는 절차가 필요합니다.

■ 이상 행위 탐지 강화
보안 제품 자체의 이상 동작도 모니터링해야 합니다.
예를 들어 관리 서버와의 통신 패턴 변화,
정책 변경, 예상치 못한 프로세스 생성,
비정상 네트워크 연결 등을 볼 수 있습니다.

■ 벤더 접근 권한 재점검
보안 제품은 운영 편의성을 위해
높은 권한과 광범위한 접근성을 가질 수 있습니다.
관리 콘솔 계정, API 토큰, 연동 계정의 권한을
최소화했는지 다시 점검하는 것이 좋습니다.

---

🧱 보안 업체가 특히 강화해야 할 영역

이번 사건은 Trellix만의 문제가 아닙니다.
모든 보안 업체, 그리고 소프트웨어를 배포하는 모든 기업이
같은 질문을 받아야 합니다.

“우리의 개발·빌드·배포 체인은
정말 공격자에게 안전한가?”

이를 위해서는 아래 항목이 중요합니다.

■ 저장소 접근 통제
개발자 계정에 MFA를 적용하고,
권한을 최소화해야 합니다.
퇴사자·외주·임시 계정도 정기적으로 정리해야 합니다.

■ CI/CD 시크릿 관리
토큰과 키를 코드나 설정 파일에 직접 넣지 않아야 합니다.
시크릿은 별도 관리 시스템에 저장하고,
짧은 수명과 최소 권한 원칙을 적용해야 합니다.

■ 빌드 환경 격리
빌드 서버는 일반 업무망과 분리해야 합니다.
외부 입력이 빌드 과정에 영향을 주지 않도록
워크플로 권한도 제한해야 합니다.

■ 릴리즈 서명 보호
서명 키는 가장 중요한 자산입니다.
가능하면 HSM이나 전용 키 관리 체계를 사용하고,
서명 작업은 강한 승인 절차를 거쳐야 합니다.

■ 변경 탐지와 감사 로그
누가 어떤 코드를 수정했는지,
어떤 워크플로가 실행됐는지,
어떤 아티팩트가 생성됐는지 추적 가능해야 합니다.

■ 침해 후 접근 제거
침해를 확인했다고 끝이 아닙니다.
공격자가 남겨둔 토큰, SSH 키, 백도어성 계정,
변조된 워크플로가 있는지 끝까지 확인해야 합니다.

일부 과거 사례에서는
방어자가 침해를 인지한 뒤에도
공격자가 계속 코드 변경을 시도한 정황이 있었습니다.
즉, “발견”과 “퇴출”은 다른 문제입니다.

---

⚠️ 이번 사건에서 아직 남은 질문들

현재 Trellix가 공개한 정보는 제한적입니다.
그래서 고객과 보안 업계가 궁금해할 질문이 많습니다.

• 침해된 저장소는 어디에 있었는가?
• 접근 권한은 읽기 전용이었는가?
• 공격자가 CI/CD 워크플로에 접근했는가?
• 릴리즈 서명 키나 배포 인증 정보가 노출됐는가?
• 영향받은 제품군은 무엇인가?
• 공격자는 어떤 초기 침투 경로를 사용했는가?
• 고객이 직접 조치해야 할 항목이 있는가?
• 오픈소스 또는 서드파티 구성요소가 관련됐는가?

이 질문들에 대한 답이 나와야
실질적인 위험 수준을 판단할 수 있습니다.

지금 단계에서 중요한 태도는
“아무 일도 아니다”라고 넘기지 않는 것입니다.
동시에 확인되지 않은 내용으로
과도하게 단정하지 않는 것도 필요합니다.

---

🧠 결론: 소스 코드 저장소는 이제 ‘내부 문서함’이 아니라 핵심 공격 표면입니다

이번 Trellix 사건은
보안 업체도 공급망 공격의 예외가 아니라는 점을
다시 보여줍니다.

예전에는 소스 코드 저장소를
개발자들이 사용하는 내부 공간 정도로 여겼습니다.

하지만 지금은 다릅니다.

소스 코드 저장소에는
제품 구조, 탐지 로직, 취약한 코드, 빌드 설정,
배포 스크립트, 워크플로 권한, 시크릿 흔적까지
공격자가 탐낼 만한 정보가 모여 있습니다.

특히 보안 업체의 저장소라면
그 가치는 더 큽니다.

공격자는 코드를 통해
제품을 우회하는 방법을 연구할 수 있고,
더 나아가 빌드·배포 체인을 장악해
고객에게 악성 업데이트를 전달하려 할 수도 있습니다.

따라서 앞으로의 보안은
“완성된 제품을 검사하는 것”만으로는 부족합니다.

개발 단계, 빌드 단계, 배포 단계, 서명 단계,
그리고 고객 환경에 설치되는 단계까지
전체 소프트웨어 공급망을 하나의 보안 경계로 봐야 합니다.

이번 사건의 최종 영향은
Trellix의 추가 조사 결과를 봐야 판단할 수 있습니다.
다만 한 가지는 분명합니다.

소스 코드 저장소 침해는 단순한 정보 유출이 아니라,
공급망 전체를 흔들 수 있는 신호입니다.

보안팀은 이제 저장소, CI/CD, 릴리즈 서명,
벤더 업데이트 검증을
침해 대응과 자산 관리의 핵심 영역으로 다뤄야 합니다. 🙏