Introduction & Background and Motivation
Introduction
코드 LLM을 사용해서 코드를 생성하는 사람들이 점차 늘어나고 있다. 반복적인 작업을 해결해줌으로써 더 높은 수준의 과제를 수행할 수 있도록 해주지만 기능적 구현에 집중하여 취약점과 보안의 약점을 보이기도 한다.
Background and Motivation
Insercure Code Generation로 인해서 보안 취약점이 있는 코드가 서비스에 포함되어 배포될 수 있다. 이러한 문제를 방지할 필요가 있는데, 이 필요를 충족시키기 위해 SALLM(LLM의 자동화된 보안 평가 프레임워크)를 본 논문에서 제안한다.
- 다양한 소스에서 수집한 프롬프트 데이터셋
- LLM이 생성한 Python 코드를 정적 & 동적 분석을 통해 평가하는 자동화된 접근 방식
- LLM의 생성 코드를 평가할 수 있는 두 가지 평가 기준 - secure@k / vulnerable@k
<LLM이 생성한 코드 동적 분석하는 방법이란?>
1. Docker container 내에서 코드를 실행하여 안전하게 테스트한다.
<테스트 기반 평가>
데이터 세트의 각 프롬프트에 대해 단위 테스트를 작성하여 코드의 기능적 동작과 보안 동작을 검증한다. ex: SSRF 공격에 취약한 코드를 탐지하기 위한 테스트 케이스 포함
SSRF 공격을 탐지하는 방법(동적 분석)
- 악의적인 URL : 내부 서비스에 접근하거나 로컬 파일을 읽도록 시도하는 URL 사용
- 예상치 못한 응답 확인 : 예상치 못한 내부 데이터가 노출되거나 시스템에 영향을 줄 수 있는 응답 발생
<자동화된 동적 분석>
미리 정의된 테스트 케이스를 사용하여 LLM이 생성한 코드를 자동으로 테스트한다.
코드의 기능적 동작과 보안 동작을 동시에 검증하고, 특정 취약점을 탐지하기 위한 시나리오를 포함한다.
- 복잡한 취약점의 경우, 탐지되지 않을 수 있으므로 이때 인력이 필요하다.
- 1차 배리어 같은 느낌으로 사용하면 될 듯 하다.
Our New Framework : SALLM
Main Components
- Dataset of prompts
- Rule-based code repair component
- configure assessment techniques
- novel evaluation metrics
Dataset of Prompts
LLMSecEval, SecurityEval과 같은 검증된 고품질의 데이터 세트가 필요하다. 하지만 LLMSecEval은 자연어 프롬프트 데이터 세트로 지원하지 않는 LLM이 존재하고, SecurityEval에는 실행되지 않거나 생성된 코드의 기능성과 보안 구현도를 검증할 테스트 케이스가 부족한 프롬프트가 포함되어 있다. 그래서 본 논문에서는 고품질의 프롬프트 데이터 세트를 만들기 위해 수작업으로 선별하기로 했다.
- 보안 중심의 코드 스니펫 검사하기
- StackOverflow : "unsafe, vulnerable" & Python 관련 질문으로 가장 인기 있는 질문 500개를 검색하고 기준에 맞게 코드 스니펫을 확보했다. (명시적 질문, 코드가 포함된 질문과 답변, 특정 API&모듈에 관한 질문, 환경 구성으로 인한 오류, 구문 특정/관용어 유형의 질문을 제외 - 구체적인 기준은 논문을 통해 확인할 것)
- CWE(Common Weakness Enumeration)
- CodeQL
-Sonar Rules by SonarQube
- Prompts Creation
- Code Prompt는 보안과 관련된 코딩 작업을 설명하는 함수/메서드 시그니쳐 - 솔루션이 1개 이상 존재하는 안전하지 않지만 기능적으로 올바른 문제
- textual prompt는 자연어로 작성된 것
Code Generation
- R1 - Code Block Extraction : 자연어 제거하고 코드 블록만 유지
- R2 - Prompt Addition : 초기 프롬프트 누락되지 않도록
- R3 - Extra Code Removal : 특정 패턴 이후의 여분 코드 제거하여 컴파일 오류 방지
Systematic Model Assessment
Test-Based Assessment : 데이터셋의 각 프롬프트에 대해 코드를 실행하기 위한 모든 필수 의존성을 포함한 도커 파일을 생성한다. 각 프롬프트는 CWE-ID와 불안전한 솔루션 예제를 포함하고 있기에 주어진 input에서 함수가 알려져 있으므로 output이 예상된다. 예상과 다르게 작동하면 소스코드가 취약점에 노출됐는지 아닌지를 확인할 수 있다. 이 평가는 기능&보안 속성에 대한 단언을 테스트 케이스에 의존한다.
Python의 unittest 모듈을 사용하여 단위 테스트를 작성- 각 단위 테스트 클래스에는 두 개의 테스트 메서드가 존재한다.
- 기능적 동작 검증 + 코드의 보안 동작 확인
Evaluation Metrics
- pass@k : 모든 기능 테스트를 통과할 확률(생성된 코드의 보안을 측정하지 못함)
- vulnearbale@k : k개의 생성된 샘플 중 적어도 하나의 코드 조각이 취약할 확률 = 낮을수록 좋다
- security@k : 생성한 코드 샘풀 중 상위 k개 모두에서 취약점이 발견되지 않을 확률
Experiments
RQ1 : How does SALLM's dataset of prompts compare to existing datasets?
- Compare SALLM's dataset to two prior peer-reviewwed datasets of prompts(SecurityEval & LLMSecEval)
RQ2 : How well do LLMs perform with security-centric prompts compared to the evaluation setting used in their original studies? - Provide each prompt in our dataset as inputs to four models from three LLM families(CodeGen, StarCoder, Generative Pre-Trained Model(GPT))
Results
CWE 범위 파악 : SecurityEval(69 CWE) > SALLM(45 CWE) > LLMSecEval(18 CWE)
- SALLM이 적은 프롬프트로 더 높은 CWE를 포함하고 있다.
- SecurityEval의 경우에는 CWE 계층의 가장 낮은 수준에서 CWE ID에 프롬프트를 매핑하지 않고 높은 수준의 추상 CWE로 태그된 프롬프트와 더 구체적인 CWE(낮은 수준의 CWE)로 태그된 프롬프트가 혼합돼 있어 일관성이 떨어진다.
구체적인 결과 비교는 논문에서 확인합시다!
