수천 개의 앱을 수천 번 점검했더니 설정 오류와 취약점들이 무더기로 나왔다. 오픈소스도 문제이긴 하지만 생각보다 높은 비중을 차지하고 있지는 않았다. 점검 방법을 다양화 하거나 처음부터 보안을 고려한 설계를 진행하면 군계일학이 될 수 있다고 한다.

[보안뉴스 문가용 기자] 거의 모든 애플리케이션들에 최소 한 개 이상의 취약점이나 설정 오류가 있는 것으로 조사됐다. SSL과 TLS의 설정 오류, CSP 헤더 부재, 정보를 유출시키는 서버 배너가 보안에 직접적으로 영향을 주는 문제들 중 가장 빈번히 나타나는 것으로 집계됐고, 취약점이나 설정 오류 중 25%는 고위험군 혹은 초고위험군에 속한 것으로 분류됐다. 이에 대해 보안 업체 시놉시스(Synopsys)가 발표했다.


시놉시스의 소프트웨어 무결성 그룹(Software Integrity Group) 담당자인 레이 켈리(Ray Kelly)는 “설정 오류 문제들은 좀 덜 심각한 문제로 인식되는 경향이 있는데, 설정 오류나 코딩 문제나 위험하긴 마찬가지”라고 강조한다. “보통 시큐어 코딩이라고 하면 정적 스캔을 통해 발견되는 취약점을 제거하는 것을 말합니다. 점점 많은 기업들이 이 부분을 잘 해내고 있지요. 하지만 여기에 지나치게 신경을 쓴 것인지 기본적인 설정 부분을 간과할 때가 많습니다. 정적 애플리케이션 보안 점검(SAST) 스캔을 통해서는 설정 오류를 잡아내기가 힘듭니다. 이 설정이라는 건, 코드가 실제 환경에 구축되는 것과 관련된 부분이니까요. 실제 환경에 구축된 상태에서의 점검을 SAST로는 할 수 없지요.”

그렇기 때문에 SAST에 더해 설정 문제를 점검할 수 있는 도구도 추가하는 것이 안전한 애플리케이션을 만드는 데 도움이 된다고 할 수 있다. “예를 들어 모의 해킹을 한다면 SSL/TLS 설정의 오류 문제를 77% 정도 잡아낼 수 있습니다. 동적 애플리케이션 보안 점검(DAST)을 한다면 탐지율을 81%로까지 늘릴 수 있지요. 이 두 가지 중 하나에 모바일 애플리케이션 보안 점검(MAST)까지 실시한다면 82%까지 SSL/TLS 설정 오류를 찾아냅니다.”

보안 업체 베라코드(Veracode)도 지난 2월 애플리케이션 보안과 관련된 보고서를 발표한 바 있다. 지난 10년 동안 애플리케이션 스캔 행위가 3배 늘어났다는 내용을 담고 있었다. 하지만 77%의 서드파티 라이브러리에 여전히 알려진 취약점들이 존재하며, 취약점이 공개된 후 평균 3개월 동안 서드파티 라이브러리들에서 제거되지 않았다는 내용도 포함되어 있었다. 패치가 나와도 3개월 정도는 적용되지 않은 채 활용된다는 게 당시 애플리케이션 개발의 현실이라는 뜻이다.

당시에도 베라코드는 “정적 스캔과 동적 스캔을 같이 사용하는 애플리케이션 개발사는 그렇지 않은 개발사보다 평균 24일 빠르게 취약점을 해결한다”고 발표했었다. 그러면서 “보안 스캔이 포함된 지속적인 실험과 점검, 통합이 점점 애플리케이션 개발의 표준이 되어가고 있다”고도 주장했다. 시놉시스처럼 다각도의 점검이 애플리케이션 보안을 향상시킨다는 보고서라고 볼 수 있다.

SAST나 DAST, 혼자서는 부족해
시놉시스가 이번에 발표한 바에 의하면 통신 암호화와 관련된 기술들에서 가장 많은 문제가 야기된다고 볼 수 있다. SSL과 TLS가 모바일 애플리케이션들에서 가장 많이 나타나는 오류라고 하니 말이다. 하지만 문제는 이것보다 훨씬 더 많다. 

