2020.08.20

통계로 알아보는 애플리케이션 보안 현황

Lucian Constantin | CSO
지난 몇 년간 데브옵스(DevOps) 문화가 부상하면서 소프트웨어 개발에 큰 변화가 발생했고, 기업들이 새 기능과 혁신을 지원하는 데 필요한 인프라를 자동으로 축소, 또는 확장하고, 코드를 더 빨리 배포할 수 있게 되었다. 그리고 이제 개발과 운영 파이프라인에 보안을 통합시키는 데브섹옵스(DevSecOps)가 확대되면서 애플리케이션 보안에도 변화가 발생하고 있다. 그러나 업계의 새 보고서에 수록된 데이터는 여전히 ‘갭’이 존재한다는 점을 보여준다.


보안 테스트의 주체가 바뀌고 있다

ESG가 북미의 애플리케이션 개발자 및 애플리케이션 보안 담당자 378명을 조사해 발표한 새 보고서에 따르면, 많은 기관과 기업이 자신의 애플리케이션 보안 프로그램이 견고하다고 판단하고 있음에도 불구하고 알려진 취약점이 있는 코드를 계속 배포하고 있다.

취약한 코드를 배포하는 것을 결코 바람직한 일이 아니지만, 이에 대해 알고 배포하는 것이 모르고 배포하는 것보다는 낫다. 위험 평가, 문제점을 바로잡을 계획, 일시적인 경감 대책 아래 이런 결정을 내리는 경우가 많기 때문이다. 조사 대상의 약 절반이 소속 조직이 정기적으로 이렇게 하고 있다고 대답했다. 또 간헐적으로 이렇게 한다고 대답한 비율은 1/3이었다. 그 이유로는 ‘아주 중요한 일정 준수’, ‘취약점의 위험인 낮아’, ‘릴리스 주기에서 너무 늦게 문제점을 발견’이 가장 많이 언급됐다(45%).

이번 조사 결과는 가능한 개발 프로세스 초기에 보안 테스트를 통합시키는 것이 중요한 이유를 설명한다. 또한, 취약한 코드를 배포하는 것이 반드시 보안 프로그램이 견고하지 않다는 것을 알려주는 신호는 아니라는 점을 알려준다. 여러 이유에서 이런 일이 일어날 수 있고, 한 종류의 보안 테스트로는 모든 버그를 포착하기 불가능하기 때문이다. 

그러나 이 보고서는 여전히 애플리케이션 보안 프로그램을 확대하는 과정에 있는 조직들이 많다는 점도 알려준다. 구체적으로 코드 기반의 3/4 이상이 애플리케이션 보안 프로그램의 대상이라고 대답한 비율은 1/3에 불과했다. 그리고 1/3은 프로그램의 대상이 절반이 되지 않는다고 대답했다.
 
취약한 코드를 프로덕션 단계로 배포, 결정해 책임을 진 사람이나 부서는 기업에 따라 다른 것으로 조사됐다. 개발 담당 매니저가 보안 애널리스트와 함께 결정을 내리는 조직의 비율은 28%, 개발 담당 매니저나 보안 애널리스트가 단독으로 이런 결정을 내리는 비율은 각각 24%와 21%였다.

이는 애플리케이션 보안 프로그램이 성숙해지고 있음을 알리는 신호일 수 있다. 데브섹옵스는 보안 테스트를 가능한 개발 파이프라인의 앞으로 옮기는 것이 중요하기 때문이다. 과거에는 보안 팀이 결과물이 완성된 후 보안 테스트를 실시했었다.

보안 팀을 개발 프로세스에 통합시킨 결과로 개발 팀이 보안 테스트를 하고, 결과를 반영하는 기업의 경우, 개발 담당 매니저가 취약점을 수용할지 여부를 결정하는 경우가 많다. 이때 보안 팀과 협력하거나, 팀에 애플리케이션 보안에 대한 지식이 있고 트레이닝을 받은 개발자인 보안 '전문가'가 존재하는 경우, 기업 내부에서 협의해 단독으로 결정을 내린다. 

그러나 이 경우에도 궁극적으로 전사적인 정보 보안에 위험 관리 책임을 갖고 있고, 공격에 더 많이 노출될 수 있는 애플리케이션, 해커가 표적으로 삼을 수 있는 민감한 정보가 많은 애플리케이션을 판단할 수 있는 CISO가 적용한 정책을 기반으로 이런 결정을 내려야 한다. 이런 애플리케이션들은 패칭 등에 있어 더 엄격한 규칙이 적용될 수 있다.


보안 테스트 도구 사용시 당면 과제

위험을 정확히 평가하지 않으면, 알려진 취약점이 있는 코드를 배포했을 때 심각한 결과가 초래될 수 있다. 이와 관련, 지난 12개월 동안 OWASP의 10대 취약점 때문에 프로덕션 애플리케이션이 익스플로잇 당했다고 인정한 응답자의 비율이 60%에 달했다. 

