파이썬 보안 문제: 일반적인 위험 요소 및 대응 방안

주요 내용

• 파이썬의 보안 문제는 직접 작성한 코드만큼이나 임포트한 내용에서도 비롯됩니다.
• 타이포스쿼팅과 의존성 혼동은 악성 패키지가 PyPI 사용자에게 유입되는 것으로 잘 알려진 방법입니다.
• 파이썬 릴리스의 지원 기간이 종료되면, 업스트림에서 보안 패치가 더 이상 제공되지 않습니다.
• CI를 통한 스캔, 고정된 종속성 버전, 그리고 꾸준한 패치 관행은 일상적인 보안 위협 노출을 크게 줄여줍니다.

결함이 없는 앱이라도 4단계 깊이의 종속성에 숨겨진 알려진 취약점을 포함하고 있을 수 있으며, 자신의 소스 코드만으로는 이를 절대 발견할 수 없습니다. 안전하지 않은 역직렬화, 인젝션 결함 또는 잘못된 구성으로 인해 직접 작성한 코드 역시 똑같이 문제가 될 수 있습니다. 파이썬의 보안 위험은 공급망, 런타임 버전, 그리고 직접 작성한 코드라는 세 가지 영역에 동시에 존재합니다.

이 글에서는 실제 운영 환경에서 발생하는 취약점, 이름을 꼭 알아두어야 할 CVE, 그리고 취약점 노출 위험을 줄이는 습관에 대해 자세히 살펴봅니다.

파이썬의 보안 문제는 무엇인가요?

파이썬 보안 문제는 공격자가 데이터를 탈취하거나, 기능을 탈취하거나, 시스템 무결성을 훼손하는 데 악용할 수 있는 파이썬 애플리케이션의 취약점 또는 약점을 말합니다. 파이썬은 거의 모든 곳에서 사용되고 있으며 방대한 타사 패키지 생태계를 기반으로 하고 있는데, 바로 이 생태계 덕분에 공격자들은 표적으로 삼을 수 있는 막대한 공급망 표면을 확보하게 됩니다.

이러한 문제들 대부분은 그리 특이한 것이 아닙니다. 이는 사용자 입력을 eval()로 전달하는 것, 공개된 CVE 취약점이 있는 구형 라이브러리를 사용하는 것, 혹은 단순한 설정 오류 에서 비롯됩니다.

팀들을 당황하게 만드는 네 번째 요인은 더 이상 수정 패치를 제공받지 못하는 파이썬 버전을 실행하고 있는 경우입니다. 릴리스의 지원 기간이 종료되면 업스트림 보안 패치 제공이 중단되므로, 그 날짜 이후에 발견된 취약점은 마이그레이션을 수행하거나 다른 곳에서 확장 지원을 받지 않는 한 해결되지 않은 상태로 남게 됩니다.

파이썬에서는 이러한 상태를 ‘버그 수정(bugfix)’과 ‘보안(security)’이라고 부릅니다. 버그 수정 브랜치에는 버그 수정과 보안 수정 사항이 모두 반영되며, 몇 달에 한 번씩 새로운 바이너리가 제공됩니다. 브랜치가 보안 브랜치로 전환되면 보안 수정 사항만 반영되며 더 이상 바이너리가 출시되지 않습니다. 이로 인해 일부 플랫폼에서는 소스 코드로부터 직접 빌드해야 할 수도 있고, 타사 라이브러리의 지원이 중단되기 시작할 수도 있습니다. 이 단계의 시작을 긴장을 풀 때가 아니라 업그레이드를 계획해야 할 시점으로 삼으십시오.

파이썬의 일반적인 보안 문제

아래에 나열된 취약점들은 웹 애플리케이션, 데이터 파이프라인, 내부 도구 등 다양한 곳에서 발견됩니다. 일부는 개발자가 직접 통제할 수 있는 코딩 오류입니다. 다른 일부는 개발자가 직접 선택하지 않은 의존성을 통해 유입되는데, 후자의 경우 간과하기 더 쉽습니다.

소나타입(Sonatype)의 2024년 공급망 보고서에 따르면, 애플리케이션 종속성 중 80%는 1년 이상 업그레이드되지 않은 채 방치되고 있으며, 취약점이 있는 구성 요소가 포함되는 경우의 95%에서는 이미 수정된 버전이 존재한다는 사실을 밝혀냈습니다. 많은 경우 문제는 제로데이 취약점이 전혀 아닙니다. 이미 수정된 버전이 준비되어 있는 알려진 CVE인 경우가 대부분입니다.

