llm-security

2 개의 포스트

cloudflare4분 읽기큐레이션 요약

프로젝트 글래스윙: Mythos가 우리에게 보여준 것

Mythos Preview는 단순히 취약점을 찾아내는 수준을 넘어, 여러 취약점을 연결해 실제 공격 경로를 구성하고 실행 가능한 증명 코드까지 생성하는 새로운 단계의 보안 도구로 평가된다. 그러나 모델의 자발적 거부는 일관되지 않으며, 탐색적 모델의 높은 오탐률 때문에 대규모 운영에는 별도의 안전장치와 검증·분류 체계가 필요하다. Project Glasswing의 핵심 교훈은 강력한 모델 자체뿐 아니라 이를 통제하고 결과를 검증하는 아키텍처가 함께 발전해야 한다는 점이다. ## Mythos Preview가 달라진 점 - Cloudflare는 Project Glasswing의 일환으로 Mythos Preview를 50개가 넘는 자체 저장소에 적용했다. - 이전 범용 프런티어 모델과의 단순한 성능 비교보다, Mythos가 실제로 수행하는 작업의 성격을 이해하는 것이 중요하다고 설명한다. - 기존 모델도 개별 버그를 발견하거나 영향도를 분석할 수 있었지만, 여러 조각을 하나의 공격으로 연결하는 단계에서 자주 멈췄다. ## 여러 취약점을 연결하는 공격 체인 - 실제 공격은 하나의 버그가 아니라 여러 취약점과 공격 원시 기능을 조합해 완성되는 경우가 많다. - 예를 들어: - use-after-free를 임의 메모리 읽기·쓰기 기능으로 전환 - 제어 흐름 탈취 - ROP(Return-Oriented Programming) 체인 구성 - 최종적으로 시스템 제어권 획득 - Mythos Preview는 낮은 심각도로 분류될 만한 개별 버그들을 결합해 더 심각한 실제 공격 경로를 추론할 수 있었다. - 이러한 추론 과정이 자동화된 스캐너보다는 숙련된 보안 연구자의 작업에 가깝게 나타났다는 점이 두드러졌다. ## 반복 실행을 통한 익스플로잇 증명 - Mythos Preview는 의심되는 취약점을 설명하는 데 그치지 않고, 이를 재현하는 코드를 직접 작성한다. - 생성한 코드를 격리된 scratch 환경에서 컴파일하고 실행해 예상한 동작이 발생하는지 확인한다. - 실패하면 오류 결과를 분석하고 가설을 수정한 뒤 다시 시도한다. - 이 반복 루프를 통해 단순한 “취약할 가능성”과 실제 악용 가능한 취약점을 구분한다. - 따라서 취약점 탐지와 익스플로잇 가능성 입증 사이의 간극을 모델 스스로 줄일 수 있다. ## 정당한 보안 연구에서의 모델 거부 - Project Glasswing에서 제공된 Mythos Preview에는 일반 공개 모델에 적용되는 추가 안전장치가 없었지만, 모델 자체적으로 일부 요청을 거부하는 경향이 나타났다. - 그러나 거부 기준은 일관되지 않았다. - 동일한 코드라도 실행 환경의 사소한 변화에 따라 연구를 허용하거나 거부했다. - 심각한 메모리 버그를 확인한 뒤에도 시연용 익스플로잇 작성은 거부할 수 있었다. - 요청 표현을 바꾸거나 실행 시점을 달리하면 반대 결과가 나오기도 했다. - 이러한 자발적 안전장치는 실제로 존재하지만, 확률적이고 상황 의존적이므로 단독 안전 경계로 사용할 수 없다. - 향후 공개되는 강력한 사이버 보안 모델에는 통제된 연구 환경 밖에서도 사용할 수 있도록 별도의 안전장치가 필요하다. ## 신호 대 잡음 문제와 오탐 - 보안 취약점 분석에서 가장 어려운 일 중 하나는 발견된 문제가 실제인지, 악용 가능한지, 즉시 수정해야 하는지를 판별하는 것이다. - AI 스캐너와 AI가 생성한 코드의 확산은 이 문제를 더욱 악화시켰으며, Cloudflare는 여러 후속 검증 단계를 구축해 대응하고 있다. ### 프로그래밍 언어의 영향 - C와 C++는 메모리를 직접 제어할 수 있어 다음과 같은 취약점이 발생하기 쉽다. - 버퍼 오버플로 - 경계 밖 읽기·쓰기 - 메모리 수명 관리 오류 - Rust와 같은 메모리 안전 언어는 이러한 버그 유형의 상당수를 컴파일 시점에 제거한다. - 실험에서는 메모리 비안전 언어로 작성된 프로젝트에서 오탐이 일관되게 더 많이 발생했다. ### 모델의 탐색 편향 - 숙련된 사람은 발견 내용과 함께 확신 수준을 명확히 제시하지만, 모델은 코드에 문제가 없어도 문제를 찾으려는 경향이 있다. - 결과에는 “가능성이 있다”, “잠재적으로”, “이론상 가능하다”와 같은 추측성 표현이 많이 포함된다. - 탐색 단계에서는 이런 보수적·과잉 탐지 성향이 유용할 수 있다. - 하지만 실제 트리아지 큐에서는 각각의 추측성 결과를 사람이 검증하고 기각해야 하므로, 수천 건으로 확장될 경우 인력과 모델 토큰 비용이 크게 누적된다. ## 실용적인 결론 Mythos Preview 같은 모델은 취약점 후보 발굴을 넘어 공격 체인 구성과 재현 증명까지 수행할 수 있어 보안 연구의 생산성을 크게 높일 수 있다. 다만 결과를 그대로 신뢰해서는 안 되며, 격리된 실행 환경, 다단계 검증, 신뢰도 기반 우선순위화, 일관된 안전 정책을 함께 구축해야 대규모 운영에 적합하다.

