리눅스 서버 보안 실전 정리: 다층 방어 체계 구축하기

목차

 

들어가며

리눅스(Linux, 서버 환경에서 가장 널리 쓰이는 운영체제) 서버는 클라우드와 웹 백엔드,

 

컨테이너(container, 애플리케이션을 격리해 실행하는 가상 단위)의 기반을 이루며 그만큼 공격의 표적이 된다.

 

2026년 현재 침해 사고의 60퍼센트 이상이

 

복잡한 제로데이(zero-day, 공개되거나 고쳐지기 전에 악용되는 알려지지 않은 취약점)가 아니라

 

잘못된 설정에서 비롯되는 것으로 보고된다.

 

공격은 자동화되어, 취약한 서버를 찾아 악용하기까지 걸리는 시간이 몇 주가 아니라 몇 시간 단위로 줄었다.

 

이런 환경에서 단일한 방어선 하나에 의존하는 방식은 더 이상 전략이 아니라 요행에 가깝다.

 

다층 방어(Defense in Depth, 여러 겹의 통제를 쌓아 한 겹이 뚫려도 다음 겹이 막는 설계)는

 

실패를 전제하고 그 실패를 견디게 만드는 접근이다.

 

이 글은 네트워크 경계, 호스트와 운영체제, 애플리케이션 코드, 데이터와 탐지의 네 계층으로 나누어 실무 통제를 정리한다.

경계는 가장 먼저, 가장 좁게

UFW 기본 차단: 열린 포트 하나가 곧 입구다

UFW(Uncomplicated Firewall, 우분투 계열에서 방화벽 규칙을 다루는 관리 도구)는

 

리눅스 커널(kernel, 운영체제의 핵심부) 방화벽을 쉽게 설정하도록 돕는 계층이다.

 

방화벽의 기본 정책은 들어오는 모든 연결을 차단하고 필요한 포트만 명시적으로 여는

 

화이트리스트(whitelist, 허용한 대상만 통과시키는 목록) 방식이어야 한다.

 

이 기본 차단(default deny) 정책에서 인바운드(inbound, 외부에서 서버로 들어오는 방향)는 원칙적으로 막히고 예외만 허용된다.

 

열려 있는 포트 하나하나가 공격자가 시도할 수 있는 입구이므로,

 

포트 수를 줄이는 것은 공격 표면(attack surface, 공격자가 노릴 수 있는 진입 지점의 총량)을 줄이는 것과 같다.

 

쓰지 않는 서비스와 포트를 닫는 작업은 가장 적은 노력으로 가장 큰 노출을 제거하는 조치에 해당한다.

 

방화벽은 다층 방어의 가장 바깥 경계로서, 안쪽 계층이 처리해야 할 트래픽 자체를 미리 걸러 낸다.

비표준 포트: 방어가 아니라 자동 공격 회피다

SSH(Secure Shell, 서버에 원격 접속하는 표준 프로토콜)의 기본 포트는 22번으로 널리 알려져 있다.

 

인터넷에는 22번 포트만 골라 자동으로 두드리는 봇(bot, 사람 대신 작업을 반복하는 자동화 프로그램)이 상시 돌아다니므로,

 

포트를 바꾸면 이런 1차 스캔의 표적에서 벗어난다.

 

다만 포트 변경은 그 자체가 강력한 방어가 아니라,

 

자동화된 공격의 소음을 줄이는 보조 수단(security through obscurity, 은폐를 통한 보안)에 가깝다.

 

실제 신원 검증은 뒤에서 다룰 공개키 인증(공개키와 개인키 쌍으로 신원을 증명하는 방식)이 담당하고,

 

포트 변경은 인증 로그를 깨끗하게 유지하는 역할을 한다.

 

포트를 바꿀 때는 방화벽에서 새 포트를 먼저 열어 두어야 접속이 끊기는 사고를 피할 수 있다.

 

따라서 비표준 포트는 단독 대책이 아니라 다른 통제와 함께 쓰일 때만 의미가 있다.