OWASP의 10대 취약점에는 웹 애플리케이션에 초래되는 가장 중대한 보안 위험들이 포함되어 있다. ▲SQL 주입 ▲취약한 인증 ▲민감한 데이터 노출 ▲취약한 액세스 제어 ▲잘못된 보안 구성 ▲알려진 취약점이 존재하는 서드파티 구성요소 이용 등이 여기에 해당된다. 일반적으로 프로덕션 코드에 허용해서는 안되는 문제점들이다.

시장조사기관 ESG 보고서에 따르면, 기업들은 다양한 애플리케이션 보안 테스트 도구를 이용하고 있다. ASV(API security vulnerability) 도구 56%, 잘못된 구성에 대해 보호해주는 IaC(Infrastructure as Code) 보안 도구 40%, SAST(Static Application Security Testing) 도구 40%, SCA(Software Composition Analysis) 테스트 도구 38%, IAST(Interactive A\application security testing) 도구 38%, DAST(Dynamic Application Security Testing) 도구 36%, 보안 문제 파악과 해결에 도움을 주는 IDE(Integrated Development Environment) 플러그인 29%, 컨테이너와 리포지토리, 마이크로서비스에 사용되는 이미지 스캐닝 도구 29%, 퍼징(fuzzing) 도구 16%, 컨테이너 런타임 구성 보안 도구 15% 등이다.

응답자는 이런 도구를 사용할 때 직면하는 가장 큰 과제로 ▲파악한 문제를 경감시키는 지식 부족(29%) ▲개발자들이 회사가 투자한 도구를 효과적으로 사용하지 못하는 것(24%) ▲보안 테스트 도구들이 마찰을 초래하고 개발 주기를 지연시키는 문제(26%) ▲여러 공급업체의 애플리케이션 보안 도구들의 통합이 미흡한 문제(26%)를 꼽았다.

약 80%의 기관과 기업은 보안 애널리스트가 개발자와 직접 협력해 기능과 코드를 평가하고, 위협 모델링을 하고, 매일 개발 스크럼 미팅에 참여하고 있다고 응답했지만, 개발자들의 보안 트레이닝은 많지 않은 것으로 보인다. 개별 개발자나 개발 담당 매니저가 애플리케이션 보안 테스트를 책임지고 있다고 대답한 비율이 각각 19%와 26%에 불과한 이유가 여기에 있다. 이에 대한 책임을 전담 보안 애널리스트에 맡기고 있다고 대답한 비율, 개발 팀과 보안 팀이 공동 책임지고 있다고 대답한 비율은 각각 1/3과 29%였다.

1/3에 해당되는 기관과 기업은 공식 보안 훈련을 요구하는 개발자가 절반이 되지 않았다. 모든 개발자에게 이런 훈련을 요구하는 비율은 15%에 불과했다. 개발자에게 매년 한 차례 이상 공식 보안 훈련 참여를 요구하는 조직의 비율은 절반이 되지 않았으며, 16%는 개발자가 스스로 학습하길 기대하고 있었다. 개발자가 팀에 합류할 때 보안 훈련을 제공하는 비율은 20%에 불과했다.

보안 훈련을 제공하거나 요구하는 경우에도, 대부분 조직이 이런 훈련의 효과를 적절히 추적하지 않고 있다. 개발 팀이나 개별 개발자를 대상으로 보안 문제 도입과 지속적인 개선에 관한 매트릭스를 추적하는 기관과 기업은 40%에 불과하다.

ESG 연구를 후원했던 애플리케이션 보안업체 가운데 하나인 베라코드(Veracode)는 최근 개발자들이 수십 애플리케이션 보안 학습 과정과 익스플로잇과 패치를 연습할 수 있는 컨테이너화 된 앱을 무료로 이용할 수 있는 인-브라우저 플랫폼인 베라코드 시큐리티 랩스 커뮤니티 에디션(Veracode Security Labs Community Edition)을 런칭했다.


공급망 공격의 표적화 된 오픈소스 구성요소들

성숙한 애플리케이션 보안 프로그램이라면 오픈소스 구성요소들과 프레임워크를 다뤄야 한다. 현대적인 애플리케이션 코드 기반에서 큰 비중을 차지하고, 취약점이 승계되는 위험과 공급망 공격 위험이 존재하기 때문이다. ESG 조사 결과에 따르면, 약 절반이 코드 기반의 50% 이상이 오픈소스 구성요소라고 대답했다. 코드의 2/3가 넘는다고 밝힌 비율도 8%이다. 그렇지만 오픈소스 취약점을 다루는 데 투자한 조직의 비율은 48%에 불과한 실정이다.

오픈소스 거버넌스 업체인 소나타입(Sonatype)은 ‘2020년 소프트웨어 공급망 현황 보고서(2020 State of the Software Supply Chain report)'에서 오픈소스 소프트웨어 프로젝트를 표적으로 삼는 공격이 연간 430% 증가했다고 밝혔다. 이런 공격은 공격자가 공개된 취약점을 익스플로잇하는 수동적 공격이 아니다. 공격자는 개발자가 자신의 애플리케이션으로 코드를 가져오는 업스트림 오픈소스 프로젝트를 침해해 악성코드를 주입하려 시도한다.

