상용 기성품 소프트웨어
더 많은 작업
- Commercial Off-The-Shelf Software; COTS, 상용 소프트웨어, 기성 상용 제품
- 특정 고객을 위해 새로 만든 것이 아니라 이미 완성되어 일반에 판매·임대·라이선스되는 상용 소프트웨어 제품
NIST 용어집은 COTS를 '상업적으로 이미 만들어져 일반 대중에게 판매, 임대, 라이선스할 수 있는 소프트웨어·하드웨어 제품'으로 정의한다. 운영체제, 사무용 소프트웨어, 데이터베이스 관리 시스템, 백신, 상용 ERP 패키지 등이 대표적이다. 직접 개발보다 빠르고 싸며 검증된 기능을 쓸 수 있지만, 조직은 코드를 보지 못하고 설계를 바꾸지 못하는 제품의 보안 위험을 떠안게 된다.
CISSP 출제 기준 8.4 '도입한 소프트웨어의 보안 영향을 평가한다'는 COTS, 오픈소스, 제3자, 관리형 서비스(예: 기업용 애플리케이션), 클라우드 서비스(SaaS, IaaS, PaaS)를 평가 대상으로 나열한다. 일부를 고객 요구에 맞게 수정한 상용 제품은 MOTS(modified off-the-shelf)라 부르기도 한다.
COTS 평가는 '제품'과 '공급자'를 함께 본다. 미국 CISA의 『Secure by Demand Guide』는 구매 조직이 공급자의 사내 보안(enterprise security)만이 아니라 공급자가 고객에게 내놓는 제품의 보안(product security)을 물어야 한다고 강조한다.
| 평가 항목 | 확인할 내용 |
|---|---|
| 공급자 보안 성숙도 | 보안 개발 절차(예: NIST SSDF 준수 여부), 보안 조직과 책임자, 취약점 공개 정책과 대응 기록, 과거 사고 이력, 재무 안정성 |
| 제3자 인증·평가 | 정보보호시스템 공통평가기준(CC, ISO/IEC 15408) 인증과 평가 보증 등급·보호 프로파일, 암호 모듈 검증, 공공 도입 시 국가별 보안 적합성 검증 제도,SOC 보고서, 클라우드라면 클라우드 보안인증제나 FedRAMP |
| 패치·지원 정책 | 보안 업데이트 주기와 긴급 패치 절차, 지원 종료 일정(제품 지원 종료), 패치 배포 채널의 무결성(서명) |
| SBOM 요구 | 제품에 포함된 오픈소스·제3자 구성 요소 목록(SBOM)을 받아, 새 취약점이 공개될 때 영향 여부를 바로 판단할 수 있게 한다. |
| 기본 설정과 강화 | 기본 계정·기본 비밀번호 유무, 불필요한 서비스, 로그 기능, 다중 인증·SSO 지원. 도입 전에 조직의 보안 기준선에 맞춘 설정 강화(하드닝) 가이드를 받는다. |
| 데이터 처리 | 수집·저장·전송하는 데이터, 원격 진단·텔레메트리 기능, 데이터 저장 위치 |
| 통합 위험 | 기존 시스템과의 연동 방식, 필요한 권한과 네트워크 포트, 서비스 계정 권한 |
평가는 도입 전에 끝나지 않는다. 운영 중 패치 적용, 설정 변경 감시, 공급자 보안 공지 모니터링, 재평가를 공급망 위험 관리의 일부로 계속한다. NIST SP 800-161 Rev. 1은 이런 공급망 위험 관리를 조직 전체 위험 관리에 통합하는 방법을 다룬다.
- 코드 검증 불가: SAST나 코드 리뷰를 할 수 없어 숨은 기능, 백도어, 취약한 코드를 직접 확인하지 못한다. 공급자의 증빙과 제3자 평가에 의존한다.
- 수정 불가: 취약점이 발견되어도 조직이 직접 고칠 수 없고 공급자 패치를 기다려야 한다. 그동안은 웹 방화벽, 네트워크 분리, 기능 비활성화 같은 보완 통제를 쓴다.
- 블랙박스 시험: 조직이 할 수 있는 것은 DAST, 퍼징, 설정 점검, 네트워크 트래픽 분석 정도이다. 라이선스가 역공학을 금지하는 경우도 많아 계약 조건을 확인해야 한다.
- 공급자 종속: 공급자가 지원을 끝내거나 사업을 접으면 보안 업데이트가 끊긴다.
소스코드 기탁(source code escrow)은 공급자의 소스 코드와 빌드 자료를 독립된 제3자 기탁 기관에 맡겨 두고, 계약에서 정한 사건(공급자 파산, 사업 중단, 유지보수 의무 불이행 등)이 생기면 고객이 소스를 받을 수 있게 하는 계약 장치이다.
- 목적은 공급자 소멸에 대비한 가용성·연속성 확보이다. 평상시 보안 검증 수단은 아니다.
- 기탁물이 최신 버전과 일치하는지, 실제로 빌드 가능한지 검증하는 조항(검증 기탁)을 두지 않으면 정작 필요할 때 쓸모가 없다.
- 기탁 기관, 기탁 범위(소스, 빌드 스크립트, 문서, 제3자 구성 요소 목록), 갱신 주기, 해제 조건을 계약에 명시한다. 일반적인 제3자 보관 개념은 에스크로 문서를 참고한다.
| 유형 | 조직의 통제 수준 | 소스 접근 | 주요 평가 방법 | 주요 위험 |
|---|---|---|---|---|
| COTS | 낮음(설정만 가능) | 불가 | 공급자 평가, CC 등 인증, SBOM, 블랙박스 시험, 설정 강화 | 패치 의존, 숨은 기능, 지원 종료 |
| 오픈소스(오픈소스 소프트웨어) | 높음(수정 가능) | 가능 | SCA, 코드 리뷰·SAST, 커뮤니티 활동성과 유지관리 상태, 라이선스 검토 | 유지관리자 부족, 악성 패키지, 라이선스 의무, 공식 지원 부재 |
| 제3자 개발(외주·맞춤형) | 계약으로 정함 | 계약에 따라 가능 | 계약 보안 요구, 산출물 코드 검토, 개발 절차 감사, 인수 시험 | 개발사 보안 역량, 지식재산 귀속, 유지보수 연속성 |
| 관리형 서비스(기업용 애플리케이션 운영 위탁) | 낮음~중간 | 보통 불가 | SLA, SOC 보고서, 감사 권한, 접근 통제 검토 | 위탁 업체 직원의 특권 접근, 데이터 위치, 종료 시 이전 |
| 클라우드 SaaS | 가장 낮음(애플리케이션 설정과 데이터, 사용자 관리) | 불가 | 보안 인증, SOC 보고서, 계약상 책임 분담, CASB | 설정 오류, 데이터 위치·주권, 공급자 침해 |
| 클라우드 PaaS | 중간(애플리케이션과 데이터) | 플랫폼은 불가 | 책임 분담 확인, 플랫폼 보안 기능 검토 | 플랫폼 종속, 권한 설정 오류 |
| 클라우드 IaaS | 높음(운영체제부터 위) | 인프라는 불가 | 책임 분담 확인, 이미지·네트워크 설정 점검 | 고객 측 설정 오류와 패치 누락 |
클라우드는 서비스 모델에 따라 고객과 공급자의 책임 경계가 달라진다. 자세한 내용은 클라우드 서비스 모델과 클라우드 보안 참고.
보안 요구는 계약서에 들어가야 강제할 수 있다.
- 보안 개발 절차 준수와 증빙 제출(보안 개발 프레임워크 자기 증명 등)
- 취약점 통지 기한과 패치 제공 기한, 지원 기간 보장
- SBOM 제공과 갱신 의무
- 보안 사고 통지 의무와 통지 기한, 협조 의무
- 감사권 또는 제3자 감사 보고서 제공 의무
- 데이터 처리 위치, 반환·파기 조건, 개인정보 처리 위탁 조항
- 하위 공급자 사용 시 동일 의무 전가
- 소스코드 기탁 조건과 해제 사유
- 책임 제한, 손해배상, 보험
- COTS의 근본 한계는 소스를 보거나 고칠 수 없다는 것이다. 따라서 평가는 공급자 평가, 독립 인증, 블랙박스 시험, 설정 강화로 한다.
- 소스코드 기탁은 공급자 파산·지원 중단에 대비한 연속성 통제이다. 보안 취약점 점검 수단으로 고르는 것은 오답이다.
- 도입 전 보안 요구는 계약 단계에서 넣어야 한다. 계약 후에는 요구할 근거가 없다.
- 공통평가기준(CC) 인증은 평가된 설정과 범위에서의 보증이다. 조직이 설정을 바꾸면 그 보증이 그대로 적용되지 않는다.
- 클라우드 서비스는 IaaS → PaaS → SaaS로 갈수록 고객의 통제 범위가 줄고 공급자 평가 의존이 커진다.
- Glossary: commercial off-the-shelf (COTS) – NIST CSRC
- NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations – NIST
- Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem – CISA
- Common Criteria Portal – Common Criteria Recognition Arrangement
- Software Bill of Materials (SBOM) – CISA