fail2ban: 무차별 대입을 로그에서 읽어 끊는다

fail2ban(인증 로그를 감시해 공격 IP를 자동으로 차단하는 도구)은 반복되는 로그인 실패를 탐지하는 데 쓰인다.

 

같은 주소가 정해진 시간 안에 실패 횟수를 넘기면, 도구는 방화벽 규칙을 추가해 해당 주소를 일정 기간 차단한다.

 

이 방식은 가능한 값을 끝없이 시도하는 무차별 대입(brute force, 비밀번호 등을 반복 입력해 뚫는 공격)을 자동으로 끊어 낸다.

 

다만 fail2ban은 로그에 남은 실패만 보고 차단하므로,

 

여러 주소에 나누어 들어오는 분산 공격(distributed attack, 다수의 IP로 분산해 가하는 공격)은 막지 못한다.

 

인터넷에 노출된 SSH 서버는 정상적인 운영 중에도 끊임없는 접속 시도를 받기 때문에 이 도구의 효용이 크다.

 

차단 기준과 기간은 운영 환경에 맞추어 조정하되, 정상 사용자가 함께 막히지 않도록 균형을 잡아야 한다.

원격 접근은 VPN과 IP 제한으로: ISMS-P 2.6.6의 요구

관리 목적의 원격 접속은 인터넷 전체에 열어 두지 않고, 승인된 주소에서만 들어오도록 제한하는 것이 원칙이다.

 

VPN(Virtual Private Network, 외부와 서버 사이에 암호화된 통로를 만드는 가상 사설망)을 거치면

 

관리 접속을 내부망 안으로 들여올 수 있다.

 

방화벽에서 접속 출발지를 특정 IP(Internet Protocol address, 인터넷에서 기기를 식별하는 주소) 대역으로 좁히면,

 

자격 증명(credentials, 로그인에 쓰이는 인증 정보)이 유출되어도 접속 가능한 위치 자체가 제한된다.

 

국내 기준인 ISMS-P(정보보호 및 개인정보보호 관리체계) 2.6.6 항목은 원격 접근을 원칙적으로 금지하고

 

불가피한 경우 IP 기반 통제를 요구한다.

 

같은 기준은 VPN을 상시 허용하지 않고 사용 승인과 접속 기간을 함께 제한하도록 명시한다.

 

결국 경계 계층의 목표는 누가, 어디서, 어떤 포트로 들어오는지를 모두 좁히는 데 있다.

기본 설정은 공격자를 위한 것이다

SSH 공개키와 MFA: 추측할 비밀번호를 없앤다

SSH 로그인에는 비밀번호 방식과 공개키 방식이 있으며, 공개키 방식이 더 안전하다.

 

공개키 인증은 비대칭 암호(asymmetric cryptography, 공개키와 개인키 한 쌍을 쓰는 암호 방식)를 써서,

 

개인키를 가진 사람만 서버가 낸 문제를 풀어 신원을 증명하게 한다.

 

설정에서 비밀번호 인증을 끄면(PasswordAuthentication no) 추측할 비밀번호가 사라져 무차별 대입 자체가 무의미해진다.

 

새 키는 ed25519(타원곡선 기반의 현대적 키 알고리즘)를 권장하며,

 

이는 기존 RSA(전통적으로 널리 쓰여 온 공개키 알고리즘) 방식보다 짧고 빠르면서 안전하다.

 

root 직접 로그인을 막고(PermitRootLogin no) 접속 가능한 계정을 지정하면 공격 표면이 한층 더 줄어든다.

 

여기에 MFA(Multi-Factor Authentication, 비밀번호 외에 추가 인증을 요구하는 다중 인증)를 더하면

 

키가 유출되어도 한 겹의 방어가 남는다.

최소 권한 원칙: root 직접 로그인부터 막는다

최소 권한 원칙(principle of least privilege)은 사용자와 프로세스에 꼭 필요한 권한만 부여하는 것을 뜻한다.

 