안전하지 않은 역직렬화

신뢰할 수 없는 출처에서 피클 데이터를 불러오면 원격 코드 실행이 발생할 위험이 있습니다. pickle.load() 는 인스턴스화되는 즉시 코드를 실행하는 객체를 포함하여 임의의 파이썬 객체를 아무런 제한 없이 재구성해 냅니다. yaml.load() 도 안전하지 않은 로더를 사용할 경우 마찬가지입니다. 신뢰할 수 없는 YAML의 경우, yaml.safe_load()를 사용해야 하며, 신뢰할 수 없거나 인증되지 않은 데이터에는 pickle을 전혀 사용하지 마십시오.

동적 실행을 통한 주입

eval() 및 exec() 는 공격자가 제어하는 문자열을 실행 가능한 파이썬 코드로 변환합니다. 매개변수가 지정되지 않은 SQL은 메커니즘은 다르지만 동일한 유형의 문제로, 이 경우 입력은 프로그램이 아닌 쿼리의 구조를 재구성합니다. 매개변수를 바인딩하는 대신 f-string을 사용하여 쿼리를 형식화하는 것이 바로 여기서 흔히 발생하는 실수입니다. 규칙은 단순하지만 효과적입니다. 신뢰할 수 없는 입력을 코드, 셸 명령어 또는 SQL에 절대로 삽입하지 마십시오.

취약점이 있는 의존성 및 악의적인 의존성

일반적인 프로젝트는 긴 전이적 트리를 포함하며, 해당 트리 내의 어떤 패키지든 알려진 CVE를 포함하고 있거나 합법적인 패키지를 노골적으로 사칭한 것으로 드러날 수 있습니다. 타이포스쿼팅과 의존성 혼동은 현재 잘 알려진 공급망 공격 패턴입니다. TuxCare가 작성한 리눅스 채굴 프로그램이 실행 중인 것으로 적발된 세 가지 PyPI 패키지에 대한 에 대한 TuxCare의 분석 보고서는 실제 환경에서 이러한 현상이 어떻게 나타나는지 보여줍니다.

단순한 안내 이메일보다는 능동적인 보호 기능을 원하신다면, Python용 SecureChain은 는 공개 PyPI 저장소를, 악성코드 검사를 거치고 지속적으로 패치가 적용되는, 소스 코드에서 재컴파일된 검증된 대체 저장소로 교체합니다.

아카이브 처리에서의 경로 탐색

아카이브 압축 해제 시, 구성 요소 경로를 신중하게 처리하지 않으면 경로 탐색 위험이 발생할 수 있습니다. 이는 ../ 를 포함하는 멤버 이름은 파일을 의도한 디렉터리 외부로 저장할 수 있기 때문입니다. 파이썬의 tarfile 모듈에서는 이 문제가 CVE-2007-4559로 추적된 문제이며, 추출 필터 메커니즘이 도입되기 전까지 10년 넘게 표준 라이브러리에 남아 있었습니다.

지원 종료된 Python 실행하기

이 문제는 코드 버그라기보다는 일정상의 문제입니다. 지원 종료 시점을 훨씬 넘긴 Python 2로 구동되는 레거시 서비스는 레거시 서비스는 업스트림에서 보안 패치를 제공받지 못하므로, 마이그레이션을 수행하거나 확장 지원을 받지 않는 한 해당되는 모든 CVE는 미해결 상태로 남아 있습니다. 재작성이 현실적인 경우, Python 2에서 3으로 마이그레이션하는 것 것이 진정한 해결책입니다.

TuxCare의 Python에 대한 지속적인 라이프사이클 지원 이는 당분간 임시 방편으로 활용될 수 있습니다. 이 서비스는 Python 2.7 및 3.3부터 3.13까지의 릴리스가 지원 종료 시점을 지난 후에도, 사용자가 이미 사용하고 있는 패키지 관리자를 통해 CVE 패치를 지속적으로 제공합니다.

파이썬은 어디에나 있는데, 그 자체가 위험 요소 중 하나입니다

