cpg-analysis

cpg-analysis 스킬 개요

cpg-analysis는 일반적인 저장소 훑어보기만으로는 부족할 때 쓰는 심층 코드 분석 스킬입니다. Joern CPG와 CodeQL을 활용해 제어 흐름, 데이터 흐름, 프로그램 의존성, taint 경로, 보안 이슈를 추적하고 판단하는 데 도움을 줍니다. 보안 리뷰를 하거나, 함수 간 버그를 추적하거나, 입력이 sink까지 어떻게 도달하는지 입증해야 한다면 cpg-analysis를 사용하세요.

최적의 활용처: 보안 감사와 흐름 추적

cpg-analysis는 Security Audit 작업에 특히 잘 맞습니다. “이 입력이 위험한 sink까지 도달할 수 있는가?” 또는 “여러 파일을 가로질러 source에서 sink까지 어떤 경로가 있는가?” 같은 질문에 답해야 할 때 유용합니다. 표면적인 코드 설명보다, 근거를 바탕으로 분석해야 하는 작업에서 가장 힘을 발휘합니다.

무엇이 다른가

일반적인 프롬프트와 달리 cpg-analysis는 그래프 기반 추론을 중심으로 설계되어 있습니다. AST로 구조를 보고, CFG로 실행 순서를 파악하며, 데이터 흐름 그래프로 전파 경로를 추적합니다. 실무적으로는 보안과 정합성 질문에 대한 추적성이 훨씬 좋아진다는 뜻입니다. 특히 단순한 grep이나 요약으로는 실제 경로를 놓치기 쉬운 대규모 코드베이스에서 차이가 큽니다.

설치할 가치가 있는 경우

깊은 정적 분석, taint 추적, 취약점 탐색을 반복해서 하게 될 때 cpg-analysis를 설치하세요. 빠른 코드 이동만 필요하다면, 1단계 메모리 도구로도 충분한 경우가 많고 실행 부담도 더 가볍습니다.

cpg-analysis 스킬 사용법

cpg-analysis를 설치하고 런타임을 확인하기

레포의 스킬 매니저로 cpg-analysis 스킬을 설치한 뒤, 사용할 경로에 필요한 런타임이 준비되어 있는지 확인하세요. Joern 기반 워크플로우는 보통 Docker와 JVM이 필요하고, CodeQL 기반 워크플로우는 CodeQL CLI가 필요합니다. 로컬이나 현재 환경에서 이런 도구를 실행할 수 없다면, 프롬프트가 아무리 좋아도 이 스킬의 활용 범위는 제한됩니다.

올바른 파일부터 시작하기

먼저 SKILL.md를 읽고, tier 선택 기준, Joern을 써야 하는 경우, 핵심 MCP 도구를 설명하는 섹션을 확인하세요. 이 부분을 먼저 보면 쿼리를 만들기 전에 어떤 분석 경로를 택해야 하는지 알 수 있습니다. 스킬이 특정 저장소 트리를 언급한다면, 기억에 의존해 추측하지 말고 그 맵을 먼저 따라가세요.

막연한 요청을 쓸 수 있는 프롬프트로 바꾸기

cpg-analysis를 잘 쓰는 방법은 단순히 “이 repo 분석해줘”가 아니라, 구체적인 분석 대상부터 정하는 데서 시작합니다. 다음 항목을 포함하세요:

• 저장소 또는 하위 디렉터리
• 알고 있다면 언어나 프레임워크
• 보안 질문 또는 버그 가설
• 관심 있는 source, sink, 또는 기능
• “런타임 실행 금지”, “auth 흐름에 집중” 같은 제약

프롬프트 형태 예시:
Use cpg-analysis to trace whether user-controlled input from the API reaches command execution in src/ without sanitization. Focus on interprocedural paths and show the key nodes and files.

단계적으로 작업하기