일상 작업은 일반 계정으로 수행하고, 관리 작업이 필요할 때만 sudo(권한을 일시적으로 상승시키는 명령)를 통해 처리한다.

 

root(시스템의 모든 권한을 가진 최상위 계정)로 직접 로그인하는 통로를 막으면, 한 번의 인증 실패가 전체 장악으로 이어지지 않는다.

 

쓰지 않는 계정과 과도한 권한은 내부 위협과 권한 상승(privilege escalation, 낮은 권한에서 높은 권한을 탈취하는 것)

 

공격의 통로가 되므로 정기적으로 정리해야 한다.

 

파일과 디렉터리 권한도 역할에 맞게 좁혀, 한 서비스가 침해되어도 접근 범위가 제한되도록 한다.

 

권한을 좁히는 작업은 침해의 발생 자체보다 침해가 번지는 범위를 줄이는 데 목적이 있다.

강제 접근 통제: SELinux와 AppArmor가 다른 점

일반적인 리눅스 권한은 파일 소유자와 그룹에 기반한 임의 접근 통제(DAC, Discretionary Access Control)이며,

 

root는 거의 모든 것을 할 수 있다.

 

이 한계를 보완하는 것이 강제 접근 통제(MAC, Mandatory Access Control)로,

 

프로세스가 root 권한을 얻어도 정해진 범위를 넘지 못하게 막는다.

 

두 방식은 모두 리눅스 보안 모듈(LSM, Linux Security Module)로 동작하지만 정책을 표현하는 방식이 다르다.

 

SELinux(Security-Enhanced Linux)는 모든 객체에 라벨을 붙여 통제하는 라벨 기반 방식으로, 세밀하지만 설정이 복잡하다.

 

AppArmor는 실행 파일의 경로에 프로파일을 붙이는 경로 기반 방식으로, 통제 범위는 좁지만 설정이 단순하다.

 

레드햇(Red Hat, 기업용 리눅스 배포판 계열) 계열은 SELinux를, 우분투 계열은 AppArmor를 기본 탑재하므로

 

배포판(distribution, 리눅스를 묶어 완성된 형태로 배포한 것)에 맞는 도구를 켜 두는 것이 출발점이다.

패치 자동화: 취약점은 몇 시간 만에 악용된다

운영체제와 패키지에는 공개된 취약점이 식별 번호와 함께 발표되며,

 

이를 CVE(Common Vulnerabilities and Exposures, 공개된 보안 취약점 식별 체계)라 한다.

 

공개된 취약점은 공격 코드(exploit, 취약점을 실제로 악용하는 코드)도 함께 퍼지는 경우가 많아,

 

패치하지 않은 시스템은 자동화 공격의 손쉬운 표적이 된다.

 

2026년에는 취약점 공개에서 악용까지 걸리는 시간이 몇 시간 단위로 짧아져, 수동 대응만으로는 따라잡기 어렵다.

 

우분투 계열의 unattended-upgrades(보안 업데이트를 자동으로 적용하는 기능) 같은 도구로 보안 패치를 자동화하는 것이 현실적이다.

 

커널 자체를 강화하고 불필요한 기능을 끄면, 알려지지 않은 취약점이 악용되더라도 피해 범위를 줄일 수 있다.

 

여기에 rkhunter 같은 루트킷(rootkit, 시스템에 숨어 권한을 유지하는 악성코드) 탐지 도구를 병행하면 은폐된 침입을 발견할 수 있다.

방화벽은 코드 속 구멍을 막지 못한다

접근 통제와 SSRF: OWASP가 2025년 둘을 합친 이유

서버를 아무리 단단하게 만들어도, 애플리케이션 코드 자체의 결함은 방화벽이 막지 못한다.

 

웹 보안의 표준 참고 자료인 OWASP(Open Worldwide Application Security Project) Top 10에서

 

접근 통제 실패는 2025년에도 1위 위험이다.

 