파이썬의 광범위한 사용 범위야말로 보안 부채가 누적되는 주된 원인입니다. 파이썬을 기반으로 구축된 시스템은 대개 코드가 방대하고 핵심 업무 부하를 담당하는 경우가 많아, 사소한 변경조차도 운영에 차질을 빚을 위험이 있기 때문에 버전 마이그레이션이 다음 분기로 미뤄지곤 합니다. 이러한 지연이 지원이 중단된 런타임 환경이 여전히 운영 환경에 남아 있는 큰 이유입니다.

Django는 트래픽이 많은 수많은 사이트를 구동하고 있으며, Django 1.11은 Python 2를 지원하는 마지막 릴리스였고, 2.0부터는 Python 2 지원이 완전히 중단되었습니다. Flask 역시 2.0 버전에서 Python 2 지원을 중단했습니다. 만약 사이트가 여전히 두 프레임워크 중 Python 2 시대의 릴리스에 의존하고 있다면, 지원되는 마이그레이션 경로나 보안 패치를 제공할 다른 출처가 필요합니다.

AI 및 머신러닝 분야에서 TensorFlow, pandas, scikit-learn은 모두 Python API를 제공하지만, 내부적으로는 최적화된 C, C++ 또는 Cython에 크게 의존하고 있습니다. 이처럼 광범위하게 배포된 라이브러리에 취약점이 존재할 경우, 수많은 하위 애플리케이션에 영향을 미칠 수 있습니다.

DevOps 분야에서는 Ansible, Mercurial, Buildbot, SCons 등이 파이썬으로 작성되었거나 파이썬과 긴밀하게 연동되어 있으며, 기업용 플랫폼인 Tryton이나 Odoo와 같은 경우 가동 중단 시 막대한 비용이 발생하는 대규모 배포 환경에서 운영되고 있습니다.

파이썬 애플리케이션 보안을 위한 모범 사례

이런 문제들 중 상당수를 차단하는 데 별도의 보안 팀이 필요하지는 않습니다. 대신, 몇 가지 습관을 자동으로 적용해 사람의 기억에만 의존하지 않도록 해야 합니다. 목표는 예방, 즉 결함이 있는 코드가 배포되지 않도록 하는 것과, 어쩔 수 없이 문제가 슬쩍 빠져나갔을 때 신속하게 수정하는 것입니다.

의존성 고정 및 감사

다음 파일에서 종속성 버전을 고정하세요 requirements.txt에 의존성 버전을 명시하거나, 패키지 관리자의 잠금 파일을 사용하여 매번 동일한 방식으로 의존성을 해결하도록 하세요. 그런 다음 커밋할 때마다 해당 파일을 스캔하세요.

pip-audit 및 Safety CLI와 같은 도구는 취약점 데이터베이스와 의존성을 대조하여 검사하며, 일치하는 항목을 발견하면 0이 아닌 반환값을 반환합니다. 덕분에 취약점이 발견되면 CI 작업이 실패하게 됩니다. Safety의 기존 check 명령어는 더 이상 사용되지 않으며, 대신 safety scan로 대체되었다는 점을 알아두는 것이 좋습니다.

전문가 팁: pip-audit는 취약점을 발견하면 이미 0이 아닌 종료 코드를 반환하므로, pip-audit -r requirements.txt 를 실행하면 문제가 프로덕션 환경에 반영되는 것을 막고 CI 작업이 실패하도록 할 수 있습니다. –strict 옵션을 추가하면, 의존성 수집 과정에서 오류가 발생했을 때도 감사가 실패하도록 할 수 있습니다.

모든 입력값을 검증하고 정제하기

양식 입력란, API 페이로드, 파일 업로드, 아카이브 내용 등 모든 외부 입력을 기본적으로 신뢰할 수 없는 것으로 간주하십시오. 데이터베이스에는 매개변수화된 쿼리를, 파일 경로에는 허용 목록을, 직렬화된 데이터에는 안전한 로더를 사용하십시오. 실제로는 다음과 같이 처리해야 합니다. yaml.safe_load() 를 사용해야 하며, 신뢰할 수 없거나 인증되지 않은 데이터는 절대 언피클링해서는 안 됩니다.

정적 분석 실행