지난 5월, 깃허브 보안 팀은 넷빈즈(NetBeans) IDE 프로젝트에 대한 백도어 공격을 시도하는 옥토퍼스 스캐너스(Octopus Scanner)라는 악성코드 캠페인에 대해 경고했다. npm이나 PyPi 같은 패키지 리포지토리에 이런 침해된 구성요소, 악성 구성요소가 정기적으로 배포되고 있다.

복잡한 종속성들이 이 문제를 다루기 어렵게 만든다. 2019년, 다름슈타트 대학(Darmstadt University)의 연구진은 자바스크립트 구성요소의 주 소스인 npm 생태계를 분석했다. 그리고 일반적인 패키지들은 각기 다른 39개 메인테이너의 서드파티 패키지 79종을 평균적으로 로딩한다는 사실을 밝혀냈다. npm에서 가장 인기있는 5개 패키지는 13만 4,774~16만 6,086종의 다른 패키지를 로딩하고 있었다.

소나타입은 이 보고서에서 “악성코드를 고의적으로 은밀하게 업스트림 오픈소스 프로젝트에 주입하는 경우, 이를 심은 사람을 제외한 나머지 사람들은 악성코드의 존재를 모를 가능성이 크다. 이는 악의적인 세력이 업스트림에 은밀하게 덫을 놓고, 공급망에서 취약점이 확대되면 다운스트림에서 공격을 실시할 수 있도록 도와주는 방법이다”라고 설명했다.

소나타입에 따르면, 2015년 2월에서 2019년 6월 사이에 216건의 ‘차세대’ 공급망 공격이 보고됐다. 그러나 2019년 7월에서 2020년 5월 사이에 추가적으로 929건의 공격이 기록됐다. 이는 아주 인기있는 공격 경로가 되었다는 의미다.

해커가 구성요소의 알려진 취약점을 익스플로잇하는 전통적인 공격의 경우, 기업들이 이에 대해 충분히 빠르게 대응을 하지 못하는 것으로 판단된다. 2017년 에퀴팩스 침해 사고를 초래했던 아파치 스트러츠(Apache Struts) 2를 예로 들면, 취약점이 알려지고 72시간이 되지 않아 공격자들이 취약점에 대한 익스플로잇 공격을 시작했다. 더 최근에는 솔트스택(SaltStack)에 보고된 한 취약점이 발표된 지 3일이 되지 않아 익스플로잇이 되면서 많은 기업이 대비하지 못한 일이 있었다.

소나타입이 소프트웨어 개발 담당자 679명을 조사한 결과에 따르면, 공개되고 하루 이내에 오픈소스 취약점을 파악한 조직의 비율은 17%에 불과하다. 첫 1주, 1주가 지나고 가서 파악한 비율이 각각 1/3과 약 절반이었다. 또한 약 절반의 조직들은 취약점을 파악하고 대응하는 데 1주 이상이 필요했다. 그리고 이 기간이 1개월 이상인 조직도 약 절반이다.

매년 이용할 수 있는 오픈소스 구성요소와 이에 대한 소비가 증가하고 있는 추세다. 지난 해 자바스크립트 커뮤니티가 릴리스한 새 구성요소는 50만이 넘는다. 이에 rpm 디렉터리는 130만 패키지를 갖게 되었다. 5월까지 개발자들은 npm에서 패키지를 860억 회 다운로드 받았다. 소나타입은 올해 말에는 다운로드 수가 1조에 도달할 것이라고 전망했다. 다름슈타트 대학이 지난 해 발표한 보고서 내용 가운데 우려되는 부분은 npm 패키지의 40%에 알려진 취약점이 포함되어 있다는 것이다. 또한 패치가 적용되지 않은 상태인 npm 패키지의 취약점 비율이 66%이다.

자바 생태계의 경우, 개발자들은 2019년에 메이븐 센트럴 리포지토리(Maven Central Repository)에서 2,260억 회 오픈소스 구성요소를 다운로드했다. 이는 2018년보다 55% 증가한 수치다. 소나타입은 2020년 통계를 토대로, 올해 자바 구성요소 다운로드가 3,760억 회에 도달할 것으로 추정했다. 센트럴 리포지토리를 관리하고 있어, 이 데이터에 대한 인사이트가 풍부한 소나타입은 알려진 취약점이 존재하는 구성요소 다운로드가 1/10이라고 설명했다.

1,700개의 엔터프라이즈 애플리케이션을 분석한 결과, 평균적으로 135개의 서드파티 소프트웨어 구성요소가 포함되어 있고, 이 가운데 90%가 오픈소스이다. 이 오픈소스 구성요소 가운데 취약점이 1개 이상 포함된 비율은 11%이다. 그러나 애플리케이션은 이런 구성요소에서 평균적으로 38개의 알려진 취약점을 물려받는다. 애플리케이션은 통상 2,000~4,000개의 오픈소스 구성요소로 만들어진다. 이는 오픈소스 생태계가 현대적인 소프트웨어 개발에서 중요한 역할을 하고 있다는 점을 알려준다.