접근 통제 실패는 사용자가 권한 없는 데이터나 기능에 접근하게 되는 결함으로, 가장 흔한 침해 원인으로 꼽힌다.

 

2025년 개정에서 SSRF(Server-Side Request Forgery, 서버가 공격자가 지정한 주소로 대신 요청을 보내게 만드는 공격)는

 

접근 통제 범주로 통합되었다.

 

SSRF는 특히 클라우드에서 내부 메타데이터 주소(metadata endpoint, 클라우드가 내부 설정과 자격 정보를 알려 주는 특수 주소)를

 

호출시켜 자격 증명을 빼내는 경로로 악용되므로, 도착지 주소를 검증해야 한다.

 

권한 검사는 화면이 아니라 서버에서 매 요청마다 수행되어야 하며,

 

허용 목록(allowlist, 미리 허가한 대상만 통과시키는 방식)으로 외부 요청을 통제해야 한다.

경로 순회와 주입: 사용자 입력은 적이다

경로 순회(Path Traversal, 파일 경로에 상위 디렉터리 기호를 끼워 의도하지 않은 파일에 접근하는 공격)는

 

입력 경로를 검증하지 않을 때 발생한다.

 

공격자는 정상 파일 이름 대신 상위 경로 기호를 넣어 시스템 파일을 읽어 내려 시도한다.

 

주입(Injection, 사용자 입력이 코드나 질의의 일부로 실행되도록 조작하는 공격)도 같은 뿌리에서 나오는 위험이다.

 

대표적으로 SQL 인젝션(데이터베이스에 명령을 보내는 질의문을 조작하는 공격)과

 

XSS(Cross-Site Scripting, 페이지에 악성 스크립트를 심는 공격)가 여기에 속한다.

 

방어의 원칙은 모든 외부 입력을 신뢰하지 않고,

 

정규화(normalization, 입력을 표준 형태로 정리하는 것)와 허용 목록으로 검증한 뒤에만 사용하는 것이다.

 

입력값을 질의나 경로에 직접 잇지 않고 분리해 다루는 것이 이 계열 공격을 막는 공통 해법이다.

JWT의 함정: payload는 암호화가 아니라 인코딩이다

JWT(JSON Web Token, 로그인 후 발급하는 인증 토큰)는

 

헤더와 페이로드(payload, 토큰에 담기는 정보 부분), 서명 세 부분을 점으로 이은 문자열이다.

 

페이로드에는 사용자 정보가 담기고 서명으로 위변조를 검증하므로, 서버가 세션을 따로 저장하지 않아도 신뢰를 확인할 수 있다.

 

다만 페이로드는 암호화가 아니라 단순 인코딩(encoding, 내용을 숨기지 않고 형식만 바꾸는 변환)이어서,

 

누구나 디코딩해 그 내용을 읽을 수 있다.

 

따라서 비밀번호나 민감 정보를 페이로드에 담아서는 안 되며, 만료 시간을 반드시 설정해야 한다.

 

서명 알고리즘을 none으로 허용하는 설정은 위변조를 그대로 통과시키므로 차단해야 한다.

 

비밀키는 안전하게 보관하고 주기적으로 교체하여, 토큰 위조의 근거 자체를 보호해야 한다.

전송과 구성 보안: TLS, CORS, 시크릿 관리

TLS(Transport Layer Security, 통신 구간을 암호화하는 전송 계층 보안)는 전송 중 데이터의 도청과 변조를 막는다.

 

HSTS(HTTP Strict Transport Security, 브라우저가 항상 암호화 연결만 쓰도록 강제하는 정책)와

 

CSP(Content Security Policy, 허용된 출처의 자원만 불러오게 하는 정책) 같은 보안 헤더를 함께 적용한다.

 

CORS(Cross-Origin Resource Sharing, 다른 출처의 요청을 허용할지 정하는 규칙)는 그 자체가 방어가 아니라,

 

어떤 출처에 자원을 열어 줄지 통제하는 설정이다.

 

