shell-scripting

Contagious Interview IDE 공격을 탐지하고 방지하는 방법 (새 탭에서 열림)

Contagious Interview 캠페인은 가짜 채용 과제로 피해자가 악성 저장소를 VS Code에서 열고, `tasks.json`을 통해 악성 명령을 실행하도록 유도한다. 글은 VS Code 자체보다 운영체제에 가까운 `node-pty`의 `spawn-helper` 실행을 탐지하는 EDR 규칙과, IDE 작업 자동 실행을 비활성화하는 하드닝을 함께 적용해야 한다고 주장한다. 이를 통해 인포스틸러 설치와 기업 네트워크 접근 권한 탈취를 실행 전에 차단할 수 있다. ## Contagious Interview 공격의 진입 방식 - 공격자는 가짜 면접·코드 리뷰를 미끼로 피해자에게 악성 코드 저장소를 다운로드하고 VS Code에서 열도록 유도한다. - 저장소의 `.vscode/tasks.json`에는 프로젝트를 열 때 자동 실행되는 작업이 정의될 수 있다. - VS Code는 해당 저장소를 신뢰하도록 승인해야 작업을 실행하지만, 피해자는 면접 과정이라고 믿어 무심코 신뢰를 부여할 가능성이 높다. - 악성 작업은 `runOn: "folderOpen"`을 사용해 폴더를 열 때 자동 실행되며, 화면에 거의 표시되지 않도록 설정할 수 있다. - 예시 명령은 운영체제별로 다음 단계 악성코드를 내려받아 실행한다. - macOS: `curl ... | bash` - Linux: `wget ... | sh` - Windows: `curl ... | cmd` - 이후 인포스틸러가 비밀번호와 암호화폐 정보를 탈취하고, 지속성을 확보해 피해자의 기업 네트워크 접근 권한을 악용할 수 있다. ## IDE보다 낮은 계층을 겨냥한 탐지 - 특정 VS Code 기능만 탐지하면 VS Code 포크나 유사한 Node/Electron 기반 IDE를 우회 경로로 사용할 수 있다. - GitLab은 운영체제에 더 가까운 프로세스 생성 계층을 조사했다. - VS Code는 하위 프로세스를 실행할 때 널리 사용되는 `node-pty` 라이브러리를 활용한다. - `node-pty.spawn()` 호출은 자체 바이너리인 `spawn-helper`를 실행하며, 이 프로세스는 Node 애플리케이션의 자식 프로세스로 생성된다. - `node-pty`는 주당 다운로드 수가 100만 회 이상인 널리 사용되는 라이브러리이므로, 이 계층을 이용하면 특정 IDE에 종속되지 않는 탐지가 가능하다. ## 백그라운드 실행과 사용자 실행의 구분 - GitLab은 Purple Team 훈련으로 공격 경로를 재현한 뒤 EDR 텔레메트리를 분석했다. - VS Code에서 백그라운드 작업을 실행할 때는 주로 `spawn-helper`가 호출된다. - 사용자가 통합 터미널을 열거나 직접 프로세스를 실행하는 등 전면적인 상호작용이 있을 때는 `Code Helper` 바이너리가 사용된다. - 따라서 `spawn-helper`를 기반으로 탐지하면 사용자가 인지하지 못한 상태에서 실행되는 IDE 작업에 집중할 수 있다. - 일반적인 개발 활동에서 발생하는 의도적 프로세스 실행을 제외해 오탐을 줄일 수 있다. ## `curl | shell` 패턴과 행위 기반 튜닝 - `curl | bash`는 Homebrew 설치처럼 정상적인 용도로도 사용될 수 있으므로 단순 문자열 탐지는 오탐 가능성이 있다. - 하지만 사용자가 인지하지 못하는 백그라운드 작업에서 해당 명령이 실행되는 것은 조직 환경에서 비정상적일 수 있다. - GitLab은 다음과 같은 조건을 결합해 탐지 규칙을 조정했다. - 부모 프로세스가 IDE의 `spawn-helper`인지 - 작업이 백그라운드에서 실행됐는지 - 외부 URL에서 데이터를 내려받는지 - 다운로드한 내용을 셸로 직접 파이프하는지 - 이 방식은 모든 백그라운드 작업을 차단하지 않고, 드물고 위험한 실행 조합만 경고하도록 설계됐다. - 조직 내 많은 개발자가 매일 VS Code를 사용했음에도 구현 후 오탐이 발생하지 않았다고 설명한다. ## 다층 방어와 IDE 설정 강화 - EDR을 이용한 런타임 탐지는 악성 작업이 실제로 실행되는 순간을 포착하는 방어선이다. - 동시에 조직 전체 설정을 배포해 VS Code의 작업 자동 실행 자체를 비활성화하면 공격 표면을 줄일 수 있다. - 특히 저장소를 열 때 자동으로 실행되는 작업을 제한하면 `runOn: "folderOpen"` 기반 공격을 예방하는 데 효과적이다. - VS Code뿐 아니라 동일한 Node 기반 구조와 백그라운드 작업 기능을 가진 IDE 포크에도 같은 원칙을 적용해야 한다. 실무적으로는 IDE 작업 자동 실행을 기본 비활성화하고, EDR에서 `spawn-helper`의 백그라운드 프로세스 생성과 `curl/wget | shell` 패턴을 함께 모니터링하는 방식을 권장한다. Gmail·채용 플랫폼 등 초기 유입 경로에 대한 보안 교육과 저장소 신뢰 승인 절차도 병행해야 한다.

AI가 개발자의 선택을 (새 탭에서 열림)