.NET 생태계와 마이크로서비스 생태계의 구성요소 소비 트렌드도 유사한 것으로 조사됐다. 도커허브(DockerHub)는 지난 해 2.2 컨테이너 이미지를 받았으며, 올해 개발자는 960억 이미지를 가져오는 요청을 했다. 공개된 공급망 공격에는 도커허브에 호스팅 된 악성 컨네이너 이미지들이 관여되어 있으며, 이미지가 잘못 구성되거나, 취약점을 갖고 있을 확률 또한 높다.


IaC에 필요한 '코드로서의 교정'

데브옵스는 소프트웨어 개발에 큰 변화를 가져왔으며, 이는 전통적인 모놀리식(monolith) 애플리케이션을 자체 컨테이너에서 실행되는 개별 서비스로 분리해 유지시키는 새로운 마이크로서비스 아키텍처를 구현시켰다. 애플리케이션에는 더 이상 기능에 필요한 코드만 포함되지 않는다. 클라우드 플랫폼에서의 배포를 정의해 자동화하는 구성 파일, 필요한 리소스가 포함된다. 데브섹옵스(DevSecOps)의 경우, 개발 팀은 안전한 코드를 작성하는 것에 더해 안전한 인프라를 배포하는 책임을 진다.

IaC 템플릿과 클라우드 배포에서 취약한 구성을 감지할 수 있는 플랫폼을 운영하고 있는 클라우드 보안업체인 애큐릭스(Accurics)가 발표한 새 보고서에 따르면, 컴퓨팅 리소스 프로비저닝에 사용된 구성에 권한을 가진 하드코딩 된 키를 갖고 있는 조직은 41%였으며, 프로비저닝 된 리소스를 갖고 있고 권한 승인이 지나친 IAM(Identity and Access Management) 정책으로 실행되고 있는 배포의 비율은 41%였다. 또한, 대부분이 라우팅 규칙이 잘못 구성되어 있었다.

애큐릭스에 따르면, 이런 문제는 익스플로잇 공격 사례가 많다. 2019년 9월 280만 명의 고객 기록이 노출된 센츄리링크(CenturyLink)의 침해 사고, 2019년 8월 솔트 해시 된 비밀번호와 이메일이 포함된 데이터베이스 스냅샷이 노출된 임페르바(Imperva) 침해 사고, 2019년 7월 미국 거주자 1억 명이 영향을 받은 캐피탈 원 침해 사고 등을 예로 들 수 있다.

애큐릭스는 “데이터베이스 암호화, 액세스 키 순환, 다중인증 적용 등 베스트 프랙티스가 적용되도록 ‘코드로서의 정책(Policy as code)’을 도입해 적용해야 한다. 그러나 이와 동시에 권한 상승(privilege increase)과 경로 변경(route changes)으로 클라우드 배포에 침해 경로가 발생했는지 확인하기 위해 자동화된 위협 모델링도 필요하다. 기업들은 개발 동안 인프라를 규정할 때 코드로서의 보안(Security as code)으로 코드로서의 정책을 보강해야 한다(코드로서의 인프라)”라고 강조했다.

애큐릭스 CTO 옴 물찬다니에 따르면, ‘코드로서의 교정(Remediation as code)’이라는 새로운 프랙티스가 부상하고 있는 추세다. 이는 보안 도구가 클라우드 구성 템플릿의 취약점을 확인하거나, 배포 자체에서 실행되는 것은 물론 자동으로 문제를 고치는 데 필요한 코드를 생성해 개발자에게 제안하는 방식을 의미한다. 이를 통해 해결에 소요되는 시간을 개선시킬 수 있다. 이는 아주 중요한 문제다. 지금까지는 이런 프로세스가 수동인 경우가 많아, 많은 문제들이 무시되었기 때문이다.

지난 몇 년간 많은 애플리케이션 및 인프라 보안 공급업체들이 개발 도구와 통합이 잘 되도록 제품들을 업그레이드했다. 개발자들은 보안 팀과 일하는 방식, 기대사항이 다르기 때문이다. 클라우드 배포에 대해 테스트를 할 수 있는 오픈소스 도구들도 많다.
 
침입 테스트 업체인 비숍 폭스(Bishop Fox)는 블랙 햇 USA 컨퍼런스에서 스모그클라우드(Smogcloud)라는 도구를 출시했다. 보안 엔지니어와 클라우드 관리자가 인터넷에 개방된 FQDN(Fully Qualified Domain Name)과 IP, 잘못된 구성(misconfigurations)이나 취약점 등에 노출된 AWS 클라우드 자산, 더 이상 사용하지 않는 자산, 현재 모니터링되고 있지 않은 서비스, 기타 쉐도우 IT 문제들을 파악하도록 도움을 주는 도구다. 애큐릭스는 여러 오픈소스 도구들과 클라우드 배포 테스팅 플랫폼 무료 버전도 공급하고 있다. editor@itworld.co.kr



