돌아온 OWASP TOP 10, “소프트웨어 개발의 뿌리부터 곪았다”
- 접근 제어 실패, 1위 수성 성공
- 소프트웨어 복잡성 증가하면서 불거지는 문제가 가득
- 보안을 '통합적 설계'로 접근하지 않는 현실
4년 만에 OWASP Top 10이 공개됐다. 현대 소프트웨어에서 가장 많이 발견되는 유형의 취약점들을 10개로 정리해 둔 이 목록은, 이번이 불과 8번째 집계 결과이긴 하지만 이미 소프트웨어 개발에 있어 중요한 참고 자료로 자리를 잡고 있다. 비정기적으로 발표되는 Top 10은, 2021년 발표된 이후 한 동안 소식이 없었다가 여러 가지 변경점과 함께 올해 새로운 메시지도 전달하고 있다.
결과부터 보자면, 가장 유의해야 할 10가지 취약점 카테고리는 순서대로 다음과 같다.
1) 접근 제어 실패
2) 보안 설정 오류
3) 소프트웨어 공급망 오류 및 결함
4) 암호화 오류
5) 주입 관련 취약점
6) 안전하지 않은 설계
7) 인증 실패
8) 소프트웨어 또는 데이터 무결성 오류
9) 보안 로깅 및 경고 오류
10) 예외 조건의 부적절한 처리
소프트웨어의 고질적 문제와 진화를 보여주는 1~3위
OWASP은 ‘접근 제어 실패’에 대해 “가장 심각한 애플리케이션 보안 위협”이라고 설명했다. “실험한 모든 애플리케이션의 3.73%가 이런 류의 오류를 포함하고 있었습니다.” 이 카테고리에 해당하는 CWE는 21가지로, ‘권한이 없는 사용자가 열람하면 안 되거나 뭔가를 실행할 수 없는 것에 접근할 수 있게 되는 결과’를 야기하는 모든 유형의 취약점들이 여기에 포함된다. 2021년 탑텐에서도 1위였다. 즉 현대 소프트웨어 환경에서 적잖은 기간 동안 가장 큰 위험 요소로 남아 있는 취약점이라고 볼 수 있다.
‘보안 설정 오류’의 경우 2021년 5위였다가 이번에 2위로 급상승한 유형의 취약점이다. 테스트용 애플리케이션 전체에서 3%가 이런 유형의 취약점에 노출돼 있었다고 한다. 약 16개의 CWE가 이 범주에 포함된다.
“이 유형의 오류가 2위로 뛰어오른 건 현대 소프트웨어의 진화가 취한 방향성 때문입니다. 최근 소프트웨어의 구조와 쓰임새가 고도화 되고 복잡해짐에 따라 소프트웨어에 내재된 보안 장치들마저 덩달아 복잡해지고 있습니다. 그래서 예전에는 개발자가 보안 규칙을 코드로 명확히 정의해 놓을 수 있었다면, 지금은 기본 원리만 정의해 놓고 사용자가 사용 환경과 방법에 따라 유연하게 설정할 수 있도록 해놓는 추세입니다. 예전 소프트웨어 보안이 정해진 레시피로 요리하는 것과 같았다면 요즘 소프트웨어의 보안은 온갖 다양한 재료만 가져다주는 것과 비슷합니다. 전자는 실패 확률이 적지만 다양하고 많은 요리를 할 수 없고, 후자는 반대이죠. 소프트웨어의 확장성과 유연성이 중요한 가치가 되면서 보안을 설정 방식으로 탑재하기 때문에 설정 오류가 많이 나오고 있다고 정리할 수 있습니다.”
‘소프트웨어 공급망 오류’의 경우 5개의 CWE가 여기에 해당한다. 테스트 환경에서 아주 많은 앱들이 이 문제를 가지고 있던 건 아니었지만, 여기에 해당하는 단일 취약점(CVE)들의 평균 심각도는 이번 탑텐에 포함된 그 어떤 오류들의 그것보다 높았다고 한다. 2021년에는 ‘취약하고 오래된 구성 요소’라는 이름의 카테고리였으나, 이번 해 개념이 확장되면서 명칭 자체가 바뀌었다.
“이 문제 역시 현대 소프트웨어의 개발 방식이 바뀌어 가고 있는 것과 관련이 있습니다. 개발자들의 ‘보안 관심사’ 중 가장 많이 언급된 것도 이것이라, 개발자들이 현장에서 실질적으로 체감하고 있는 위협이라고도 볼 수 있습니다. 이는 소프트웨어들이 백지에서부터 출발하는 게 아니라 각종 오픈소스나 구성 요소들을 조합하는 방식으로 만들어지는 것과 관련이 있습니다. 이런 방식으로 개발을 하면, 하나의 소프트웨어가 매우 복잡한 의존성 구조를 가지게 되거든요. 즉 소프트웨어 하나를 만드는 데 개입되는 구성 요소가 점점 많아지고, 관계도가 얽히고 꼬이는 겁니다. 그렇기 때문에 어디 한 군데서 오류가 나도 광범위한 영향력이 발휘되기도 하죠.” 실제 개발자들을 직접 노리는 공급망 공격이 가장 유행하고 있기도 하다.
떨어진 순위, 유지되는 순위
그 다음 ‘암호화 실패’는 이전 탑텐에서 2위였다가 4위로 내려간 유형의 오류다. 애플리케이션들 중 평균 3.8%에서 발견됐다고 한다. CWE로 따지자면 32개가 여기에 해당된다. “대서특필되는 문제가 아니라 개발자나 보안 담당자들이 심각성을 잘 인지 못하고 있는 취약점이기도 합니다. 하지만 각종 민감 데이터 유출이나 시스템 침해로까지 이어지는 중대한 결함입니다.”
‘주입 관련 취약점’은 이름 그대로 ‘주입 공격’을 허용하는 오류다. 2021년 기준 3위였다가 올해 5위로 떨어졌다. 38개의 CWE가 여기에 속한다. 올해 탑텐 목록에서 가장 많은 CWE를 보유하고 있는 카테고리다. CVE로 따져도 1위라고 한다. “교차 사이트 스크립팅(XSS)나 SQL 주입 공격 등을 가능하게 하는 게 바로 이 주입 관련 취약점이라고 할 수 있습니다.” 그나마 다행인 건 개발자들이 앱 개발 후 보안 점검할 때 가장 많이 확인하는 게 주입 관련 취약점이라고 한다.
‘안전하지 않은 설계’ 문제는 이전에 4위였다가 이번에 6위로 하락했다. 2021년에 처음 소개된 카테고리로, 비교적 새로운 유형의 오류라고 할 수 있다. 요 몇 년 사이 ‘설계에서부터 보안(Security by Design)’이라는 개념이 확대되면서 많이 발견되고 또 논란이 된 취약점이며, 많은 부분 개선이 이뤄지고 있기도 하다. 특히 위협 모델링과 보안을 고려한 설계라는 문화가 서서히 퍼지고 있어, 앞으로 이 카테고리의 순위는 더 떨어질 것으로 기대되고 있다.
‘인증 실패’는 이전에도 7위, 올해도 7위다. CWE 36개를 포함하고 있다. 2021년에는 ‘식별 및 인증 실패’라는 이름이었으나, 올해에는 인증의 개념을 보다 명확히 구분하기 위해 따로 독립시켰다. 재미있는 건, 인증 실패가 여전히 많은 앱에서 나오고 있지만, 오히려 긍정적인 면모가 있다는 OWASP의 분석 내용이다. ‘인증 실패’라는 중대 결함이 7위를 유지하고 있는 게 어떻게 긍정적일 수 있을까?
“탑텐에 포함된 다른 유형의 취약점보다 증가세가 완화되어 있다는 점에서 긍정적입니다. 다음 탑텐에서는 떨어지거나 순위 바깥으로 밀려날 수도 있습니다. 게다가 요즘은 앱 개발자가 직접 인증 기술을 개발해 넣지 않고, 표준 프레임워크를 외부에서 가져다 탑재시키죠. 그러니 앱 개발자의 기술적 부족함이 인증 실패로 이어지는 사례가 줄고, 프레임워크를 사용하는 사용자의 설정이나 보안 정책 운영 상에서의 실수가 인증 실패로 이어지는 경우가 늘어나고 있습니다. ‘보안 설정 오류’라는 카테고리가 급증한 것과, ‘인증 실패’ 카테고리의 순위 유지가 사실 같은 맥락의 현상이라고도 할 수 있습니다.”
개발자의 기술적 오류로 인한 인증 실패는, 같은 인증 실패라도 좀 더 치명적인 결과를 낳을 수 있고, 정책과 운영상의 실수로 인한 인증 실패는 그렇게까지 치명적이지 않다는 게 일반론이다. 개발자가 인증 시스템을 직접 구현하다가 발생하는 오류들에는 ‘평문 비밀번호 저장’, ‘자체 해시 함수 사용’, ‘로그인 실패 시 에러 메시지로 계정 존재 여부 노출’, ‘토큰 만료 확인 누락’, ‘비밀번호 변경 후 기존 세션 유지’와 같은 것들이 있는데, 이중 하나만 뚫려도 곧바로 계정 탈취로 이어진다. 설정 오류도 계정 탈취로 이어질 수 있지만 확률이 낮다. ‘인증 실패’가 겉으로 보기에는 7위를 유지하는 것처럼 보여도 그 속을 들여다보면 표준 프레임워크 활용 비율이 높아졌기에 “긍정적”이라고 OWASP 측은 설명하고 있는 것이다.
‘소프트웨어와 데이터 무결성 문제’ 역시 8위에 머물러 있는 것으로 집계됐다. 적잖은 앱에서 발견되는 특징으로, 소프트웨어나 코드, 데이터가 변조되지 않았다는 것을 보장해주는 시스템이 부실하다는 의미다. 권한과 신뢰를 부여하는 과정에서 혼돈이 올 수 있고, 그 틈을 공격자가 파고 들어 큰 문제를 일으킬 수 있다. 어떻게 보면 공급망 문제와도 비슷한데, 공급망은 소프트웨어가 연루된 생태계 전체를 아우르는 문제이고 ‘소프트웨어/데이터 무결성 문제’는 단일 애플리케이션에 해당하는 것이라 할 수 있다. 약 12개의 CWE가 여기에 해당한다.
‘보안 로깅 및 경고 오류’ 역시 9위에서 변함이 없다. 원래는 ‘보안 로깅 및 모니터링 오류’였는데, 명칭이 살짝 변경됐다. 모니터링을 넘어 경고까지 가야한다는 OWASP의 철학이 반영된 것이라고 한다. “경고 없이 모니터링만 하는 보안 시스템은, 현대 소프트웨어 생태계에서 무의미합니다. 로깅을 하는 이유, 모니터링을 하는 이유, 전부 피해자에게 적절한 경고를 하기 위해서죠. 이 개념이 좀 더 퍼져나가면 ‘모니터링을 하고 있다’는 것만으로 안전을 유지할 수 없다는 생각이 정착할 것으로 보고 있습니다.”
‘예외 조건 처리 결함’은 올해 새롭게 등장한 항목이다. 총 24개의 CWE가 여기에 포함된다. 이는 위에서 언급된 ‘소프트웨어 구조가 점점 복잡해지고 있다’는 것과 맞물려 있는 현상이다. 복잡해지기 때문에 소프트웨어가 개발자의 의도와 다르게 작동하는 경우의 수를 모두 생각해 대비하는 게 어려워지고 있다. 게다가 ‘개발 속도’가 중요한 가치로 자리를 잡으면서 개발자들이 예외 처리를 설계하는 것에 크게 집중하지 않기도 한다. “이런 개발 분위기가 모두 반영된 게 바로 이 새 카테고리라고 할 수 있습니다.”
개발 방식의 대변혁
2025년 탑텐 목록이 드러내는 내용은 명확하다. “소프트웨어가 지나치게 복잡해지고 있다”는 것이다. 그 복잡성을 안전하게 추스리면서 나아가기는커녕 시장 선점 효과를 우선시하기 때문에 다양한 문제가 발생한다는 게 OWASP의 경고라고 할 수 있다. 소프트웨어 개발자들은 그 어느 때보다 더 많은 구성 요소를 빌려 쓰는데, 그 구성 요소들을 일일이 검사하지 못하는 현재 개발 상황이 거의 모든 취약점들의 근본 원인으로 작동하고 있다. 이는 개발 업계 전체의 분위기가 바뀌기 전에는 개선되기 힘든 문제일 것이므로 상당 기간 해결되지 않은 채 남아 있을 것으로 예상된다.
그 와중에 권한 관리 실패가 꽤 긴 기간 1위를 지키고 있다는 것에도 주목해야 한다. 소프트웨어의 근본 구조에 기인한 문제이기 때문이다. 이 '근본 문제'란 무엇인가? 소프트웨어의 기능이 늘어날수록 개발자가 각 기능과 관련이 있는 접근 권한의 모든 상황을 면밀히 검토해 개발에 반영해야 하는데, 이 과정에서 실수가 없을 수 없다는 것이다. 이는 ‘소프트웨어의 기능이 곧 하나의 공격 통로가 된다’와 ‘접근 권한 문제와 관련된 책임을 개발자만 지고 있다’는 의미로 연결된다.
‘소프트웨어 기능이 곧 하나의 공격 통로가 된다’는 것은, 소프트웨어 기능이 많으면 많아질수록 공략의 방법이 증가한다는 뜻이다. 기능 하나 추가하는 것이 결코 가벼운 사안이 아니라는 의미다. 그러므로 ‘우리 소프트웨어에 이런 기능을 하나 추가할까?’라는 아젠다가 회의 테이블에 올라왔을 때, 개발자는 물론 보안 담당자와 기획자, 마케터, 영업 담당자 등이 다 모여서 다각도로 검토해야 한다. 하지만 현실은 어떤가? 개발팀 안에서 모든 경우의 수를 알아서 생각하고, 이를 알아서 구현해야 한다. ‘접근 권한 책임을 개발자 혼자 진다’는 것이다. 현대의 보안은 ‘통합적 설계’로서 갖춰야 하는데, 일부 담당자 개인의 몫으로만 남기고 있기에 아직 ‘접근 권한 관리 실패’가 1위를 굳건히 수성하고 있다고 해석할 수 있다.
OWASP 탑텐은 ‘10개의 취약점 목록’이 아니다. 소프트웨어 개발 방식의 뿌리에서부터 곪아터진 문제들이 다양한 형태로 드러나는 것을, 보기 좋게 10개로 요약한 것에 가깝다. 개발자 개개인보다, 개발 팀을 운영하는 회사의 운영진들이 더 깊이 읽고 숙고해야 할 문서라고 할 수 있다.
한편 16일, OWASP 서울 챕터는 '보안 송년회'를 통해 OWASP 탑텐의 보다 세부적이고 전문적인 내용을 공개할 예정이다.🆃🆃🅔
by 문가용 기자(anotherphase@thetechedge.ai)
Related Materials
- [1] OWASP Top 10:2025 공식 소개 페이지 (A01–A10 목록 및 정의), 2024년
- [2] OWASP Top 10:2025 RC1 메인 페이지, 2024년
- [3] OWASP Top 10 2025: Key Changes and What Developers Should Do, Aikido, 2024년
- [4] The New 2025 OWASP Top 10 List: What Changed, and What You Need to Know, Fastly, 2024년