허용 출처를 별표(wildcard, 모든 출처를 뜻하는 기호)로 열고 인증 정보까지 허용하면 아무 사이트나 사용자 권한으로 접근할 수 있으므로,

 

출처를 명시적으로 좁혀야 한다.

 

보안 설정 실패는 OWASP 2025에서 2위로 올라설 만큼 흔한 위험이며, 잘못 구성된 헤더가 그 대표 사례다.

 

비밀번호와 API(Application Programming Interface, 프로그램끼리 연동하는 창구) 키 같은 시크릿(자격 증명)은

 

코드에 직접 박지 않고 환경 변수(environment variable, 코드 밖에서 값을 주입하는 설정)나 별도 저장소로 분리하여

 

버전 관리(version control, 코드 변경 이력을 추적하는 시스템)에 노출되지 않게 한다.

뚫린다고 가정해야 살아남는다

저장 데이터 암호화: 디스크가 통째로 빠져나가도

다층 방어는 언젠가 한 겹이 뚫린다는 전제 위에서 가장 안쪽의 자산을 따로 보호한다.

 

저장 데이터 암호화(at-rest encryption, 디스크에 저장된 상태의 데이터를 암호화하는 방식)는

 

디스크가 통째로 유출되어도 내용을 읽지 못하게 한다.

 

리눅스에서는 LUKS(Linux Unified Key Setup, 리눅스의 디스크 암호화 표준)로 디스크 단위 암호화를 적용할 수 있다.

 

학습 데이터에 선수 영상처럼 개인을 식별할 수 있는 정보가 포함되면 개인정보보호법의 적용 대상이 된다.

 

국내 개인정보보호법은 개인정보를 저장하고 전송할 때 암호화 등 안전성 확보 조치를 갖추도록 요구한다.

 

따라서 저장 데이터 보호는 기술적 선택이 아니라 법적 의무로도 다루어야 한다.

모델 가중치 보호: pickle 대신 SafeTensors

AI 모델의 가중치(weights, 학습으로 얻어진 모델의 핵심 수치 자산) 파일은 유출되면 그대로 복제될 수 있는 핵심 자산이다.

 

파이토치(PyTorch, 널리 쓰이는 딥러닝 라이브러리)의 기본 저장 포맷인

 

pickle(파이썬 객체를 파일로 저장하는 직렬화 모듈)은 파일을 불러올 때 임의의 코드가 실행될 수 있는 구조다.

 

이 위험 때문에 파이토치는 2.6 버전에서 모델을 불러올 때 코드 실행을 막는 안전 모드를 기본값으로 바꾸었다.

 

더 근본적인 대안은 코드를 담을 수 없는 SafeTensors(텐서, 즉 모델이 다루는 수치 배열만 안전하게 저장하는 포맷)를 쓰는 것이다.

 

가중치는 코드와 분리해 저장하고, 신뢰할 수 없는 출처의 모델 파일은 그대로 불러오지 않는 것이 원칙이다.

 

또한 모델 파일은 크고 형식이 뚜렷하여, 네트워크 단에서 무단 반출을 탐지하기에 비교적 유리하다.

AI 공급망 점검: 5배 늘어난 악성 모델과 AIBOM

공개 모델 저장소가 악성코드 유포 경로가 되면서,

 

AI 공급망(supply chain, 소프트웨어가 만들어져 전달되기까지의 전체 경로) 보안은 코드 공급망 못지않게 중요해졌다.

 

한 연구는 공개 저장소에 올라오는 악성 모델의 수가 한 해 사이 약 5배로 늘었다고 보고한다.

 

악성 pickle을 잡아내는 대표 검사 도구에서도 2025년 말 우회가 가능한 심각도 높은 취약점 세 건이 공개되었다.

 

따라서 검사 도구 하나에 의존하기보다,

 

모델과 데이터의 출처와 해시(hash, 데이터를 고정 길이의 고유 값으로 바꾼 지문)를 검증하는 절차를 함께 두어야 한다.

 