정적 분석은 위험한 패턴이 제품에 반영되기 전에 이를 포착합니다. Bandit은 널리 사용되는 파이썬 전용 정적 분석 도구로, 하드코딩된 비밀번호, 보안 검사에 사용되는 assert 문, 안전하지 않은 subprocess 호출 등을 감지합니다. 린터와 함께 실행하면 보안 검사가 별도의 번거로운 작업이 아닌, 일상적인 개발 과정의 일부가 됩니다.

파이썬과 관련 라이브러리를 최신 패치로 유지하세요

업데이트되지 않은 패키지는 알려진 취약점이 계속 악용될 수 있는 흔한 원인입니다. 런타임, 표준 라이브러리 및 종속성을 포괄하는 체계적인 패치 적용 절차를 통해 공격자가 노릴 수 있는 기회를 줄일 수 있습니다. 취약점 패치와 위험 추적이 명확히 구분되지 않는다고 느껴진다면, 다음의 패치 관리와 취약점 관리의 차이점에 대한 이 분석 에 대한 이 분석 자료를 읽어보시기 바랍니다.

실행 시 최소 권한 원칙 적용

서비스를 루트 사용자가 아닌 계정으로 실행하고, 파일 및 네트워크 권한을 엄격하게 제한하며, 디버그 모드가 활성화된 상태로 절대 배포하지 마십시오. 공격자가 코드 실행에 성공하더라도, 최소 권한 원칙을 준수했는지에 따라 사고가 통제 가능한 수준에 그칠지, 아니면 매우 힘든 한 주를 보내게 될지가 결정됩니다.

파이썬 보안 위험을 완화하는 방법

모범 사례는 ‘좋은 모습’이 어떤 것인지 알려줍니다. 완화 전략은 실제 처리해야 할 업무가 쌓여 있는데 시간이 충분하지 않을 때, 순서대로 작업을 처리해 나가는 방식입니다. 영향이 가장 큰 것부터 차례대로 처리해 나가세요.

1단계: 실제로 운영 중인 시스템을 파악하기

보이지 않는 것은 보호할 수 없습니다. 소프트웨어 BOM(자재 명세서)을 생성하여 직접적 및 전이적 종속성의 전체 목록과 더불어 모든 환경의 정확한 Python 버전을 파악하세요.

2단계: 알려진 CVE와 대조하여 검사하기

해당 인벤토리 정보를 스캐너(Pip-Audit, Safety CLI 또는 플랫폼 도구 등)에 입력하고, 설치된 각 패키지와 버전을 알려진 취약점 공지와 대조해 보세요. 그러면 “문제가 있을 수도 있다”는 막연한 우려를 우선순위가 매겨지고 해결 가능한 목록으로 전환할 수 있습니다.

주의: 직접적인 요구 사항만 반영한 인벤토리는 전이적 취약점을 간과할 수 있습니다. 결과를 신뢰하기 전에, 사용 중인 도구가 전체 의존성 트리를 해결하거나 기록하는지 확인하십시오.

3단계: 심각도뿐만 아니라 악용 가능성에 따라 우선순위를 정하세요

배포 환경에서 접근할 수 없는 코드의 CVSS 점수가 높다고 해서, 대외용 API를 통해 노출된 중등도 심각도의 버그보다 자동으로 더 높은 순위를 차지하는 것은 아닙니다. 심각도는 접근 가능 여부와 실제 악용 사례와 같은 맥락을 종합적으로 고려하여 판단해야 합니다. 다음은 CVE 및 CVSS 점수 산정 방식에 대한 이 입문서 이 입문서는 무턱대고 패치를 적용하는 대신 우선순위를 효과적으로 결정하는 데 도움이 됩니다.

4단계: 패치 적용 후 확인

수정 사항을 적용한 후, 실제로 적용되었는지 확인하십시오. 스캐너와 테스트 스위트를 다시 실행하십시오. Python 의존성부터 그 기반이 되는 Linux 패키지에 이르기까지 스택 전반에 걸쳐 동일한 원칙이 적용됩니다. 검증 없이 패치를 적용하는 것은 그저 희망사항에 불과하기 때문입니다.

5단계: 문제가 재발하지 않도록 자동화하기