AI는 단순히 코딩 속도를 높이는 도구를 넘어, 개발자가 선택하는 언어·프레임워크·도구 자체를 바꾸고 있다. GitHub의 Octoverse 2025 데이터에 따르면 TypeScript가 2025년 처음으로 Python과 JavaScript를 제치고 가장 많이 사용된 언어가 되었으며, 이는 AI가 복잡한 기술의 사용 장벽을 낮춘 결과로 해석된다. 따라서 조직은 AI의 생산성 향상뿐 아니라, AI가 증폭하는 아키텍처 품질과 기술 선택의 변화까지 관리해야 한다. ## 편의성이 개발자 선택을 바꾸는 과정 개발자는 사용하기 쉽고 마찰이 적은 기술을 반복적으로 선택하며, 이러한 선택이 생태계 전체의 흐름을 바꾼다. - 작업이 편리했던 경험은 기억에 남아 이후의 기술 선택에 영향을 준다. - GitHub 신규 개발자의 **80%가 첫 주 안에 Copilot을 사용**한다. - AI가 보일러플레이트와 문법 오류를 처리하면서, 복잡한 언어를 선택할 때의 비용이 감소했다. - 개발자는 “배우기 쉬운 기술”보다 “목적에 가장 적합하고 AI가 잘 지원하는 기술”을 선택하게 된다. ## TypeScript와 AI 친화적 기술의 성장 Octoverse 데이터는 AI가 실제 기술 채택에 영향을 주고 있음을 보여준다. - 2025년 8월, TypeScript가 GitHub에서 가장 많이 사용되는 언어가 되었다. - TypeScript 사용량은 전년 대비 **66% 증가**했다. - JavaScript 사용량은 **24% 증가**했다. - AI가 생성한 프로젝트에서 Shell 스크립트 사용량은 **206% 증가**했다. - 이는 개발자들이 Bash를 갑자기 선호하게 되었다기보다, AI가 Shell 사용의 문법적·인지적 부담을 줄였기 때문으로 볼 수 있다. ## 강한 타입 시스템이 AI 코드 생성에 유리한 이유 AI는 가능한 코드의 범위가 명확할수록 더 안정적인 결과를 생성할 수 있다. - JavaScript에서는 변수의 타입이 상황에 따라 무엇이든 될 수 있다. - TypeScript에서 `x: string`처럼 타입을 선언하면 문자열이 아닌 연산을 배제할 수 있다. - 이런 제약은 AI가 생성할 수 있는 코드의 공간을 줄이고, 문맥에 맞는 코드를 만들 가능성을 높인다. - 타입 검사는 오류를 줄이는 강력한 안전장치지만, 비즈니스 로직의 정확성까지 보장하지는 않는다. - GitHub의 공개 저장소 중 **110만 개 이상이 LLM SDK를 사용**하고 있어, 생성형 AI 연동은 실험 단계를 넘어 주류가 되었다. ## 빠른 개발과 아키텍처 품질의 균형 AI는 생산성을 크게 높이지만, 잘못된 설계도 더 빠르게 확산시킬 수 있다. - AI는 기존에 정립된 패턴을 따르는 데 강하고, 좋은 구조를 처음부터 설계하는 데는 상대적으로 약하다. - 초기 API 엔드포인트나 컴포넌트를 명확한 구조로 작성하면 이후 생성되는 코드도 그 패턴을 따를 가능성이 높다. - 반대로 불안정한 구조를 먼저 만들면 AI가 이를 반복·확장해 기술 부채를 키울 수 있다. - AI 지원 개발로 처리량이 **20~30% 증가**할 수 있지만, 그만큼 아키텍처의 일관성이 빠르게 무너질 위험도 커진다. ## 개발자와 팀을 위한 실천 방법 - **생성 전에 패턴을 정한다.** API, 컴포넌트, 디렉터리 구조, 오류 처리 방식 등을 먼저 정의한다. - **타입 시스템을 가드레일로 활용한다.** 타입 통과를 완전한 정합성의 증거로 간주하지 않는다. - **AI 생성 코드를 더 엄격하게 테스트한다.** 코드가 자연스럽고 초기 검사를 통과하더라도 테스트와 리뷰를 생략하지 않는다. - **템플릿과 문서를 표준화한다.** AI가 참고할 수 있도록 템플릿 저장소와 명시적인 아키텍처 결정을 제공한다. ## 엔지니어링 리더가 관리해야 할 지표 AI 도입의 성공 여부는 단순한 코드 생성량이나 자동완성 수락률만으로 판단하기 어렵다. - Copilot 사용 지표를 통해 일·주간 활성 사용자, 에이전트 사용률, 추가·삭제된 코드 라인, 언어·모델별 사용 패턴을 확인한다. - 에이전트 사용률은 높은데 특정 팀의 결함이 증가한다면 프롬프트 교육이나 코드 리뷰 기준을 강화해야 한다. - 특정 언어나 모델에서 결함률이 높다면 해당 기술 선택과 사용 방식을 재검토할 수 있다. - Copilot API를 이용하면 사용자 단위 데이터를 기반으로 조직에 맞는 대시보드를 구축할 수 있다. - 개발 속도가 빨라질수록 시니어 엔지니어의 아키텍처 검토와 품질 관리 역량은 더욱 중요해진다. AI를 도입할 때는 “얼마나 많은 코드를 만들었는가”보다 “어떤 구조와 품질의 코드를 만들었는가”를 관리해야 한다. TypeScript 같은 강한 제약의 도구와 명확한 개발 패턴을 기반으로 AI를 활용하고, 테스트·리뷰·품질 지표를 함께 운영하는 것이 실용적인 접근이다.