AIBOM(AI Bill of Materials, AI 시스템을 구성하는 모델과 데이터의 명세)은 어떤 구성요소가 들어왔는지 추적하는 근거가 된다.

 

모델 갱신을 코드 배포와 동일한 검토 절차로 다루는 것이, 공급망을 통한 침입을 줄이는 실질적 방법이다.

로그 중앙화와 무결성 감시: Wazuh와 FIM

보이지 않는 위협은 막을 수 없으므로, 다층 방어의 마지막 축은 기록과 감시다.

 

시스템과 애플리케이션이 남기는 접속과 인증, 오류 로그를 한 곳에 모아야 사고를 사후에 추적할 수 있다.

 

OWASP 2025도 로깅과 알림의 실패를 독립된 위험으로 다루며, 기록만 있고 알림이 없으면 가치가 낮다고 지적한다.

 

Wazuh(오픈소스 보안 모니터링 플랫폼)는 호스트(host, 서버 같은 개별 시스템) 기반 침입 탐지와

 

로그 분석, 파일 무결성 감시를 한데 묶어 제공한다.

 

파일 무결성 모니터링(FIM, File Integrity Monitoring)은 중요한 설정 파일이 무단으로 바뀌면 이를 즉시 알린다.

 

인증 로그를 모니터링 시스템으로 보내, 새 주소에서의 로그인 실패나 설정 파일 변경에 경보를 거는 것이 효과적이다.

침입 탐지와 정기 취약점 점검: Suricata에서 자동 스캔까지

호스트 기록만으로는 부족하므로, 네트워크를 흐르는 트래픽(traffic, 네트워크를 오가는 데이터)도 함께 들여다보아야 한다.

 

Suricata(오픈소스 네트워크 위협 탐지 엔진)는 실시간으로 트래픽을 분석하는

 

침입 탐지 시스템(IDS, Intrusion Detection System)이자 침입 차단 시스템(IPS, Intrusion Prevention System)이다.

 

네트워크 탐지의 경보를 앞서 말한 모니터링 플랫폼으로 모으면, 호스트 정보와 합쳐 사고의 맥락을 빠르게 파악할 수 있다.

 

새로운 취약점은 끊임없이 공개되므로, 점검은 한 번으로 끝나지 않고 정기적으로 반복해야 한다.

 

의존성 라이브러리(dependency, 프로그램이 가져다 쓰는 외부 코드)와 컨테이너,

 

웹 애플리케이션을 주기적으로 스캔하여 알려진 취약점을 미리 찾아내야 한다.

 

마지막으로 백업과 복구 절차를 갖추고 복원을 실제로 시험해 두어야,

 

침해나 랜섬웨어(ransomware, 데이터를 암호화해 잠그고 금전을 요구하는 악성코드) 이후에도 운영을 되살릴 수 있다.

나가며

리눅스 서버 보안은 한 가지 도구나 한 번의 설정으로 끝나는 작업이 아니다.

 

네트워크 경계에서 공격 표면을 좁히고, 호스트와 운영체제를 단단하게 만들며, 코드와 데이터를 보호하는 통제가 겹겹이 쌓여야 한다.

 

각 계층은 독립적으로 완벽하지 않으며, 한 겹이 뚫렸을 때 다음 겹이 피해를 막는다는 전제에서 의미를 가진다.

 

AI 서버라면 모델 가중치와 공급망이라는 새로운 자산과 경로가 더해져, 보호 대상의 범위가 한층 넓어진다.

 

설정은 시간이 지나며 어긋나므로, 정기적인 점검과 기록, 그리고 빠른 대응이 이 모든 통제를 살아 있게 한다.

 

결국 견고한 서버는 한 번 만드는 것이 아니라 계속 유지하고 다듬어 가는 상태에 가깝다.

참고 자료

[다층 방어·리눅스 하드닝]