2020.08.20

통계로 알아보는 애플리케이션 보안 현황

Lucian Constantin | CSO
지난 몇 년간 데브옵스(DevOps) 문화가 부상하면서 소프트웨어 개발에 큰 변화가 발생했고, 기업들이 새 기능과 혁신을 지원하는 데 필요한 인프라를 자동으로 축소, 또는 확장하고, 코드를 더 빨리 배포할 수 있게 되었다. 그리고 이제 개발과 운영 파이프라인에 보안을 통합시키는 데브섹옵스(DevSecOps)가 확대되면서 애플리케이션 보안에도 변화가 발생하고 있다. 그러나 업계의 새 보고서에 수록된 데이터는 여전히 ‘갭’이 존재한다는 점을 보여준다.


보안 테스트의 주체가 바뀌고 있다

ESG가 북미의 애플리케이션 개발자 및 애플리케이션 보안 담당자 378명을 조사해 발표한 새 보고서에 따르면, 많은 기관과 기업이 자신의 애플리케이션 보안 프로그램이 견고하다고 판단하고 있음에도 불구하고 알려진 취약점이 있는 코드를 계속 배포하고 있다.

취약한 코드를 배포하는 것을 결코 바람직한 일이 아니지만, 이에 대해 알고 배포하는 것이 모르고 배포하는 것보다는 낫다. 위험 평가, 문제점을 바로잡을 계획, 일시적인 경감 대책 아래 이런 결정을 내리는 경우가 많기 때문이다. 조사 대상의 약 절반이 소속 조직이 정기적으로 이렇게 하고 있다고 대답했다. 또 간헐적으로 이렇게 한다고 대답한 비율은 1/3이었다. 그 이유로는 ‘아주 중요한 일정 준수’, ‘취약점의 위험인 낮아’, ‘릴리스 주기에서 너무 늦게 문제점을 발견’이 가장 많이 언급됐다(45%).

이번 조사 결과는 가능한 개발 프로세스 초기에 보안 테스트를 통합시키는 것이 중요한 이유를 설명한다. 또한, 취약한 코드를 배포하는 것이 반드시 보안 프로그램이 견고하지 않다는 것을 알려주는 신호는 아니라는 점을 알려준다. 여러 이유에서 이런 일이 일어날 수 있고, 한 종류의 보안 테스트로는 모든 버그를 포착하기 불가능하기 때문이다. 

그러나 이 보고서는 여전히 애플리케이션 보안 프로그램을 확대하는 과정에 있는 조직들이 많다는 점도 알려준다. 구체적으로 코드 기반의 3/4 이상이 애플리케이션 보안 프로그램의 대상이라고 대답한 비율은 1/3에 불과했다. 그리고 1/3은 프로그램의 대상이 절반이 되지 않는다고 대답했다.
 
취약한 코드를 프로덕션 단계로 배포, 결정해 책임을 진 사람이나 부서는 기업에 따라 다른 것으로 조사됐다. 개발 담당 매니저가 보안 애널리스트와 함께 결정을 내리는 조직의 비율은 28%, 개발 담당 매니저나 보안 애널리스트가 단독으로 이런 결정을 내리는 비율은 각각 24%와 21%였다.

이는 애플리케이션 보안 프로그램이 성숙해지고 있음을 알리는 신호일 수 있다. 데브섹옵스는 보안 테스트를 가능한 개발 파이프라인의 앞으로 옮기는 것이 중요하기 때문이다. 과거에는 보안 팀이 결과물이 완성된 후 보안 테스트를 실시했었다.

보안 팀을 개발 프로세스에 통합시킨 결과로 개발 팀이 보안 테스트를 하고, 결과를 반영하는 기업의 경우, 개발 담당 매니저가 취약점을 수용할지 여부를 결정하는 경우가 많다. 이때 보안 팀과 협력하거나, 팀에 애플리케이션 보안에 대한 지식이 있고 트레이닝을 받은 개발자인 보안 '전문가'가 존재하는 경우, 기업 내부에서 협의해 단독으로 결정을 내린다. 

그러나 이 경우에도 궁극적으로 전사적인 정보 보안에 위험 관리 책임을 갖고 있고, 공격에 더 많이 노출될 수 있는 애플리케이션, 해커가 표적으로 삼을 수 있는 민감한 정보가 많은 애플리케이션을 판단할 수 있는 CISO가 적용한 정책을 기반으로 이런 결정을 내려야 한다. 이런 애플리케이션들은 패칭 등에 있어 더 엄격한 규칙이 적용될 수 있다.


보안 테스트 도구 사용시 당면 과제

위험을 정확히 평가하지 않으면, 알려진 취약점이 있는 코드를 배포했을 때 심각한 결과가 초래될 수 있다. 이와 관련, 지난 12개월 동안 OWASP의 10대 취약점 때문에 프로덕션 애플리케이션이 익스플로잇 당했다고 인정한 응답자의 비율이 60%에 달했다. 

