왜 Shift Left 꿈이 보안과 개발자에게 악몽이 되었는가

Source: Bleeping Computer

작성자: Ivan Milenkovic, Vice President Risk Technology EMEA, Qualys

소개

지난 10년 동안 우리는 보안과 개발에 관한 편안한 허구에 빠져 있었습니다. 만약 우리가 **“좌측 이동(shift left)”**을 실천하고 개발자들이 코딩, 테스트, 인프라 배포와 함께 보안에 조금 더 책임을 지게 할 수 있다면, 디지털 세계는 더 안전하고, 더 빠르며, 더 저렴해질 것입니다.

그럼에도 불구하고, 속도와 보안 사이의 근본적인 갈등은 오히려 악화되었습니다.

왜 이런 결과가 나왔을까?

개발자들은 엄청난 압박에 시달리고 있습니다. 프로젝트 관리의 고전적인 삼각형—Fast, Good, Cheap; pick two—가 산산조각이 났습니다.

기업들은 이제 빠르고, 좋고, 저렴하며, 안전한 솔루션을 요구합니다. 상황이 급박해지면 언제나 **“빠름”**이 승리합니다. 동시에 이미 물에 빠져 있던 개발자들에게는 과도한 인지 부하가 가해지고 있습니다.

개발자들이 개발 속도를 높이기 위해 공개 컨테이너 이미지를 사용하기로 선택하면 목표를 달성하려는 시도이지만, 동시에 잠재적인 위험에 노출되는 것입니다.

그렇다면 실제 문제를 어떻게 파악하고, 이를 해결하기 위해 어떤 접근을 해야 할까요?

비즈니스 요구 vs. 보안 권고

보안 업계에는 개발자가 게으르거나 부주의하다는 널리 퍼진 이야기가 있습니다. 그것은 사실이 아닙니다.
개발자는 과중한 업무에 시달리는 실용적인 전문가이며, 주어진 인센티브에 따라 행동합니다. 보너스가 금요일까지 기능을 출시하는 것에 달려 있고, 보안 스캔에 4시간이 걸려 빌드를 차단한다면, 개발자는 스캔을 우회하는 방법을 찾게 됩니다.

보안이 장벽으로 인식되는 이유

• 속도 압박: 비즈니스는 점점 더 빠른 결과를 요구합니다.
• 시끄러운 도구: 많은 오탐을 생성하거나 실행 속도가 느린 보안 도구는 작업 흐름을 방해합니다.
• 분리된 프로세스: 보안 검사가 CI/CD 파이프라인에 통합되지 않으면, 엔지니어링의 필수 요소라기보다 사후 생각에 불과합니다.

결과

• 조직은 실제로 환경에서 무엇이 실행되고 있는지에 대한 가시성을 잃습니다.
• 파이프라인은 코드를 자동으로 배포하고, 인프라는 사람 개입 없이 확장·축소되며, AI 에이전트가 이제 자체 스크립트를 작성하고 실행할 수 있습니다.
• 이 고속 자동화 혼란 속에서 우리는 Docker Hub와 같은 공개 레지스트리를 선별된 라이브러리처럼 여기며, 이미지가 안전할 것이라고 가정합니다.

공개 레지스트리를 신뢰하는 것은 위험

Docker, Amazon, Google, Microsoft 등은 모두 공개 컨테이너 레지스트리를 운영하므로 자연스럽게 안전하다고 여겨집니다. 그 신뢰는 잘못된 것입니다.

컨테이너 이미지가 배포 파이프라인에 도달할 때 이미 신뢰된 아티팩트—애플리케이션에 내장된—이지만, 여전히 취약점이나 악성 코드를 포함하고 있을 수 있습니다.

핵심 요점: 비즈니스 속도와 보안 사이의 격차를 메우기 위해서는 보안이 외부 장벽이 아니라 개발자 워크플로에 빠르고, 소음이 적으며, 긴밀히 통합된 도구와 프로세스가 필요합니다.

Source: https://blog.qualys.com/product-tech/2026/01/22/public-container-registry-security-risks-malicious-images

34,000‑이미지 현실 점검

Qualys Threat Research Unit (TRU)은 최근 공개 레포지토리에서 가져온 34,000개 이상의 컨테이너 이미지에 대한 포괄적인 분석을 수행하여 매니페스트 아래에서 실제로 어떤 일이 일어나고 있는지 조사했습니다.

• 악성 이미지: 약 2,500개 (전체 샘플의 ≈ 7.3 %)
  • 이 중 70 %는 암호화 채굴 소프트웨어를 포함하고 있었습니다.
• 비밀 노출: 전체 이미지의 42 %가 다섯 개 이상의 비밀(예: AWS 액세스 키, GitHub API 토큰, 이미지 레이어에 직접 포함된 데이터베이스 자격 증명 등)을 포함하고 있어 다른 리소스나 계정에 접근하는 데 사용될 수 있습니다.