• Linux Security in 2026: Hardening, Monitoring and Defense (LinuxSecurity): https://linuxsecurity.com/news/server-security/linux-security-hardening-best-practices
• Linux System Hardening: The Complete Guide (SUSE): https://www.suse.com/c/linux-hardeningthe-complete-guide-to-securing-your-systems/
• Ubuntu Server Security Best Practices 2026: https://www.howto-do.it/ubuntu-server-security-best-practices-2026/
• Linux Server Security Hardening 20-Point Checklist (VistoShield): https://vistoshield.com/blog/linux-server-security-hardening-checklist

[SSH·접근 통제]

• SSH Hardening: Ed25519 Keys and Disabling Root Login (DEV): https://dev.to/jonesrussell/ssh-hardening-ed25519-keys-and-disabling-root-login-50di
• SSH and SCP in 2026: Hardening (DEV): https://dev.to/matheus_releaserun/ssh-and-scp-in-2026-configuration-security-hardening-and-advanced-tips-8nm
• SSH Hardening Guide: Best Practices (Linuxize): https://linuxize.com/post/ssh-hardening-best-practices/
• SSH Hardening 2026: Complete Guide (ZeonEdge): https://zeonedge.com/blog/ssh-hardening-2026-complete-guide-linux-server

[강제 접근 통제 SELinux/AppArmor]

• AppArmor vs SELinux (TuxCare): https://tuxcare.com/blog/selinux-vs-apparmor/
• AppArmor vs SELinux (AppArmor 공식): https://apparmor.net/about/apparmor_vs_selinux/
• How to Choose Between AppArmor and SELinux on Ubuntu (OneUptime): https://oneuptime.com/blog/post/2026-03-02-how-to-choose-between-apparmor-and-selinux-on-ubuntu/view

[OWASP·애플리케이션 보안]

• OWASP Top 10:2025 Introduction (OWASP 공식): https://owasp.org/Top10/2025/0x00_2025-Introduction/
• What Changed in OWASP Top 10 2025 (Qualys): https://blog.qualys.com/qualys-insights/2026/06/15/what-changed-in-owasp-top-10-2025-and-recommendations-for-each-category
• OWASP Top 10 2025: What Changed (Parasoft): https://www.parasoft.com/blog/owasp-top-10/

[AI 모델·공급망 보안]

• BC-Breaking: torch.load weights_only=True 기본값 전환 (PyTorch Dev): https://dev-discuss.pytorch.org/t/bc-breaking-change-torch-load-is-being-flipped-to-use-weights-only-true-by-default-in-the-nightlies-after-137602/2573
• Pickle Vulnerability in AI/ML Pipelines (Fortra): https://www.fortra.com/blog/supply-chain-vulnerability
• Malicious AI Model Repositories (Cloud Security Alliance): https://labs.cloudsecurityalliance.org/research/csa-research-note-malicious-ai-model-repositories-attack-sur/
• 3 Zero-Day PickleScan Vulnerabilities (JFrog): https://jfrog.com/blog/unveiling-3-zero-day-vulnerabilities-in-picklescan/
• AI Model Supply Chain and Training Data Poisoning (CISO Marketplace): https://cisomarketplace.com/blog/ai-model-supply-chain-training-data-poisoning-open-source-risk

[탐지·대응 Wazuh/Suricata]

• SIEM-Based IDS Using Wazuh and Suricata with ELK (GitHub): https://github.com/Humoria/SIEM-Based-Intrusion-Detection-System-Using-Wazuh-and-Suricata-Integrated-with-ELK-Stack
• How to Integrate Wazuh with Suricata (Softstrix): https://softstrix.com/how-to-integrate-wazuh-with-suricata-for-better-threat-detection/

[한국 컴플라이언스]

• ISMS-P 2.6.6 원격접근 통제 인증기준: https://meganad.github.io/ISMS-P/CERT/2.6.6
• ISMS-P 제도소개 (KISA): https://isms.kisa.or.kr/main/ispims/intro/
• 주요정보통신기반시설 기술적 취약점 분석·평가 상세 가이드 (KISA): https://www.kisa.or.kr/2060204/form?postSeq=12&lang_type=KO&page=1