대화로 이야기할 때 코드가 아닌 경우: 소프트웨어를 시뮬레이션하고 개발하는 LLM 에이전트 비교

LLMs는 honeypot처럼 네트워크 프로토콜 구현을 시뮬레이션하는 데 사용되기도 하고, 실제로 작성하는 데도 사용됩니다. 이전 연구들은 이 두 가지 용도를 별도로 평가해 왔습니다. 즉, 한 경우에서는 모델의 답변이나 대화에서, 다른 경우에서는 생성된 코드에서 각각 평가한 것입니다. 우리는 지식 탐색(knowledge probe) (모델에게 구현이 어떤 보안 검사를 필요로 하는지 묻는 것)과 대화를 통해 생성된 프로그램이 부족한 보안 검사 항목들을 식별할 수 있다는 것을 관찰했지만, 같은 모델이 작성하는 코드를 가지고 이 둘을 비교한 연구는 없었습니다. 이러한 격차를 해소하기 위해, 우리는 시뮬레이션 모드(S-mode) (모델이 대화 속에서 구현을 수행하는 방식)와 개발 모드(D-mode) (모델이 프로그램을 작성하고 프로그램에 공격이 가해지는 방식), 그리고 지식 탐색을 기준선으로 하는 최초의 비교를 제시합니다. 우리는 하나의 공격 스위트와 하나의 오라클로 이 세 가지를 모두 판단하는 하니스를 설계 및 구현했으며, 4가지 프로토콜 구현에 대해 15개의 LLM을 평가했습니다. 그 결과, 전체 보안 사양(full security specification)과 함께했을 때, 재조립(reassembly), HTTP, 방화벽 구현에서 두 모드 모두에서 중간 모델의 공격 성공률은 최대 4%였습니다. 하지만 DNS에서는 S-mode에서 13%, D-mode에서 15%를 기록했습니다. D-mode에서 누락된 DNS 요구 사항을 사양에 추가하면 해당 공격 성공률이 100%에서 34%로 떨어지며, 오직 그 검사 항목만 변경됩니다. 반면 명시된 규칙을 삭제하는 것은 다른 검사 항목에서도 프로그램의 취약점을 약화시킵니다. 모델에게 미리 물어보는 것만으로는 프로그램이 어떤 검사를 가지고 있는지 예측할 수 없습니다. 왜냐하면 DNS 리졸버를 작성하는 14개 중 13개의 모델이 해당 검사 항목을 언급하지만, 42개 프로그램 모두가 이를 갖추지 못했기 때문입니다. S-mode는 유용한 첫 번째 필터 역할을 하여 실제 DNS 취약점의 82%를 플래그 지정하고 안전한 케이스의 96%는 플래그 지정하지 않았습니다. 이는 양쪽 방향으로 오류를 범합니다. 즉, D-mode가 구현하지 않은 보안 검사를 과도하게 보고하고(over-reporting), D-mode가 보고한 검사 항목을 제대로 보고하지 못하는 경우(under-reporting)가 있습니다. S-mode는 스크리닝은 할 수 있지만 D-mode 테스트를 대체할 수는 없으며, 모델이 암송할 수 있더라도 보안 요구 사항은 문서로 작성되어야 합니다.