Netwrix 1Secure는 데이터와 아이덴티티 전반에 걸쳐 통합된 가시성을 제공합니다 - 14일간 무료로 전체 액세스가 가능합니다.무료 평가판 시작

리소스 센터블로그

CIS Control 16: 애플리케이션 소프트웨어 보안

CIS Control 16: 애플리케이션 소프트웨어 보안

Oct 12, 2025

현대적인 IT 환경에는 일반적으로 다양한 애플리케이션이 포함됩니다. 사내에서 개발한 소프트웨어, 호스팅되는 소프트웨어 플랫폼, 오픈소스 도구, 구매한 솔루션 등이 이에 해당합니다. 이러한 애플리케이션은 민감한 시스템, 데이터 및 기타 IT 자산에 접근하기 때문에 사이버 범죄자들은 공격 중 이를 악용하려고 합니다.

CIS Control 16은 조직의 보안 태세를 강화하기 위한 애플리케이션 소프트웨어 보안 통제를 제공합니다. 이 블로그 게시물에서는 이러한 CIS controls를 구현하면 코딩 실수, 취약한 인증, 안전하지 않은 설계, 안전하지 않은 인프라 및 공격자가 민감한 데이터와 시스템에 접근하기 위해 사용하는 기타 취약성으로 인한 위험을 줄이는 데 어떻게 도움이 되는지 설명합니다.

다음 사항을 참고하세요. CIS Critical Security Controls Version 8 이전에는 애플리케이션을 보안하는 방법에 대한 주제가 CIS Control 18에서 다뤄졌습니다.

16.1. 보안이 포함된 애플리케이션 개발 프로세스를 수립하고 유지한다

첫 번째 단계는 안전한 코딩 방식, 안전한 애플리케이션 설계 표준 및 절차, 그리고 제3자 코드의 보안을 모두 다루는 보안 애플리케이션 개발 프로세스를 수립하는 것입니다. 또한 개발 팀과 구현 그룹을 포함해 애플리케이션 라이프사이클에 관여하는 모든 사람에게 이 프로세스에 대한 교육을 제공해야 합니다. 목표는 모든 사람이 보안 관행을 이해하고 위험 노출을 최소화하기 위해 적극적으로 노력하는, 사이버보안 인식의 문화를 만드는 것입니다.

이러한 접근 방식은 업계 규정, 법적 의무 및 내부 거버넌스 요구사항에 대한 조직의 준수 수준도 향상시킬 것입니다.

16.2. 소프트웨어 취약점을 수용하고 대응하기 위한 프로세스를 수립하고 유지한다

또한 소프트웨어 취약점을 수용하고 대응하기 위한 강력한 취약점 관리 프로세스가 필요합니다. 정기적으로 위험 평가를 수행하여 네트워크 보안의 취약 지점을 파악하고, 팀 구성원이 사고 대응 중 발견되는 경우를 포함해 보안 이슈를 언제든지 쉽게 제출할 수 있도록 프로세스를 마련하세요.

취약점 보고서를 처리하고 수정(복구) 프로세스를 모니터링할 책임 역할을 반드시 지정하고, 취약점 추적 시스템에 투자하는 방안도 고려하세요.

16.3. 보안 취약성에 대해 근본 원인 분석을 수행한다

보안 취약성을 완화하려면 근본 원인 분석을 통해 근본적인 문제를 이해하는 것이 필수입니다. 특정 취약성을 해결하는 데 도움이 될 뿐 아니라, 근본 원인 분석은 보안 및 컴플라이언스 자세를 강화하는 안전한 구성 기준선(configuration baseline)을 정의하는 데도 도움이 됩니다.

16.4. 제3자 소프트웨어 구성요소의 목록을 수립하고 관리합니다

개발 과정에서 팀이 사용하는 구성요소와 향후 사용 예정인 구성요소를 포함해, 제3자 소프트웨어 구성요소의 목록을 작성합니다. 이러한 소프트웨어 구성요소가 앱에 야기할 수 있는 위험을 검토하고 문서화하며, 변경이나 업데이트가 발생하면 이를 식별하고 기록하여 목록을 적절히 관리하세요.

16.5. 최신이며 신뢰할 수 있는 제3자 소프트웨어 구성요소를 사용합니다

가능한 경우 검증된 신뢰할 수 있는 소프트웨어와 라이브러리를 사용합니다. 이러한 구성요소의 신뢰할 수 있는 출처를 찾고, 사용하기 전에 소프트웨어에 취약점이 있는지 평가하세요.

모든 제3자 소프트웨어 구성요소가 지속적인 개발자 지원을 제공하는지 확인합니다. 지원이 없는 구성요소는 비활성화하거나 제거하세요. 보안 업데이트를 계속해서 제공받는 소프트웨어 자산을 사용하면 위험 노출을 최소화하는 데 도움이 됩니다. 이러한 업데이트에는 반드시 신뢰할 수 있고 검증된 출처만 사용하세요. 물론, 시스템과 장치의 무결성을 유지하려면 업데이트를 적시에 설치해야 합니다.

16.6. 애플리케이션 취약점에 대한 심각도(Severity) 평가 시스템과 프로세스를 수립하고 유지합니다

애플리케이션 취약점의 심각도를 평가하면 위험 완화(복구) 작업의 우선순위를 정하는 데 도움이 됩니다. 전문가 팁: 평가 시스템을 설계할 때, 해당 애플리케이션과 취약점이 비즈니스 프로세스에 얼마나 중요한지(치명도)를 반드시 포함하세요. 또한 애플리케이션에 대해 최소 보안 허용 수준(minimum-security acceptability level)을 설정하는 것도 고려해 보십시오.

16.7. 애플리케이션 인프라에 표준 하드닝(hardening) 구성 템플릿을 사용합니다