좋은 cpg-analysis 가이드는 보통 두 단계로 가장 잘 작동합니다. 먼저 관련 표면을 넓게 파악하고, 그다음 경로를 깊게 파고드는 방식입니다. 처음에는 진입점과 후보 sink를 찾을 만큼만 넓게 보고, 이후 실제 관련 함수나 파일로 좁히세요. 이렇게 해야 과도한 확신을 줄이고, 출력이 실제 데이터 흐름에 맞게 유지됩니다.

cpg-analysis 스킬 FAQ

cpg-analysis는 보안 작업에만 쓰나요?

아닙니다. 보안이 가장 분명한 적합 사례이긴 하지만, 버그 탐색, 실행 경로 추론, 복잡한 코드베이스에서 값이 어떻게 이동하는지 이해하는 데도 도움이 됩니다. 단순한 텍스트 일치보다 제어 흐름이나 데이터 흐름에 답이 달린 질문에서 특히 유용합니다.

매번 Joern과 CodeQL이 모두 필요한가요?

꼭 그렇지는 않습니다. 보통은 Joern이 CPG 기반 탐색의 첫 선택으로 더 적합하고, CodeQL은 interprocedural 보안 쿼리나 취약점 패턴을 다루고 싶을 때 더 강합니다. 기본값처럼 둘 다 돌리기보다, 질문에 맞는 도구를 고르세요.

cpg-analysis는 초보자도 쓰기 쉬운가요?

작업이 구체적이라면 초보자도 사용할 수 있습니다. 하지만 요청이 막연하면 분석도 막연해집니다. 파일명, 입력 source, 위험한 sink를 말할 수 있다면 cpg-analysis를 훨씬 더 잘 활용할 수 있습니다.

언제 cpg-analysis를 쓰지 말아야 하나요?

문서 조회, 기본적인 리팩터링 조언, 파일 하나에 대한 빠른 요약만 필요하다면 cpg-analysis를 굳이 선택하지 마세요. 설치 비용이 있는 스킬이므로, 그래프 기반 도구를 쓸 만한 깊이의 분석일 때 투자 가치가 있습니다.

cpg-analysis 스킬 개선 방법

분석 대상을 더 좁히기

가장 중요한 개선점은 범위를 좁히는 것입니다. “보안 이슈 찾아줘”는 너무 넓지만, “routes/의 request params가 exec나 SQL query construction까지 도달할 수 있는지 추적해줘”는 훨씬 좋습니다. source와 sink를 분명히 정의하면 cpg-analysis의 결과가 더 실행 가능해지고, 불필요한 탐색도 줄어듭니다.

중요한 제약을 함께 알려주기

환경에서 Docker가 막혀 있다면, 코드베이스가 polyglot이라면, 또는 정적 분석만 원한다면 처음부터 말하세요. 제약 조건은 가능한 워크플로우를 바꾸고, 실행할 수 없는 경로를 스킬이 제안하는 일을 막아줍니다. cpg-analysis 설치 여부를 판단할 때는 이런 정보가 유용함과 무용함을 가르는 경우가 많습니다.

결론보다 증거를 요청하기

반복해서 물을 때는 entry point, 중간 함수, 그래프 노드, 최종 sink까지의 체인을 요청하세요. 그래야 Security Audit 검토에서 중요한 추론 과정을 실제로 보여주게 됩니다. 첫 결과가 너무 넓다면, 다음에 보고 싶은 파일 집합이나 구체적인 query 타입을 지정해 더 좁히세요.

더 나은 가설로 다시 실행하기

첫 결과가 노이즈가 많다면, 일반적인 두 번째 시도를 요구하기보다 가설을 개선하세요. 예를 들어 “auth 문제 찾아줘” 대신 “test 코드와 mock은 제외하고, router에서 sensitive handler까지의 unauthenticated access를 추적해줘”라고 바꾸는 식입니다. 강한 가설일수록 더 신호가 높은 cpg-analysis 결과를 빠르게 얻을 수 있습니다.