원문 읽기(새 탭에서 열림)
line원문

안전은 기본, 비용 절감은 덤: AI 서비스에 별도 가드레일이 필요한 이유 (새 탭에서 열림)

AI 가드레일은 모델의 오동작을 막는 필수 안전장치이지만, 단순히 시스템 프롬프트에 규칙을 심는 방식은 모델 본연의 성능 저하와 예기치 못한 부작용을 초래할 수 있습니다. 시스템 프롬프트는 규칙의 위치나 미세한 수정에 따른 출력 변동성에 매우 민감하기 때문에, 모델 외부에서 입출력을 검증하는 별도의 가드레일 체계를 구축하는 것이 보안과 서비스 안정성 측면에서 더욱 효율적입니다. ### 시스템 프롬프트 기반 가드레일의 과도한 거절 문제 * 시스템 프롬프트에 강력한 안전 규칙을 부여하면, 모델이 전체적으로 보수적인 태도를 취하게 되어 무해한 질문까지 거절하는 위양성(False Positive) 확률이 높아집니다. * 연구 결과에 따르면 안전 프롬프트 추가 시 전체 쿼리의 임베딩이 '거절' 방향으로 이동하며, "Python 프로세스를 죽이는(kill) 방법"과 같은 기술적인 질문조차 위험한 요청으로 오인하여 거절하는 패턴이 관찰됩니다. * 이는 보안 강도와 사용자 경험(정상적인 답변 수신) 사이의 트레이드오프를 심화시켜 모델의 유용성을 떨어뜨리는 원인이 됩니다. ### 프롬프트 위치 및 순서에 따른 위치 편향(Position Bias) * LLM은 긴 컨텍스트 안에서 처음과 끝부분의 정보는 잘 인식하지만, 중간에 위치한 정보는 간과하는 'Lost in the Middle' 현상을 보입니다. * 여러 제약 조건이 섞여 있는 경우, 가드레일 규칙이 시스템 프롬프트의 어느 지점에 위치하느냐에 따라 모델이 해당 규칙을 지키는 가중치가 달라집니다. * 실험 결과에 따르면 난이도가 높은 제약을 앞쪽에 배치할 때 성능이 가장 좋으며, 가드레일 규칙이 중간이나 뒤로 밀려날 경우 보안 성능이 일정하게 유지되지 않는 불안정성을 보입니다. ### 미세한 수정이 유발하는 성능의 나비효과 * 시스템 프롬프트 내의 아주 사소한 변화(공백 추가, "감사합니다" 문구 삽입 등)만으로도 모델의 결정 경계가 이동하여 전체 예측 값의 10% 이상이 바뀔 수 있습니다. * 특히 출력 형식을 지정(JSON/XML)하거나 특정 탈옥 방지 문구를 섞는 행위가 모델의 내부 추론 경로를 완전히 바꾸어, 일부 작업에서 성능이 급락하는 '재앙적인 수준의 붕괴'가 발생하기도 합니다. * 안전 규칙, 스타일, 형식 등 수십 줄의 요구사항을 하나의 시스템 프롬프트에 담을 경우, 한 줄의 수정이 모델이 어떤 규칙을 우선시할지에 대한 예측 불가능한 변화를 일으킵니다. ### 별도 가드레일 적용을 통한 보완과 추천 * 모델 본연의 성능을 유지하면서도 안전성을 확보하기 위해서는 모델 앞뒤에 독립적인 보안 게이트(별도 가드레일)를 세우는 방식이 효과적입니다. * 사용자의 입력 단계에서 위험을 감지해 차단(Tripwires)하거나 안전하게 재작성(Rewriter)하여 전달하고, 모델의 응답 후에도 다시 한번 결과를 점검하는 다층 방어 체계를 구축해야 합니다. * 이를 통해 시스템 프롬프트의 복잡도를 낮추고, 보안 정책의 수정이 모델의 전체 성능(추론 로직)에 직접적인 영향을 주지 않도록 분리하는 것이 실무적으로 권장됩니다.