사람들이 바빠지기 시작하면 수동 패치 작업은 금세 소홀해지기 마련입니다. 정기적인 스캔을 예약하고, 의존성 업데이트를 위한 자동 풀 리퀘스트를 활성화하며, 보안 점검을 통과해야만 병합이 가능하도록 설정하세요. 패치 작업은 분기마다 급하게 처리하는 대응책이 아니라, 파이프라인처럼 체계적으로 운영되어야 합니다.

일반적인 파이썬 보안 취약점(CVE)

이것들은 표준 라이브러리나 널리 사용되는 패키지에서 실제로 할당된 CVE입니다. 그중 두 개는 setuptools에 포함되어 있습니다. 빌드 시점에 사용되는 도구는 팀들이 스캔하는 것을 자주 간과하는 반복적인 사각지대입니다. 아래 점수는 NVD CVSS v3.1 기준이며, 동일한 CVE에 대한 업스트림 또는 공급업체의 평가 점수가 때때로 다를 수 있으므로, 스캐너에 다른 수치가 표시되더라도 당황하지 마십시오.

tarfile의 경로 탐색 취약점 (CVE-2007-4559)

다음 파일의 디렉터리 탐색 취약점: tarfile.extract() 및 extractall() 함수에서 발생하는 디렉터리 트래버설 취약점으로 인해, 특수하게 조작된 아카이브가 .. 를 사용하여 대상 디렉터리 외부에 파일을 작성할 수 있게 합니다. Trellix는 2022년에 이 문제를 업계에 다시 제기했으며, 자체 스캔 결과의 수동 표본 분석에서 61%의 취약점을 확인하여 35만 개 이상의 취약한 오픈소스 저장소가 존재할 것으로 추정했습니다. Python 3.12에서는 PEP 706을 통해 추출 필터가 추가되었습니다. 3.12 및 3.13 버전에서는 기존 동작이 여전히 기본값으로 설정되어 있으며, 필터가 전달되지 않을 경우 DeprecationWarning이 발생하므로 코드는 filter='data' 또는 다른 적절한 필터를 전달해야 더 안전한 처리를 받을 수 있습니다. 파이썬 3.14에서는 data 를 기본값으로 설정했습니다.

더 안전한 기본값이 도움이 되기는 하지만, 아카이브 추출 위험을 완전히 제거하는 것은 아닙니다. 2025년 6월에 출시된 CPython 일괄 릴리스(3.9.23, 3.10.18, 3.11.13, 3.12.11 및 3.13.4 포함)에서는 데이터 및 tar 필터가 조작된 심볼릭 링크와 하드 링크를 통해 우회될 수 있는 여러 취약점을 수정했으며, 이는 CVE-2024-12718, CVE-2025-4138, CVE-2025-4330, CVE-2025-4435 및 CVE-2025-4517으로 추적됩니다. Python의 tarfile 문서에서는 여전히 어떤 필터도 아카이브의 모든 위험한 기능을 차단할 수는 없다고 경고하고 있으므로, 필터를 하나의 보안 계층으로만 간주하고, 포인트 릴리스를 최신 상태로 유지하며, 압축 해제 과정에서 생성된 파일과 경로를 반드시 확인해야 합니다.

참고할 점: 2007년에 이 결함이 처음 보고되었을 때, 즉각적인 대응 조치로 추출 동작을 변경하기보다는 문서에 경고를 추가하는 방식이 채택되었습니다. 더 안전한 기본 설정은 문제가 처음 보고된 지 약 18년이 지난 Python 3.14에서야 비로소 도입되었습니다.

urllib.parse의 차단 목록 우회 취약점 (CVE-2023-24329)

특정 공백 문자로 시작하는 URL은 urllib.parse를 기반으로 구축된 차단 목록 검사를 우회할 수 있습니다. 이는 파서가 유효성 검사 전에 앞부분의 공백 문자를 제거하지 않기 때문입니다. 해당 파싱 방식에 의존하는 모든 SSRF 방지 기능이나 URL 필터는 이로 인해 무력화될 수 있습니다. 이 문제는 Python 3.11.4에서 수정되었으며, 3.10.12, 3.9.17, 3.8.17 및 3.7.17 버전으로 역이식되었습니다.

setuptools의 원격 코드 실행 취약점 (CVE-2024-6345)