OWASP의 10대 취약점에는 웹 애플리케이션에 초래되는 가장 중대한 보안 위험들이 포함되어 있다. ▲SQL 주입 ▲취약한 인증 ▲민감한 데이터 노출 ▲취약한 액세스 제어 ▲잘못된 보안 구성 ▲알려진 취약점이 존재하는 서드파티 구성요소 이용 등이 여기에 해당된다. 일반적으로 프로덕션 코드에 허용해서는 안되는 문제점들이다.

시장조사기관 ESG 보고서에 따르면, 기업들은 다양한 애플리케이션 보안 테스트 도구를 이용하고 있다. ASV(API security vulnerability) 도구 56%, 잘못된 구성에 대해 보호해주는 IaC(Infrastructure as Code) 보안 도구 40%, SAST(Static Application Security Testing) 도구 40%, SCA(Software Composition Analysis) 테스트 도구 38%, IAST(Interactive A\application security testing) 도구 38%, DAST(Dynamic Application Security Testing) 도구 36%, 보안 문제 파악과 해결에 도움을 주는 IDE(Integrated Development Environment) 플러그인 29%, 컨테이너와 리포지토리, 마이크로서비스에 사용되는 이미지 스캐닝 도구 29%, 퍼징(fuzzing) 도구 16%, 컨테이너 런타임 구성 보안 도구 15% 등이다.

응답자는 이런 도구를 사용할 때 직면하는 가장 큰 과제로 ▲파악한 문제를 경감시키는 지식 부족(29%) ▲개발자들이 회사가 투자한 도구를 효과적으로 사용하지 못하는 것(24%) ▲보안 테스트 도구들이 마찰을 초래하고 개발 주기를 지연시키는 문제(26%) ▲여러 공급업체의 애플리케이션 보안 도구들의 통합이 미흡한 문제(26%)를 꼽았다.

약 80%의 기관과 기업은 보안 애널리스트가 개발자와 직접 협력해 기능과 코드를 평가하고, 위협 모델링을 하고, 매일 개발 스크럼 미팅에 참여하고 있다고 응답했지만, 개발자들의 보안 트레이닝은 많지 않은 것으로 보인다. 개별 개발자나 개발 담당 매니저가 애플리케이션 보안 테스트를 책임지고 있다고 대답한 비율이 각각 19%와 26%에 불과한 이유가 여기에 있다. 이에 대한 책임을 전담 보안 애널리스트에 맡기고 있다고 대답한 비율, 개발 팀과 보안 팀이 공동 책임지고 있다고 대답한 비율은 각각 1/3과 29%였다.

1/3에 해당되는 기관과 기업은 공식 보안 훈련을 요구하는 개발자가 절반이 되지 않았다. 모든 개발자에게 이런 훈련을 요구하는 비율은 15%에 불과했다. 개발자에게 매년 한 차례 이상 공식 보안 훈련 참여를 요구하는 조직의 비율은 절반이 되지 않았으며, 16%는 개발자가 스스로 학습하길 기대하고 있었다. 개발자가 팀에 합류할 때 보안 훈련을 제공하는 비율은 20%에 불과했다.

보안 훈련을 제공하거나 요구하는 경우에도, 대부분 조직이 이런 훈련의 효과를 적절히 추적하지 않고 있다. 개발 팀이나 개별 개발자를 대상으로 보안 문제 도입과 지속적인 개선에 관한 매트릭스를 추적하는 기관과 기업은 40%에 불과하다.

ESG 연구를 후원했던 애플리케이션 보안업체 가운데 하나인 베라코드(Veracode)는 최근 개발자들이 수십 애플리케이션 보안 학습 과정과 익스플로잇과 패치를 연습할 수 있는 컨테이너화 된 앱을 무료로 이용할 수 있는 인-브라우저 플랫폼인 베라코드 시큐리티 랩스 커뮤니티 에디션(Veracode Security Labs Community Edition)을 런칭했다.


공급망 공격의 표적화 된 오픈소스 구성요소들

성숙한 애플리케이션 보안 프로그램이라면 오픈소스 구성요소들과 프레임워크를 다뤄야 한다. 현대적인 애플리케이션 코드 기반에서 큰 비중을 차지하고, 취약점이 승계되는 위험과 공급망 공격 위험이 존재하기 때문이다. ESG 조사 결과에 따르면, 약 절반이 코드 기반의 50% 이상이 오픈소스 구성요소라고 대답했다. 코드의 2/3가 넘는다고 밝힌 비율도 8%이다. 그렇지만 오픈소스 취약점을 다루는 데 투자한 조직의 비율은 48%에 불과한 실정이다.

오픈소스 거버넌스 업체인 소나타입(Sonatype)은 ‘2020년 소프트웨어 공급망 현황 보고서(2020 State of the Software Supply Chain report)'에서 오픈소스 소프트웨어 프로젝트를 표적으로 삼는 공격이 연간 430% 증가했다고 밝혔다. 이런 공격은 공격자가 공개된 취약점을 익스플로잇하는 수동적 공격이 아니다. 공격자는 개발자가 자신의 애플리케이션으로 코드를 가져오는 업스트림 오픈소스 프로젝트를 침해해 악성코드를 주입하려 시도한다.