업계에서 권장하는 템플릿을 사용해 서버, 데이터베이스, SaaS 및 PaaS 구성 요소를 설정하면 취약점을 완화하고 사이버 위생(cyber hygiene)을 개선하는 보안 구성을 확보하는 데 도움이 됩니다.

16.8. 운영(Production) 시스템과 비운영(Non-production) 시스템을 분리합니다

프로덕션 시스템과 개발 및 테스트에 사용되는 비(非)프로덕션 시스템을 위해 별도의 환경을 만들고 유지하세요. 승인되지 않은 인원이 프로덕션 환경에 접근하지 못하도록, 프로덕션 환경과의 모든 상호작용을 모니터링하십시오.

활동 모니터링 외에도, 효과적인 계정 관리로 IT 환경을 보호하세요. 사용자 계정에는 필요한 권한만 부여하고, 관리 권한은 최소화하십시오. 추가적인 데이터 보호 조치는 Microsoft Active Directory 환경에서 Group Policy 를 사용하여 구현할 수 있습니다.

16.9. 개발자를 애플리케이션 보안 개념과 안전한 코딩 방식에 대해 교육하세요

개발자는 안전한 코드를 작성하는 방법에 대한 교육이 필요합니다. 교육 세션은 해당 조직의 환경과 책임에 맞게 맞춤형으로 구성할 때 가장 효과적입니다. 교육에는 애플리케이션 보안 표준 모범 사례와 일반적인 보안 원칙을 포함하고, 보안 인식을 높이는 것을 목표로 해야 합니다. SANS Institute는 정보보안과 사이버보안에 대해 학습하기 위한 훌륭한 자료입니다.

안전한 코드를 작성하는 데 투자하면 취약점 탐지와 복구에 필요한 노력을 줄일 수 있어 비용을 절감할 수 있습니다.

16.10. 애플리케이션 아키텍처에 보안 설계 원칙을 적용

보안 설계 원칙에는 “사용자 입력을 절대 신뢰하지 말 것”이라는 지침이 포함되며, 모든 사용자 작업을 검증하고 명시적인 오류 검사를 수행하는 것을 의미합니다.

보안 설계에는 애플리케이션 인프라의 공격 표면을 최소화하는 것도 포함됩니다. 예를 들어 팀에서는 불필요한 프로그램을 제거하고, 기본 계정을 이름 변경하거나 제거하며, 보호되지 않은 서비스와 포트를 끌 수 있습니다.

16.11. 애플리케이션 보안 구성요소에는 검증된 모듈 또는 서비스를 활용

애플리케이션 보안 구성요소를 위한 검증된 모듈 또는 서비스는 Identity management, 암호화, 감사 및 로깅에 사용할 수 있습니다. 이를 사용하면 구현 및 설계 오류를 줄이고 개발자 업무량을 최소화할 수 있습니다.

예를 들어, 최신 운영 체제를 사용하면 애플리케이션의 효과적인 식별, 인증 및 권한 부여를 보장하는 데 도움이 될 뿐 아니라 안전한 감사 로그를 생성할 수 있습니다. 광범위하게 검토된 표준 암호화 알고리즘만 사용하면 시스템을 손상시킬 수 있는 결함의 위험을 줄일 수 있습니다.

16.12. 코드 수준의 보안 점검을 구현

정적 및 동적 분석 도구를 활용해 실수를 테스트함으로써 개발자가 안전한 코딩 방식을 준수하도록 보장하는 데 도움을 받으세요. 사용 가능한 도구를 조사하여 코드에 대해 효과적으로 작동할 수 있는 도구를 찾으십시오.

16.13. 애플리케이션 침투 테스트를 수행

침투 테스트는 코드 리뷰 및 자동화된 코드 스캐닝 과정에서 놓칠 수 있는 애플리케이션의 취약점을 발견하는 데 도움이 될 수 있습니다. CIS CSC 16의 이 구성 요소에서 수행하는 테스트의 목표는 인터넷 보안상의 공백을 포함한 약점을 식별하고, 애플리케이션 환경의 사이버 보안 회복력과 방어 메커니즘을 평가하는 것입니다.

침투 테스트의 효과는 테스터의 기술에 달려 있음을 유의하세요.

16.14. 위협 모델링을 수행합니다

위협 모델링에서는 코딩을 시작하기 전에, 보안 위험을 각 액세스 수준 또는 진입 지점 전반에 걸쳐 중점적으로 파악하도록 특별히 훈련된 개발자가 애플리케이션의 설계를 평가합니다. 애플리케이션, 아키텍처, 인프라를 구조적으로 매핑하면 약점을 더 잘 이해하여 사이버 방어를 개선하고 데이터가 무단 액세스, 절도 또는 파괴로부터 안전하게 보호되도록 할 수 있습니다.

공유하기

더 알아보기

저자 소개

Dirk schrader

Dirk Schrader

보안 연구 부문 VP

Dirk Schrader는 Netwrix의 레지던트 CISO(EMEA)이며 보안 연구 부문 VP입니다. CISSP (ISC²) 및 CISM (ISACA) 자격증을 보유한 IT 보안 분야 25년 경력의 베테랑으로, 사이버 위협에 대응하는 현대적 접근 방식으로서 사이버 복원력을 발전시키기 위해 노력하고 있습니다. Dirk는 커리어 초기에 기술 및 지원 역할에서 시작해, 이후 대규모 다국적 기업과 소규모 스타트업 모두에서 영업, 마케팅, 제품 관리 직무로 자리를 옮기며 전 세계의 사이버보안 프로젝트에 참여해 왔습니다. 그는 사이버 복원력을 달성하기 위해 변화 관리와 취약점 관리의 필요성을 다룬 수많은 글을 게재해 왔습니다.