1) 비밀번호 설정 오류가 취약한 경우가 1/4에서 나타났다 - 모의 해킹을 통해 찾아냄.
2) XSS 취약점이 22%에서 나타났다 - 모의 해킹을 통해 찾아냄
3) 세션 타임아웃이 제대로 설정되지 않은 애플리케이션이 38%였다 - DAST를 통해 찾아냄.
4) 클릭재킹 취약점을 포함하고 있는 애플리케이션이 30%였다 - DAST를 통해 찾아냄.

각 점검 방법마다 강점들이 있고, 이 때문에 점검의 방법을 다양화 하면 할수록 숨겨진 문제들을 찾아낼 가능성이 높아진다는 것이라고 볼 수 있다. “물론 이는 누구나 아는 내용입니다. 점검을 더 하면 할수록 더 많은 문제를 찾아서 해결할 수 있다는 것 말이죠. 하지만 그러려면 시간과 돈이 추가로 들어가죠. 제대로 점검을 하고 싶어도 하지 못하는 기업들 입장에서는 쓸데없는 조언일 겁니다. 그렇기 때문에 중요해지는 건 ‘설계에 의한 보안(security by design)’이라는 개념입니다. 앱 설계 시점부터 완성 시점까지 보안 요소들을 계속해서 삽입하는 것이죠. 이렇게 하는 게 나중에 보안 점검의 가짓수를 늘리는 것보다 훨씬 효율적이고 저렴합니다.”

시놉시스는 이번 보고서 작성을 위해 2700개 이상의 애플리케이션들을 4400회 이상 실험했다고 한다. 설정 오류를 제외하고, 취약점들 중 가장 빈번히 나타난 건 XSS 취약점이었다. “총 취약점 중 22%가 XSS였습니다. 대부분 고위험군으로 분류되기에 충분한 것들이었습니다. 위험도로 따지면 초고위험도로 분류된 SQL 주입 취약점이 가장 많이 나타났습니다. 전체 취약점의 4%를 차지하고 있었습니다.”

소프트웨어 공급망이라는 위험
현대 소프트웨어 코드베이스의 80%는 오픈소스 요소들이다. 그렇기 때문에 이번 조사에서 코드베이스의 81%에서 최소 한 가지 이상의 취약점이 발견되었고, 85%에서 구버전의 오픈소스가 탐지됐다는 사실이 그리 놀라운 일은 아니다. 오픈소스는 개발 행위를 매우 편리하게 만들어주기도 하지만 반대로 애플리케이션을 위험하게 만드는 주범이기도 하다.

하지만 시놉시스는 “오픈소스가 애플리케이션 문제의 가장 큰 원인이라고 결론을 내리기는 힘들다”는 입장이다. “공급망과 오픈소스 소프트웨어 요소들에서 발견된 취약점들은 애플리케이션들에서 발견되는 전체 문제의 1/4 정도만을 차지합니다. 모의 해킹을 통해 찾아낸 문제들 중 ‘취약한 서드파티 요소들’을 사용한 것이 원인이 되는 것은 21%였고, SAST를 통해서는 27%만이 여기에 해당했습니다. 오픈소스나 서드파티 요소들이 문제가 되는 경우는 생각보다 적었습니다.”

이러한 예상 외의 결과에 대해 켈리는 “소프트웨어 구성품 분석(SCA)이 개발사들 사이에서 널리 사용되는 것으로 추정된다”고 분석한다. “오픈소스나 서드파티 요소들에서 나오는 문제들은 SCA와 같은 기술을 사용하면 개발 초기에 미리 발견해 해결할 수 있습니다. 나중에 골치 아플 수 있는 문제를 미리미리 제거하는 것이죠.”

3줄 요약
1. 애플리케이션들 대부분 설정 오류나 취약점 한 개 이상 가지고 있음.
2. 서드파티와 오픈소스에 대한 의존도가 높다는 것도 문제인데, 가장 큰 문제는 아님.
3. 애플리케이션 점검 방법을 다양화하거나, 설계에 의한 보안이라는 개념을 도입하거나.
[국제부 문가용 기자(globoan@boannews.com)]

<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>