TOSSS: a CVE-based Software Security Benchmark for Large Language Models

이 논문은 CVE 데이터베이스를 기반으로 새로운 취약점이 지속적으로 통합될 수 있는 확장 가능한 벤치마크인 TOSSS 를 제안하여, 대규모 언어 모델이 보안과 취약한 코드 조각 중 올바른 선택을 할 수 있는 능력을 0 에서 1 사이의 점수로 평가하는 방법을 제시합니다.

핵심

🍎 1. 왜 새로운 시험이 필요한가요? (기존 방식의 문제점)

지금까지 AI 의 코딩 실력을 시험할 때는 주로 **"이 문제를 풀어봐"**라고 시켰습니다. (예: "은행 계좌를 만드는 코드를 짜봐")
그런 다음, 전문가나 자동 도구가 그 답안을 검사해서 "여기에 보안 구멍이 있네?"라고 찾아냈습니다.

하지만 이 방식에는 큰 문제가 있었습니다.

• 유연성 부족: 새로운 해킹 수법이 나오면, 그걸 검사할 수 있는 도구를 다시 만들어야 해서 시험을 업데이트하는 데 시간이 너무 걸립니다.
• 한계: 검사 도구가 모르는 새로운 종류의 해킹은 찾아내지 못합니다.

비유하자면:
마치 **요리사 (AI)**에게 "새로운 요리를 만들어봐"라고 시킨 뒤, 검열관이 그 요리를 맛보고 "이거에 독이 있네"라고 찾아내는 방식입니다. 하지만 독이 어떤 종류인지 검열관이 미리 알고 있어야만 찾을 수 있습니다. 새로운 독이 나오면 검열관은 당황하고 말죠.

---

🎲 2. TOSSS 의 새로운 방식: "A 와 B 중 고르세요"

저자들은 이 문제를 해결하기 위해 시험 방식을 완전히 바꿨습니다. AI 에게 코드를 만들게 하는 대신, 이미 만들어진 두 개의 코드를 보여주고 **"어떤 게 더 안전한가?"**를 고르게 한 것입니다.

TOSSS 의 핵심 원리:

1. 두 가지 옵션 제시: 같은 기능을 하는 코드가 두 개 있습니다. 하나는 안전한 코드 (A), 다른 하나는 **해킹 구멍이 있는 코드 (B)**입니다.
2. 선택 강요: AI 에게 "A 와 B 중 하나를 고르세요"라고 묻습니다. (보안 관련 질문을 하지 않고 그냥 고르게 하거나, "더 안전한 걸 고르세요"라고 힌트를 주기도 합니다.)
3. 점수 매기기: AI 가 안전한 코드를 얼마나 자주 맞혔는지 점수 (0~1) 로 줍니다.
   • 1 점: 항상 안전한 걸 고름 (명문 요리사).
   • 0.5 점: 그냥 무작위로 찍음 (운에 의존).
   • 0 점 미만: 오히려 위험한 걸 더 좋아함 (위험한 요리사).

이 방식의 장점:

• 무한한 확장성: 해킹 뉴스 (CVE) 에 새로운 구멍이 나오면, 그걸로 코드를 만들어 시험지에 넣기만 하면 됩니다. 도구를 다시 만들 필요 없이 자동으로 시험지를 업데이트할 수 있습니다.
• 명확한 결과: "A" 또는 "B"만 고르면 되므로, AI 가 엉뚱한 말을 하거나 형식을 틀리는 실수가 없습니다.

---

🔍 3. 실험 결과: AI 들은 얼마나 잘할까요?

저자들은 14 개의 유명한 AI 모델 (GPT, Claude, LLaMA 등) 을 이 시험에 붙였습니다. 결과는 다음과 같습니다.

• 성적표: 점수는 0.48 점부터 0.89 점까지 다양했습니다.
  • 0.89 점 (GLM-5 등): 거의 완벽한 안전 의식을 가진 모델들입니다.
  • 0.48 점 (Mistral 등): 거의 동전 던지기 수준 (무작위) 으로 고르는 모델도 있었습니다.
• 힌트의 효과: "이건 보안 문제야, 안전한 걸 고르라고!"라고 힌트를 주면 대부분의 AI 점수가 올랐습니다. 하지만 어떤 모델은 오히려 점수가 떨어지기도 했습니다. (너무 코딩에 집중하다 보니 보안 지시를 받으면 혼란을 느낀 것 같습니다.)
• 재미있는 사실: "코딩 전문 AI"라고 광고하는 모델들이 오히려 보안 점수가 낮았습니다. 기능이 잘 작동하는 코드를 만드는 것과 보안적인 코드를 만드는 것은 별개의 능력일 수 있다는 뜻입니다.