지난 5월, 깃허브 보안 팀은 넷빈즈(NetBeans) IDE 프로젝트에 대한 백도어 공격을 시도하는 옥토퍼스 스캐너스(Octopus Scanner)라는 악성코드 캠페인에 대해 경고했다. npm이나 PyPi 같은 패키지 리포지토리에 이런 침해된 구성요소, 악성 구성요소가 정기적으로 배포되고 있다.

복잡한 종속성들이 이 문제를 다루기 어렵게 만든다. 2019년, 다름슈타트 대학(Darmstadt University)의 연구진은 자바스크립트 구성요소의 주 소스인 npm 생태계를 분석했다. 그리고 일반적인 패키지들은 각기 다른 39개 메인테이너의 서드파티 패키지 79종을 평균적으로 로딩한다는 사실을 밝혀냈다. npm에서 가장 인기있는 5개 패키지는 13만 4,774~16만 6,086종의 다른 패키지를 로딩하고 있었다.

소나타입은 이 보고서에서 “악성코드를 고의적으로 은밀하게 업스트림 오픈소스 프로젝트에 주입하는 경우, 이를 심은 사람을 제외한 나머지 사람들은 악성코드의 존재를 모를 가능성이 크다. 이는 악의적인 세력이 업스트림에 은밀하게 덫을 놓고, 공급망에서 취약점이 확대되면 다운스트림에서 공격을 실시할 수 있도록 도와주는 방법이다”라고 설명했다.

소나타입에 따르면, 2015년 2월에서 2019년 6월 사이에 216건의 ‘차세대’ 공급망 공격이 보고됐다. 그러나 2019년 7월에서 2020년 5월 사이에 추가적으로 929건의 공격이 기록됐다. 이는 아주 인기있는 공격 경로가 되었다는 의미다.

해커가 구성요소의 알려진 취약점을 익스플로잇하는 전통적인 공격의 경우, 기업들이 이에 대해 충분히 빠르게 대응을 하지 못하는 것으로 판단된다. 2017년 에퀴팩스 침해 사고를 초래했던 아파치 스트러츠(Apache Struts) 2를 예로 들면, 취약점이 알려지고 72시간이 되지 않아 공격자들이 취약점에 대한 익스플로잇 공격을 시작했다. 더 최근에는 솔트스택(SaltStack)에 보고된 한 취약점이 발표된 지 3일이 되지 않아 익스플로잇이 되면서 많은 기업이 대비하지 못한 일이 있었다.

소나타입이 소프트웨어 개발 담당자 679명을 조사한 결과에 따르면, 공개되고 하루 이내에 오픈소스 취약점을 파악한 조직의 비율은 17%에 불과하다. 첫 1주, 1주가 지나고 가서 파악한 비율이 각각 1/3과 약 절반이었다. 또한 약 절반의 조직들은 취약점을 파악하고 대응하는 데 1주 이상이 필요했다. 그리고 이 기간이 1개월 이상인 조직도 약 절반이다.

매년 이용할 수 있는 오픈소스 구성요소와 이에 대한 소비가 증가하고 있는 추세다. 지난 해 자바스크립트 커뮤니티가 릴리스한 새 구성요소는 50만이 넘는다. 이에 rpm 디렉터리는 130만 패키지를 갖게 되었다. 5월까지 개발자들은 npm에서 패키지를 860억 회 다운로드 받았다. 소나타입은 올해 말에는 다운로드 수가 1조에 도달할 것이라고 전망했다. 다름슈타트 대학이 지난 해 발표한 보고서 내용 가운데 우려되는 부분은 npm 패키지의 40%에 알려진 취약점이 포함되어 있다는 것이다. 또한 패치가 적용되지 않은 상태인 npm 패키지의 취약점 비율이 66%이다.

자바 생태계의 경우, 개발자들은 2019년에 메이븐 센트럴 리포지토리(Maven Central Repository)에서 2,260억 회 오픈소스 구성요소를 다운로드했다. 이는 2018년보다 55% 증가한 수치다. 소나타입은 2020년 통계를 토대로, 올해 자바 구성요소 다운로드가 3,760억 회에 도달할 것으로 추정했다. 센트럴 리포지토리를 관리하고 있어, 이 데이터에 대한 인사이트가 풍부한 소나타입은 알려진 취약점이 존재하는 구성요소 다운로드가 1/10이라고 설명했다.

1,700개의 엔터프라이즈 애플리케이션을 분석한 결과, 평균적으로 135개의 서드파티 소프트웨어 구성요소가 포함되어 있고, 이 가운데 90%가 오픈소스이다. 이 오픈소스 구성요소 가운데 취약점이 1개 이상 포함된 비율은 11%이다. 그러나 애플리케이션은 이런 구성요소에서 평균적으로 38개의 알려진 취약점을 물려받는다. 애플리케이션은 통상 2,000~4,000개의 오픈소스 구성요소로 만들어진다. 이는 오픈소스 생태계가 현대적인 소프트웨어 개발에서 중요한 역할을 하고 있다는 점을 알려준다.

