오프닝



코드마스터입니다. 핵심부터 짚겠습니다. 클라우드 보안의 전장이 완전히 바뀌었습니다. 과거의 해커들이 유출된 ID와 비밀번호를 들고 성문을 두드렸다면, 이제는 성벽 자체에 생긴 미세한 균열, 즉 소프트웨어의 취ACM 취약점을 찾아내어 침투하고 있습니다.

최근 Google의 위협 보고서에 따르면, 클라우드 환경을 겨냥한 침입 방식이 '자격 증명(Credentials) 탈취'에서 '소프트웨어 취약점(Vulnerability) 악용'으로 급격히 이동하고 있음이 확인되었습니다. 이는 한국의 엔터프라이즈 기업들에게 매우 중요한 신호입니다. 국내 많은 기업이 클라우드 네이티브 아키텍처로 전환하며 IAM(Identity and Access Management)과 MFA(다요소 인증)를 강화해 왔지만, 정작 우리가 사용하는 오픈소스 라이브러리와 인프라 구성 요소의 취약점 관리에는 허점이 드러나고 있기 때문입니다.

핵심 내용



Google의 2025년 하반기 분석 데이터는 매우 충격적입니다. 조사된 클라우드 침입 사례 중 무려 4약 44.5%가 소프트웨어 취약점을 악용하여 초기 접근 권한을 획득했습니다. 반면, 기존의 주된 공격 방식이었던 탈취된 계정을 이용한 침입은 27% 수준으로 감소했습니다. 이는 역설적으로 우리가 구축해 온 계정 보호 체계가 어느 정도 효과를 거두고 있음을 의미하지만, 동시에 공격자들이 더 정교하고 기술적인 경로를 찾아냈음을 시사합니다.

가장 주목해야 할 점은 공격의 '속도'입니다. 취약점이 대중에 공개된 후, 공격자들이 이를 무기화하여 실제 클라우드 환경에 암호화폐 채굴기(Cryptominer)를 배포하기까지 걸리는 시간은 단 48시간 이내로 관측되었습니다. 이는 보안 패치를 적용하기 위한 의사결정 및 배포 프로세스가 공격자의 속도를 따라가지 못하고 있음을 보여줍니다.

공격의 핵심 기법은 RCE(Remote Code Execution, 원격 코드 실행)입니다. React2Shell(CVE-2025-5나 55182)이나 XWiki 취약점(CVE-2025-24893)과 같이 서버의 제어권을 직접적으로 탈취할 수 있는 취약점이 주요 타겟이 되었습니다. 이는 마치 도둑이 열쇠를 복사하는 대신, 건물의 창문 틈새를 발견하여 순식간에 내부로 침투하는 것과 같습니다.

심층 분석



기술적 관점에서 볼 때, 이러한 변화는 공격의 타겟이 'Identity(신원)'에서 'Software Supply Chain(소프트웨어 공급망)'으로 이동했음을 의미합니다. 현대의 클라우드 아키텍처는 수많은 오픈소스 라이브러리와 컨테이너 이미지, 그리고 복잡한 CI/CD 파이프라인으로 구성되어 있습니다. 공격자들은 이제 개발자가 신뢰하고 사용하는 코드의 하부 구조를 노리고 있습니다.

특히 CI/CD 파이프라인의 악용은 치명적입니다. 빌드 프로세스나 배포 스크립트에 침투하여 악성 코드를 주입하면, 이는 검증된 소프트웨어의 형태로 인프라 전반에 확산될 수 있습니다. 이는 단순한 단일 서버의 침해를 넘어, 기업 전체의 인프라 신뢰성을 무너뜨리는 결과를 초래합니다. 최근 북한, 중국, 이란 등 국가 배후 해킹 그룹들이 클라우드 내 지속성(Persistence) 확보와 데이터 유출을 위해 이러한 방식을 적극 활용하고 있다는 점도 간과해서는 안 됩니다.

또한, 클라우드의 특징인 '휘발성(Ephemerality)'이 공격자에게 유리하게 작용하고 있습니다. 컨테이너나 서버리스 함수처럼 짧은 수명을 가진 워크로드는 전통적인 보안 에이전트 설치나 사후 분석을 어렵게 만듭니다. 공격자는 인스턴스가 생성된 지 불과 1시간 만에 악성 페이로드를 실행할 수 있는 수준에 도달했습니다.

여기서 질문을 던지고 싶습니다. 여러분의 조직은 새로운 CVE가 발표되었을 때, 이를 식별하고 패치하기까지 얼마나 걸립니까? 혹시 '패치 완료'라는 체크리스트에만 매몰되어, 실제 배포 파이프라인의 무결성을 확인하는 과정은 놓치고 있지 않습니까?

실용 가이드



변화하는 위협에 대응하기 위해 실무 엔지니어와 보안 담당자가 반드시 챙겨야 할 체크리스트를 제안합니다.

1. DevSecOps의 내재화: 보안은 개발 마지막 단계가 아닌, CI/CD 파이프라인의 시작점부터 포함되어야 합니다. SAST(정적 분석)와 DAST(동적 분석)를 자동화된 파이프라인에 통합하여 취약점을 조기에 발견하십시오. 2. 소프트웨어 자재명세서(SBOM) 관리: 우리가 사용하는 모든 오픈소스와 라이브러리의 목록을 관리하고, 취약점 발생 시 즉각적인 영향도 분석이 가능하도록 아키텍팅해야 합니다. 3. IaC(Infrastructure as Code) 보안 스캔: Terraform이나 CloudFormation과 같은 인프라 코드 자체에 보안 설정 오류(Misconfiguration)가 없는지 자동화된 스캔 도구를 통해 검증하십시오. 4. 자동화된 반응(Automated Response) 체계 구축: 인간의 판단 속도로는 48시간의 공격 윈도우를 막을 수 없습니다. 이상 징후 탐지 시 즉각적으로 격리하거나 워크로드를 재생성하는 자동화된 대응 메커니즘을 갖추어야 합니다.

필자의 한마디



결론은 명확합니다. 이제 보안의 초점은 '누가 접속하는가(Who)'에서 '무엇이 실행되는가(What)'로 확장되어야 합니다. 계정 보안을 강화하는 것만큼이나, 우리가 사용하는 소프트웨어 생명주기 전반의 무결성을 관리하는 것이 클라우드 시대의 핵심 경쟁력입니다.

앞으로의 클라우드 보안은 더 정교한 자동화와 관측성(Observability)의 싸움이 될 것입니다. 실무 관점에서 결론은 명확합니다. 댓글로 여러분의 대응 전략이나 고민을 남겨주세요. 코드마스터였습니다.

출처: "https://www.ghacks.net/2026/03/10/google-cloud-attacks-now-exploit-software-flaws-more-often-than-credentials/"