주요 시사점

1. 타이포스쿼팅은 여전히 큰 위협 – 공격자는 종종 오탈자가 포함된 이미지 이름을 이용해 악성 컨테이너가 다운로드되도록 합니다.
2. “철자를 확인하라”는 간단한 조언은 필요하지만 충분하지 않으며, 고위험 문제에 대한 저비용 대응에 불과합니다.
3. 개발자에게 “좀 더 조심하라”고 말하는 것은 보안 전략이 아닙니다.

권장 접근 방식

• 성숙한 환경에서는 공개 레지스트리에서 직접 이미지 Pull을 절대 하지 말 것.
• 외부 이미지를 모두 내부 아티팩트 레포지토리를 통해 프록시하여 격리 구역으로 활용할 것.
• 인프라 팀이 무거운 작업을 담당하고, 개발자에게는 빠르고 검증된 공급 체인을 제공함으로써 속도와 보안을 균형 있게 유지할 것.

이 전환은 인프라 팀에 더 많은 작업을 요구하지만, 개발자는 더 빠르게 그리고 훨씬 적은 위험으로 작업할 수 있게 됩니다.

Shift Down

“Shift left”만으로는 부족한 이유

• 버그를 초기에 고치는 것이 비용이 적게 들지만, 보안을 SDLC 초기에 옮기는 것은 단순히 부담을 개발자에게 전가하는 것이다.

• 이제 개발자는 다음을 기대받는다:

  1. 자신의 코드를 스캔한다.
  2. 서드‑파티 의존성을 검증한다.
  3. 설정을 강화한다.
  4. 비밀 정보를 탐지한다.
  5. 컴플라이언스 감사를 수행한다.

• 동시에, 그들은 주로 기능 속도로 평가받는다.

그 결과? 보안은 모든 개발자의 할 일 목록에 또 하나의 항목이 될 뿐, 협업적인 노력이 아니다.

“Shift‑Down” 접근법

보안을 각 IDE에 강제로 넣는 대신, 보안 인프라를 기본값으로 만들고 개발자는 이미 검증된 골든 패스를 따라 작업하게 한다.

골든 패스를 유지하면 보안이 자동으로 적용된다. 오프‑로드를 선택하면 추가 보안 단계를 직접 처리해야 한다.

구현 방법

1. 플랫폼‑엔지니어링 기본값

   • Terraform 모듈 / Crossplane 컴포지션 / OPA 정책이 필수 설정을 강제한다(예: S3 버킷은 버전 관리를 반드시 사용).
   • 개발자는 비준수 리소스를 만들 수 없으며, 플랫폼이 요청을 거부한다.

2. 자동 스캔 및 강제 적용

   • CI 파이프라인이 컨테이너 이미지 스캔을 자동으로 실행한다.
   • 어드미션 컨트롤러가 비준수 이미지를 클러스터에 배포되기 전에 차단한다.
   • 개발자는 취약 이미지가 거부될 것만 알면 되고, 스캔이 어떻게 동작하는지는 몰라도 된다.

3. 셀프‑힐링 수정

   • 베이스 이미지 취약점이 발견되면 플랫폼이 자동으로 PR을 생성해 업그레이드한다.
   • 런타임 보안 도구가 알림만 보내는 것이 아니라, 문제를 일으키는 파드/노드를 자동으로 종료하거나 격리한다.

4. 명확한 비즈니스 시그널링

   • 초기 단계부터 보안과 개발이 비용, 위험, 노력에 대해 하나된 입장을 제시한다.
   • “보안 비용”은 플랫폼에 내재화되어, 사후에 추가되는 생각이 아니다.

기대 효과

• 저항 최소 경로: 보안 배포가 가장 쉬운 옵션이 된다.
• 인지 부하 감소: 개발자는 기능 구현에 집중하고, 보안 세부 사항에 신경 쓰지 않는다.
• 신속한 복구: 자동 PR과 런타임 액션이 수동 지연을 없앤다.
• 공유 책임: 플랫폼 엔지니어와 개발자가 비즈니스가 요구하는 속도로 함께 움직인다.

“Shift‑Left” 유지 시 위험

• 개발자 번아웃 – 보안 작업을 기능 작업 위에 쌓아 놓는다.
• 제어 우회 – 과부하된 팀이 방어 장치를 무시하거나 우회할 수 있다.
• 사고 증가 – 수동 단계는 오류가 발생하기 쉽고, 해결이 늦어진다.

결론

Shift down은 보안을 개발자의 IDE에서 인프라 계층으로 옮겨, 전문 플랫폼 엔지니어링 팀이 관리하도록 하는 것이다. 보안 기본값 제공, 자동 강제 적용, 셀프‑힐링 메커니즘을 통해 보안을 가장 낮은 저항의 경로로 만들고, 비즈니스를 안전하게 전진시킨다.

Sponsored and written by Qualys.