.NET 생태계와 마이크로서비스 생태계의 구성요소 소비 트렌드도 유사한 것으로 조사됐다. 도커허브(DockerHub)는 지난 해 2.2 컨테이너 이미지를 받았으며, 올해 개발자는 960억 이미지를 가져오는 요청을 했다. 공개된 공급망 공격에는 도커허브에 호스팅 된 악성 컨네이너 이미지들이 관여되어 있으며, 이미지가 잘못 구성되거나, 취약점을 갖고 있을 확률 또한 높다.


IaC에 필요한 '코드로서의 교정'

데브옵스는 소프트웨어 개발에 큰 변화를 가져왔으며, 이는 전통적인 모놀리식(monolith) 애플리케이션을 자체 컨테이너에서 실행되는 개별 서비스로 분리해 유지시키는 새로운 마이크로서비스 아키텍처를 구현시켰다. 애플리케이션에는 더 이상 기능에 필요한 코드만 포함되지 않는다. 클라우드 플랫폼에서의 배포를 정의해 자동화하는 구성 파일, 필요한 리소스가 포함된다. 데브섹옵스(DevSecOps)의 경우, 개발 팀은 안전한 코드를 작성하는 것에 더해 안전한 인프라를 배포하는 책임을 진다.

IaC 템플릿과 클라우드 배포에서 취약한 구성을 감지할 수 있는 플랫폼을 운영하고 있는 클라우드 보안업체인 애큐릭스(Accurics)가 발표한 새 보고서에 따르면, 컴퓨팅 리소스 프로비저닝에 사용된 구성에 권한을 가진 하드코딩 된 키를 갖고 있는 조직은 41%였으며, 프로비저닝 된 리소스를 갖고 있고 권한 승인이 지나친 IAM(Identity and Access Management) 정책으로 실행되고 있는 배포의 비율은 41%였다. 또한, 대부분이 라우팅 규칙이 잘못 구성되어 있었다.

애큐릭스에 따르면, 이런 문제는 익스플로잇 공격 사례가 많다. 2019년 9월 280만 명의 고객 기록이 노출된 센츄리링크(CenturyLink)의 침해 사고, 2019년 8월 솔트 해시 된 비밀번호와 이메일이 포함된 데이터베이스 스냅샷이 노출된 임페르바(Imperva) 침해 사고, 2019년 7월 미국 거주자 1억 명이 영향을 받은 캐피탈 원 침해 사고 등을 예로 들 수 있다.

애큐릭스는 “데이터베이스 암호화, 액세스 키 순환, 다중인증 적용 등 베스트 프랙티스가 적용되도록 ‘코드로서의 정책(Policy as code)’을 도입해 적용해야 한다. 그러나 이와 동시에 권한 상승(privilege increase)과 경로 변경(route changes)으로 클라우드 배포에 침해 경로가 발생했는지 확인하기 위해 자동화된 위협 모델링도 필요하다. 기업들은 개발 동안 인프라를 규정할 때 코드로서의 보안(Security as code)으로 코드로서의 정책을 보강해야 한다(코드로서의 인프라)”라고 강조했다.

애큐릭스 CTO 옴 물찬다니에 따르면, ‘코드로서의 교정(Remediation as code)’이라는 새로운 프랙티스가 부상하고 있는 추세다. 이는 보안 도구가 클라우드 구성 템플릿의 취약점을 확인하거나, 배포 자체에서 실행되는 것은 물론 자동으로 문제를 고치는 데 필요한 코드를 생성해 개발자에게 제안하는 방식을 의미한다. 이를 통해 해결에 소요되는 시간을 개선시킬 수 있다. 이는 아주 중요한 문제다. 지금까지는 이런 프로세스가 수동인 경우가 많아, 많은 문제들이 무시되었기 때문이다.

지난 몇 년간 많은 애플리케이션 및 인프라 보안 공급업체들이 개발 도구와 통합이 잘 되도록 제품들을 업그레이드했다. 개발자들은 보안 팀과 일하는 방식, 기대사항이 다르기 때문이다. 클라우드 배포에 대해 테스트를 할 수 있는 오픈소스 도구들도 많다.
 
침입 테스트 업체인 비숍 폭스(Bishop Fox)는 블랙 햇 USA 컨퍼런스에서 스모그클라우드(Smogcloud)라는 도구를 출시했다. 보안 엔지니어와 클라우드 관리자가 인터넷에 개방된 FQDN(Fully Qualified Domain Name)과 IP, 잘못된 구성(misconfigurations)이나 취약점 등에 노출된 AWS 클라우드 자산, 더 이상 사용하지 않는 자산, 현재 모니터링되고 있지 않은 서비스, 기타 쉐도우 IT 문제들을 파악하도록 도움을 주는 도구다. 애큐릭스는 여러 오픈소스 도구들과 클라우드 배포 테스팅 플랫폼 무료 버전도 공급하고 있다. editor@itworld.co.kr

X