---

💡 4. 결론: 왜 이것이 중요한가요?

이 연구는 우리에게 중요한 메시지를 줍니다.

"AI 가 코드를 잘 짤 줄 안다고 해서, 안전한 코드를 짤 줄 아는 건 아닙니다."

TOSSS 는 마치 AI 의 '안전 의식'을 측정하는 체력 검사와 같습니다.

• 기존에는 AI 가 만든 코드를 뒤져서 문제를 찾았다면, 이제는 AI 가 스스로 안전한 것을 골라낼 수 있는지를 봅니다.
• 이 방식은 새로운 해킹 수법이 나올 때마다 자동으로 시험지를 업데이트할 수 있어, AI 의 보안 능력을 꾸준히 감시할 수 있는 완벽한 도구입니다.

한 줄 요약:

"AI 에게 '요리해봐'라고 시키기보다, '독이 든 음식과 안전한 음식 중 뭐가 안전해?'라고 물어보는 것이, AI 가 실제로 안전한 코드를 만들 수 있는지 더 정확하게 알아내는 지름길입니다."

이 연구는 앞으로 AI 를 사용할 때, 단순히 "코드가 잘 돌아가는지"만 확인하는 것이 아니라 **"보안 의식이 있는 AI 를 선택해야 한다"**는 경고를 주고 있습니다.

기술 요약

논문 요약: TOSSS (Two-Option Secure Snippet Selection)

1. 문제 제기 (Problem)

대형 언어 모델 (LLM) 이 소프트웨어 개발 워크플로우에 광범위하게 통합되면서, LLM 이 생성하거나 제안하는 코드의 보안성 (Security) 에 대한 우려가 커지고 있습니다. 기존 연구들은 LLM 이 생성한 코드에 보안 취약점이 다수 존재함을 확인했습니다. 그러나 LLM 의 소프트웨어 보안 능력을 평가하기 위한 기존 벤치마크들은 다음과 같은 한계를 가지고 있습니다.

• 확장성 부족 (Limited Extensibility): 대부분의 기존 벤치마크는 정적 분석기 (Static Analyzer) 에 의존하여 생성된 코드의 취약점을 탐지합니다. 이는 분석기가 지원하는 취약점 유형과 프로그래밍 언어에 제한을 받아, 새로 발견된 취약점 (CVE) 을 쉽게 반영하거나 새로운 언어를 지원하기 어렵습니다.
• 수동 검증의 비효율성: 일부 벤치마크는 수동 검증이나 커스텀 테스트 케이스 생성에 의존하여 확장성이 떨어지고 평가 편향이 발생할 수 있습니다.
• Ground Truth 부재: 코드 생성 태스크는 정해진 정답 (Ground Truth) 과 비교하기 어렵기 때문에, 보안 점수를 산출하는 데 모호함이 존재합니다.

따라서, 새로 발견된 취약점을 자동으로 통합할 수 있고, 확장 가능하며, 명확한 정답을 기반으로 한 LLM 보안 평가 벤치마크가 필요합니다.

2. 방법론 (Methodology)

저자들은 **TOSSS (Two-Option Secure Snippet Selection)**라는 새로운 벤치마크를 제안합니다. 이는 LLM 에게 코드를 생성하게 하는 것이 아니라, 동일한 기능을 수행하는 두 가지 코드 버전 (하나는 취약한 버전, 하나는 안전한 버전) 중 안전한 것을 선택하게 하는 '코드 선택 (Code Selection)' 태스크로 평가 방식을 전환했습니다.

• 데이터 구축 (CVE 기반):
  • CVE(Common Vulnerabilities and Exposures) 데이터베이스와 MegaVul 파이프라인을 활용합니다.
  • MegaVul 은 CVE 보고된 취약점에 대한 소스 코드의 '수정 전 (취약)'과 '수정 후 (안전)' 버전을 자동으로 추출합니다.
  • 이를 통해 LLM 에게 제시할 '취약한 코드 - 안전한 코드' 쌍을 자동으로 생성하며, 새로운 CVE 가 발표될 때마다 데이터셋을 확장할 수 있습니다.
• 평가 프로세스:
  • 모델에게 두 옵션 (A 와 B) 을 제시하고, 보안에 대한 힌트 유무에 따라 선택을 요구합니다.
  • 힌트 없는 설정 (Hintless): "두 버전 중 하나를 선택하라"고만 요청 (보안 의도가 명시되지 않음).
  • 힌트 있는 설정 (With Hint): "두 버전 중 가장 안전한 구현을 선택하라"고 명시적으로 요청.
  • 점수 산정: 모델이 안전한 코드를 선택한 비율 (0~1 사이). 1 은 항상 안전한 코드를 선택, 0.5 는 무작위 추측, 0.5 미만은 취약한 코드를 선호함을 의미합니다.

