[Theori] 코드가 정상이라면, 정말 안전할까? | 비즈니스 로직 취약점이란

https://theori.io/ko/blog/what-are-business-logic-vulnerabilities

코드가 정상이라면, 정말 안전할까? | 비즈니스 로직 취약점이란 - Theori 블로그

---

비즈니스 로직 취약점이란?

코드 자체에 오류가 없더라도, 시스템이 설계된 비즈니스 규칙이 공격에 악용될 수 있다. 예를 들어 온라인 쇼핑몰 장바구니에 음수 수량을 입력하면, 코드는 정상적으로 계산을 수행하지만 결제 금액이 조작되어 부당한 카드 환불이 발생할 수 있다.

각각의 기능만 보면 문제가 없어 보이지만, 여러 기능과 규칙이 연결되는 과정에서 예상하지 못한 공격 경로가 만들어지는 유형의 취약점을 비즈니스 로직 취약점(Business Logic Vulnerability)이라고 한다.

 

1. 왜 기존 취약점 스캐너는 비즈니스 로직 취약점을 놓칠까?

대표적인 코드 분석 도구인 SAST(Static Application Security Testing)는 애플리케이션의 모든 코드를 정적으로 분석할 수 있지만, 기본적으로 규칙 기반(rule-based) 방식으로 동작하기 때문에 잘 알려진 안전하지 않은 패턴은 효과적으로 찾아낼 수 있지만 새롭게 등장한 패턴들은 찾을 수 없다.

또 다른 문제는 결과의 품질이다. 많은 코드 스캐너는 규칙에 맞지 않는 코드를 최대한 많이 찾아내는 방식으로 동작하기 때문에, 실제로 중요한 취약점과 그렇지 않은 항목이 뒤섞인 수백 개의 경고를 한 번에 출력한다. 이 때문에 보안팀이 진짜 위험한 이슈를 찾기 위해 방대한 양의 경고를 하나씩 검토해야 하는 비효율이 발생한다.

 

2. 사람이 직접 수행하는 모의해킹의 한계

전문 레드팀은 시스템의 맥락을 이해하고 공격 시나리오를 상상하는 데 강점이 있지만, 수십만 줄에서 수백만 줄에 이르는 코드베이스를 사람이 일일이 검토하는 것은 시간과 비용 측면에서 매우 부담이 크기 때문에 현실적인 한계가 있다.

결국 모든 코드를 완전히 점검하는 것은 사실상 불가능하고, 그 결과 코드베이스에는 충분히 검토되지 않은 영역이 남게 되며 이는 자연스럽게 보안의 사각지대로 이어진다.

 

3. 최신 AI 도구들도 아직은 역부족

Claude Code, Copilot, Gemini 같은 LLM 기반 도구들은 분명 코드 검토에 도움을 줄 수 있지만, 대부분은 한 번에 작은 코드 조각을 분석하거나 전체 코드를 대략적으로 살펴보는 수준에 머무르는 경우가 많다. 컨텍스트 윈도우의 제한 때문에 애플리케이션의 모든 코드를 동시에 깊이 있게 분석하기 어렵기 때문이다.

즉, 대규모 코드베이스 전체를 맥락 속에서 분석하려면 개발자가 직접 세세하게 질문을 던져야 하는 한계가 있다.

 

4. Xint: 인간처럼 이해하고 SAST처럼 확장하다

Xint는 수천 개의 AI 에이전트를 동시에 조율해 대규모 코드베이스를 병렬로 분석하며, 이를 통해 수백만 줄 규모의 코드베이스도 12시간 이내에 전체 분석을 완료할 수 있다.

단순한 패턴 기반 탐지를 넘어, 코드의 흐름과 기능 간 상호작용까지 분석해 비즈니스 로직이 실제 공격에 악용될 수 있는 지점을 찾아낸다. 이 분석 방식에는 티오리 보안 연구팀이 10년 이상 축적한 공격자의 관점이 반영되어 있다.

또한 Xint는 취약점을 나열하는 데 그치지 않고, Trigger / Impact 리포트 형태로 취약점이 실제로 어떻게 공격될 수 있는지, 그 영향이 무엇인지까지 함께 제공한다. Xint는 보안팀이나 레드팀을 대체하려는 도구가 아니라, 보안 전문가가 가진 판단력과 공격자 관점을 확장하는 역할에 가깝다.

결과적으로 Xint는 기존처럼 연 1~2회 수행되는 점검 중심의 AppSec에서 벗어나, 애플리케이션 전체를 지속적으로 검증하는 지속적인 보안 생태계를 가능하게 한다.

---

주요 키워드 개념 정리

1. 비즈니스 로직 취약점 (Business Logic Vulnerability)

코드 자체의 버그나 오류가 아닌, 서비스의 업무 규칙(business rule) 설계상의 허점을 악용하는 취약점. 각 기능은 정상적으로 동작하지만, 여러 기능을 조합하거나 입력값을 비정상적으로 활용했을 때 개발자의 의도와 다른 결과가 발생한다. 예) 음수 수량 입력, 순서 우회, 권한 범위 초과.

2. SAST (Static Application Security Testing)

소스 코드를 실행하지 않고 정적으로 분석해 취약점을 탐지하는 방법. 코드 자체의 패턴이나 구조를 규칙 기반으로 검사한다. 알려진 취약 패턴 탐지에 강하지만, 새로운 공격 패턴이나 기능 간 상호작용으로 발생하는 비즈니스 로직 취약점은 탐지하기 어렵다.

3. 규칙 기반 탐지 (Rule-based Detection)

보안 스캐너가 미리 정의된 규칙(패턴)과 코드를 매칭해 취약점을 찾는 방식. 빠르고 일관되지만, 규칙으로 정의되지 않은 새로운 형태의 취약점은 탐지하지 못한다는 근본적인 한계가 있다.

4. 레드팀 / 모의해킹 (Red Team / Penetration Testing)

실제 공격자의 관점에서 시스템을 공격해 취약점을 찾는 활동. 맥락 이해와 창의적 공격 시나리오 구성에 강점이 있지만, 대규모 코드베이스를 전수 검토하기엔 시간과 비용의 한계가 크다.

5. LLM 기반 도구 & 컨텍스트 윈도우 (Context Window)

GPT, Claude 등 대형 언어모델은 한 번에 처리할 수 있는 텍스트 분량(컨텍스트 윈도우)에 제한이 있다. 수백만 줄의 코드베이스를 동시에 전부 분석하는 것이 구조적으로 불가능하며, 이것이 LLM 기반 보안 도구의 핵심 한계다.

6. 대규모 병렬 분석 (Parallel Multi-Agent Analysis)

Xint가 채택한 방식으로, 수천 개의 AI 에이전트가 코드베이스를 동시에 분산 분석한다. 단일 모델의 컨텍스트 윈도우 한계를 극복하면서 인간 수준의 맥락 이해를 대규모로 확장할 수 있다.

7. AppSec (Application Security)

애플리케이션 수준의 보안 전반을 뜻하는 용어. 기존에는 주로 연 1~2회 정기 점검 방식으로 운영되었으나, 현대 개발 환경에서는 코드가 지속적으로 변경되기 때문에 지속적인(Continuous) AppSec으로 전환이 필요하다는 흐름이 있다.