개발 환경 보안
더 많은 작업
- Software Development Ecosystem Security; 소프트웨어 개발 생태계 보안, 개발환경 보안
- 소프트웨어를 만드는 데 쓰는 언어, 라이브러리, 도구, IDE, 런타임, CI/CD 파이프라인, 형상 관리, 코드 저장소 자체를 보호해 결과물의 무결성과 기밀성을 지키는 보안 통제
애플리케이션 코드가 아무리 안전해도 그 코드를 만들고 빌드하고 배포하는 환경이 뚫리면 공격자는 정상 배포 경로로 악성 코드를 내보낼 수 있다. 빌드 서버나 패키지 저장소를 노린 공급망 공격이 늘면서 개발 환경은 운영 환경과 같은 수준으로 보호해야 하는 대상이 되었다. CISSP 출제 기준 8.2 '소프트웨어 개발 생태계의 보안 통제를 찾아 적용한다'는 프로그래밍 언어, 라이브러리, 도구 모음, 통합 개발 환경(IDE), 런타임, CI/CD, 소프트웨어 형상 관리, 코드 저장소, 애플리케이션 보안 테스트를 나열한다. 이 문서는 마지막 항목을 제외한 생태계 요소를 다루고, 보안 테스트는 애플리케이션 보안 테스트 문서에서 다룬다.
NIST SP 800-218(SSDF)은 이 영역을 'PS(Protect the Software)' 실무 그룹, 즉 소프트웨어의 모든 구성 요소를 변조와 무단 접근에서 보호하는 활동으로 묶는다.
| 요소 | 주요 위험 | 통제 |
|---|---|---|
| 프로그래밍 언어 | 메모리 비안전 언어(C, C++)의 버퍼 오버플로·해제 후 사용, 약한 타입 검사로 인한 형 변환 오류 | 메모리 안전 언어 채택, 컴파일러 보안 옵션, 언어별 시큐어 코딩 표준 |
| 라이브러리·의존성 | 알려진 취약점이 있는 구성 요소, 타이포스쿼팅, 의존성 혼동, 유지관리자 계정 탈취 | SCA, SBOM, 버전 고정과 잠금 파일, 사내 프록시 저장소, 허용 목록 |
| 도구 모음·IDE | 악성 플러그인·확장, 개발자 PC 악성코드, AI 코드 도우미의 환각 패키지와 취약 코드 제안 | 승인된 확장만 허용, 개발 단말 엔드포인트 보안, AI 산출물 검증 |
| 런타임 | 과도한 실행 권한, 인터프리터·가상 머신 취약점, 컨테이너 탈출 | 샌드박스, 최소 권한 실행, 런타임 패치, 컨테이너 보안 설정 |
| CI/CD 파이프라인 | 파이프라인 오염 실행, 러너 장악, 비밀 유출, 산출물 변조 | 러너 격리, 비밀 관리, 서명과 출처 증명, SLSA |
| 소프트웨어 형상 관리 | 승인되지 않은 변경, 기준선 불일치, 추적 불가 | 기준선 관리, 변경 통제, 감사 기록 |
| 코드 저장소 | 무단 접근, 검토 없는 병합, 비밀 커밋, 공개 설정 실수 | 브랜치 보호, 서명 커밋, 비밀 탐지, 접근 통제 |
- 메모리 안전성: C와 C++는 메모리를 개발자가 직접 관리하므로 버퍼 오버플로, Use After Free 같은 메모리 안전 취약점이 생기기 쉽다. 미국 CISA는 『The Case for Memory Safe Roadmaps』에서 소프트웨어 제조사가 메모리 안전 언어(MSL)로 옮겨 이 취약점 부류를 없애고, 그 계획(로드맵)을 공개하라고 권고한다. Rust, Go, 자바, 파이썬 등이 메모리 안전 언어의 예로 거론된다. 다만 같은 문서는 Rust의
unsafe키워드처럼 메모리 보호를 스스로 해제하는 기능도 있으므로 그런 코드는 따로 검토해야 한다고 지적한다. - 타입 안전성: 강한 타입 시스템은 잘못된 형 변환이나 의도하지 않은 데이터 해석을 컴파일 단계에서 막는다. 동적 타입 언어는 입력 검증과 테스트에 더 의존한다.
- 실행 방식: 컴파일 언어는 배포 전 정적 검사 기회가 많고, 인터프리터 언어는 소스가 그대로 배포되어 코드 노출과 런타임 주입 위험을 따로 관리해야 한다.
- 위험한 기능:
eval같은 동적 코드 실행, 안전하지 않은 역직렬화, 경계 검사 없는 문자열 함수는 언어별 금지 목록으로 관리한다.
현대 애플리케이션 코드의 상당 부분은 직접 작성하지 않은 오픈소스 구성 요소이다. OWASP CI/CD 10대 보안 위험의 CICD-SEC-3(의존성 사슬 남용)은 다음 공격을 든다.
| 공격 | 설명 | 대응 |
|---|---|---|
| 의존성 혼동(dependency confusion) | 사내 전용 패키지와 같은 이름의 악성 패키지를 공개 저장소에 올려, 패키지 관리자가 공개본을 받아 오게 만든다. | 사내 패키지 이름 공간(scope) 예약, 사내 저장소 우선 설정, 공개 저장소 직접 접근 차단 |
| 의존성 탈취(dependency hijacking) | 인기 패키지 유지관리자 계정을 탈취해 악성 새 버전을 올린다. | 버전 고정과 해시 검증, 새 버전 도입 전 검토, 자동 갱신 지연 |
| 타이포스쿼팅(typosquatting) | 인기 패키지와 철자가 비슷한 이름으로 악성 패키지를 올려 오타를 노린다. | 허용 목록, 사내 프록시 저장소, 패키지 평판 확인 |
| 브랜드재킹(brandjacking) | 특정 브랜드의 명명 규칙을 흉내 내 신뢰를 얻는다. | 출처와 게시자 확인 |
알려진 취약점은 SCA 도구와 SBOM으로 관리하고, 지원이 끝난 구성 요소는 제품 지원 종료 관점에서 교체 계획을 세운다.
- 플러그인·확장: IDE 확장은 개발자 권한으로 소스 코드, 자격 증명, 터미널에 접근한다. 조직이 승인한 확장 목록을 운영하고 게시자를 확인한다.
- 개발자 단말: 저장소 토큰, 클라우드 키, 서명 키가 모이는 고가치 대상이다. 디스크 암호화, EDR, 다중 인증, 비밀을 평문 파일로 두지 않는 습관이 필요하다.
- AI 코드 도우미: 존재하지 않는 패키지 이름을 그럴듯하게 제안하는 환각은 공격자가 그 이름을 선점하는 공급망 위험이 된다. 또 학습 데이터의 취약한 코드 패턴을 재생산할 수 있다. AI가 만든 코드도 사람 코드와 같은 리뷰, SAST, SCA를 거치게 하고, 사내 코드와 비밀이 외부 AI 서비스로 전송되는 범위를 정책으로 정한다. 프롬프트 주입을 통해 코드 에이전트가 악성 명령을 실행하게 만드는 공격도 고려한다.
- 빌드 도구 자체: 컴파일러나 빌드 스크립트가 변조되면 소스가 깨끗해도 결과물이 오염된다. 도구도 검증된 출처에서 받고 버전을 고정한다.
소스가 저장소에 들어가 형상 관리 아래 버전이 붙고 파이프라인을 거쳐 배포되기까지의 경로 전체가 보호 대상이다.
CI/CD 파이프라인은 소스에서 운영까지 가는 자동화 경로이므로 운영 환경에 쓰기 권한을 가진 시스템으로 취급해야 한다. NIST SP 800-204D는 CI/CD 파이프라인에 소프트웨어 공급망 보안을 통합하는 전략을 다룬다. OWASP CI/CD 10대 보안 위험은 다음과 같다.
| 번호 | 위험 | 요지 |
|---|---|---|
| CICD-SEC-1 | 불충분한 흐름 통제 | 검토·승인 없이 코드가 운영까지 갈 수 있음 |
| CICD-SEC-2 | 부적절한 신원·접근 관리 | 과도한 권한, 퇴사자·미사용 계정 |
| CICD-SEC-3 | 의존성 사슬 남용 | 의존성 혼동, 타이포스쿼팅 등 |
| CICD-SEC-4 | 오염된 파이프라인 실행(PPE) | 저장소의 빌드 설정·스크립트를 조작해 파이프라인에서 악성 명령 실행 |
| CICD-SEC-5 | 불충분한 파이프라인 기반 접근 통제(PBAC) | 파이프라인 작업이 필요 이상의 자원에 접근 |
| CICD-SEC-6 | 부실한 자격 증명 관리 | 코드·로그·환경 변수에 노출된 비밀 |
| CICD-SEC-7 | 안전하지 않은 시스템 설정 | 빌드 서버·러너의 취약 설정과 미패치 |
| CICD-SEC-8 | 통제되지 않은 제3자 서비스 사용 | 저장소·파이프라인에 연결된 외부 앱의 과도한 권한 |
| CICD-SEC-9 | 부적절한 산출물 무결성 검증 | 서명·출처 검증 없이 산출물 배포 |
| CICD-SEC-10 | 불충분한 로깅과 가시성 | 파이프라인 활동을 추적·탐지할 수 없음 |
주요 통제는 다음과 같다.
- 러너 격리: 빌드마다 새로 만들고 버리는 일회용 러너를 쓰고, 신뢰 수준이 다른 작업(외부 기여자의 풀 요청 빌드와 운영 배포)은 다른 러너에서 돌린다.
- 비밀 관리: 비밀은 저장소가 아니라 비밀 관리 시스템(금고)에 두고 작업 실행 시 짧은 수명 토큰으로 주입한다. 로그에 비밀이 찍히지 않게 가린다. 가능하면 클라우드 접근은 고정 키 대신 워크로드 신원 연동을 쓴다.
- 파이프라인 정의 보호: 파이프라인 설정 파일 변경도 코드 리뷰와 승인을 거치게 한다.
- 서명과 출처 증명: 빌드 산출물과 컨테이너 이미지에 서명하고, 어떤 소스와 빌드 환경에서 만들어졌는지 출처 증명(provenance)을 남긴다. 배포 단계에서 서명과 출처를 검증한 것만 허용한다.
- SLSA(Supply-chain Levels for Software Artifacts): 소프트웨어 산출물의 공급망 무결성 수준을 단계로 정의한 프레임워크이다. 1.0판 빌드 트랙은 L0(보장 없음), L1(출처 증명 존재), L2(호스팅 빌드 플랫폼), L3(강화된 빌드)로 나뉘며, 현행 1.2판은 소스 트랙도 함께 정의한다.
소프트웨어 형상 관리(SCM, software configuration management)는 소스, 설정, 빌드 스크립트, 문서, 산출물의 버전과 기준선을 식별하고 변경을 통제·기록하는 활동이다. 자세한 일반론은 형상 관리 문서를 본다.
- 형상 식별: 무엇을 관리 대상으로 삼을지 정하고 고유 식별자를 붙인다.
- 기준선(baseline): 승인된 시점의 구성을 고정해 이후 변경을 비교하는 기준으로 쓴다.
- 변경 통제: 변경 요청, 영향 분석, 승인, 반영의 절차를 거친다(변경 관리).
- 형상 감사와 상태 기록: 배포된 것이 승인된 기준선과 같은지 확인하고 변경 이력을 남긴다.
보안 관점에서 형상 관리는 '운영에 있는 코드가 검토·승인된 바로 그 코드인가'를 증명하는 수단이다. 침해 조사 시 변경 이력은 디지털 증거가 된다.
코드 저장소는 조직의 지식재산이자 공급망의 시작점이다. 공개 저장소로 잘못 설정하거나 비밀을 커밋하는 사고가 흔하다.
| 통제 | 내용 |
|---|---|
| 접근 통제 | 다중 인증, SSO 연동, 저장소별 최소 권한 원칙, 정기 접근 권한 검토, 퇴사자 즉시 회수. 개인 접근 토큰은 범위와 만료를 둔다. |
| 브랜치 보호 | 주요 브랜치에 직접 푸시 금지, 병합 전 리뷰어 승인 필수, 상태 검사(빌드·테스트·보안 검사) 통과 필수, 강제 푸시와 이력 삭제 금지. 작성자 혼자 승인할 수 없게 해 직무 분리를 구현한다. |
| 서명 커밋 | GPG·SSH 키나 인증서로 커밋과 태그에 서명해 작성자를 검증한다. 서명 없는 커밋의 병합을 막을 수 있다. |
| 비밀 유출 탐지 | 커밋 전 훅과 서버 측 검사로 키·토큰·비밀번호를 탐지하고, 푸시 자체를 막는다. 이미 커밋된 비밀은 이력에서 지우는 것만으로 부족하므로 즉시 폐기하고 재발급한다. |
| 공개 범위 관리 | 저장소 기본값을 비공개로 두고, 공개 전환은 승인 절차를 거친다. 포크와 외부 협업자 권한을 관리한다. |
| 로깅과 백업 | 감사 로그를 SIEM으로 보내 대량 복제·권한 변경을 탐지하고, 저장소를 별도 백업한다. |
- 개발 환경과 빌드 파이프라인은 운영 환경과 같은 수준으로 보호한다. 빌드 서버 장악은 모든 고객에게 악성 코드를 배포하는 경로가 된다.
- 저장소에 비밀이 커밋되었다면 가장 먼저 그 비밀을 폐기·교체한다. 이력 삭제는 그다음 일이다.
- 브랜치 보호의 '작성자 외 리뷰어 승인'은 직무 분리를 코드 저장소에 적용한 것이다.
- 메모리 안전 언어는 버퍼 오버플로 같은 취약점 부류를 원천적으로 줄이는 예방 통제이다.
- 의존성 혼동과 타이포스쿼팅을 구분한다. 같은 이름(사내 패키지명 선점)은 의존성 혼동, 비슷한 이름(오타)은 타이포스쿼팅이다.