The package_index 69.1.1 버전까지의 setuptools에 포함된 `package_index` 다운로드 헬퍼는 os.system() 를 사용하여 셸 명령을 생성하므로, 공격자가 제어하는 패키지 URL이 명령어 실행으로 이어질 수 있습니다. 이 문제는 setuptools 70.0에서 수정되었습니다. 대부분의 팀은 빌드 도구가 의존성보다는 인프라로 분류되는 경우가 많기 때문에, setuptools 자체를 고정하거나 스캔해야 한다는 생각을 전혀 하지 않습니다.

Pillow의 임의 코드 실행 취약점 (CVE-2023-50447)

Pillow 10.1.0 버전까지는 PIL.ImageMath.eval()의 환경 매개변수를 통해 임의 코드 실행이 가능합니다. 이 취약점은 단순히 사용자가 제공한 이미지를 처리하는 것뿐만 아니라, 공격자가 제어하는 값이 해당 매개변수에 도달하는지에 따라 발생 여부가 결정됩니다. Pillow 10.2.0에서는 평가 환경이 접근할 수 있는 범위를 제한하여 이 문제가 수정되었습니다.

setuptools의 경로 탐색(CVE-2025-47273)

두 번째 setuptools 취약점은 PackageIndex.download에서 발생하는 경로 탐색(path traversal) 결함입니다. 대상 경로는 os.path.join()를 사용하여 생성되는데, 이 함수는 공격자가 조작한 파일 이름이 슬래시나 드라이브 문자로 시작할 경우 임시 디렉터리를 무시합니다. 이로 인해 실행 중인 프로세스가 권한을 가진 곳이라면 어디에나 파일이 작성될 수 있으며, 상황에 따라 코드 실행으로 이어질 수 있습니다. 이 문제는 setuptools 78.1.1에서 수정되었습니다. easy_install 와 package_index모두 더 이상 사용되지 않게 되어 취약점 노출 범위는 좁아졌지만, 1년 내에 동일한 빌드 도구에서 두 건의 결 모두 사용 중단되어 취약점 노출 범위는 좁아졌지만, 1년 이내에 동일한 빌드 도구에서 두 건의 결함이 발견된 점은 런타임 종속성뿐만 아니라 툴체인 전체를 점검해야 한다는 점을 상기시켜 줍니다.

TuxCare로 파이썬 애플리케이션의 보안을 유지하세요

파이썬 보안에서 어려운 점은 해결 방법을 아는 것이 아닙니다. 즉각적인 마이그레이션이나 서비스에 차질을 빚는 애플리케이션 업그레이드를 강요하지 않으면서도 런타임, 표준 라이브러리 및 의존성 라이브러리에 패치를 지속적으로 적용하는 것입니다. 버전이 지원 종료(EOL)에 도달해 업스트림 패치 제공이 중단되는 순간, 이러한 격차는 더욱 벌어집니다.

TuxCare는 이 문제의 양쪽 측면을 모두 해결합니다.

“업그레이드가 필요하지만”과 “지금은 운영 환경을 중단할 수 없다”는 두 가지 고민 사이에서 갈팡질팡하는 팀을 위해, Python용 Endless Lifecycle Support는 는 Python 2.7 및 3.3부터 3.13까지의 릴리스 버전에 대해, 해당 버전의 지원 종료 후에도 필요한 기간 동안 지속적으로 보안 패치를 제공합니다. 강제 마이그레이션 일정은 없으며, 업스트림 지원이 종료된 후에도 CVE 패치 제공이 계속됩니다.

pip를 통해 어떤 패키지가 설치되는지 걱정되는 팀을 위해, SecureChain for Python은 는 공개 PyPI 저장소를 검증되고 소스 코드에서 재빌드된 대안으로 대체합니다. 패키지는 사용자의 환경에 도달하기 전에 악성코드 검사를 거치며, 업스트림 관리자가 유지보수를 중단한 후에도 오랫동안 패치 업데이트가 지속됩니다. 동일한 패키지, 동일한 워크플로우를 유지하면서도 맹목적인 신뢰는 필요 없습니다.

요약

기사 이름

파이썬 보안 문제: 일반적인 위험 요소 및 대응 방안

설명

가장 흔한 파이썬 보안 문제와 그로 인한 위험, 그리고 파이썬 애플리케이션과 시스템을 안전하게 보호하기 위한 모범 사례에 대해 알아보세요.

작성자

로한 티말시나

게시자 이름

TuxCare

게시자 로고