3. 주요 기여 (Key Contributions)

1. TOSSS 벤치마크 제안: CVE 기반의 자동화된 데이터 파이프라인을 활용하여, 새로운 취약점과 프로그래밍 언어를 쉽게 통합할 수 있는 확장 가능한 보안 벤치마크를 최초로 도입했습니다.
2. 코드 선택 패러다임 전환: 복잡한 코드 생성 및 정적 분석 의존성을 탈피하고, 명확한 Ground Truth(수정 전/후 코드 쌍) 를 기반으로 한 단순한 선택 태스크를 통해 평가의 일관성과 해석 가능성을 높였습니다.
3. 광범위한 모델 평가: C/C++ 및 Java 코드에 대해 14 개의 주요 오픈소스 및 클로즈드소스 LLM 을 평가하여 다양한 모델의 보안 능력 차이를 실증했습니다.
4. 오픈소스 공개: 재현성을 위해 TOSSS 벤치마크 코드와 데이터를 GitHub 에서 공개했습니다.

4. 실험 결과 (Experimental Results)

14 개의 모델 (GLM-5, GPT-5.4, Claude Opus, Mistral, LLaMA 등) 을 C/C++ 및 Java 로 평가한 결과는 다음과 같습니다.

• 성능 범위: 힌트 없는 설정에서 모델별 점수는 0.48 에서 0.89까지 다양하게 분포했습니다.
  • 상위 모델: GLM-5 (0.878), GPT-5.4 (0.866), Claude Opus 4.6 (0.864) 등이 높은 점수를 기록했습니다.
  • 하위 모델: Mistral Large 2512 (0.480) 는 무작위 추측 수준 (0.5) 에 근접하는 낮은 점수를 보였습니다.
• 힌트의 영향:
  • 대부분의 모델은 "가장 안전한 코드를 선택하라"는 명시적 힌트를 받으면 성능이 향상되었습니다 (평균 +0.021~0.029 증가).
  • 예외: Codestral 2508 과 같은 코딩 특화 모델은 힌트를 받으면 오히려 성능이 하락했습니다. 이는 코딩 특화 모델이 기능적 정확성이나 유창성에 최적화되어 있어, 보안 지시가 오히려 방해가 될 수 있음을 시사합니다.
• 언어별 차이: C/C++ 과 Java 간 평균 성능 차이는 크지 않았으나, C/C++ 데이터 양이 많아 일부 모델에서 C/C++ 점수가 약간 높았습니다.
• 모델 계열: 같은 계열의 모델 중 최신/대규모 모델 (예: Claude Opus 4.6 vs 3.5 Sonnet) 일수록 보안 능력이 더 뛰어났습니다.

5. 의의 및 결론 (Significance & Conclusion)

• 실무적 유용성: TOSSS 는 LLM 제공자들이 모델 리포트에 포함할 수 있는 보안 중심의 지표로 활용될 수 있습니다.
• 보안 능력의 본질: 많은 현대 LLM 은 보안에 대한 명시적 지시 없이도 안전한 코드를 어느 정도 식별할 수 있지만, 성능 편차가 큽니다. 또한, 코딩에 특화된 모델이 반드시 보안 코드를 잘 선택하는 것은 아님을 발견했습니다.
• 미래 방향:
  • 훈련 데이터 개선: 취약점이 수정된 최신 소스 코드로 학습 데이터를 정제하거나, CVE 기반의 특수 데이터셋으로 파인튜닝을 수행할 필요성이 제기됩니다.
  • 프롬프트 엔지니어링: 보안 관련 지시를 명시적으로 포함하는 것이 모델의 보안 능력을 발휘하는 데 도움이 됩니다.
  • 확장성: TOSSS 는 CVE 데이터베이스를 기반으로 하므로, 향후 새로운 언어와 취약점이 발견될 때마다 자동으로 벤치마크를 업데이트할 수 있어 지속 가능한 보안 평가 도구로 자리 잡을 것으로 기대됩니다.

결론적으로 TOSSS 는 LLM 의 소프트웨어 보안 능력을 평가하는 데 있어 기존 생성형 벤치마크의 한계를 극복하고, 확장 가능하고 해석 가능한 새로운 기준을 제시한 중요한 연구입니다.