coverage-analysis

coverage-analysis 개요

coverage-analysis skill은 퍼징 harness가 실제로 어디까지 실행하는지 측정하도록 도와주며, 낮은 커버리지가 약한 harness 때문인지, 완고한 parser 때문인지, 아니면 magic value 검사 같은 실제 차단 요소 때문인지 판단할 수 있게 해줍니다. 이 skill은 특히 보안 엔지니어, 퍼징 실무자, 그리고 Security Audit용 coverage-analysis 작업에서 “이 harness가 위험한 코드까지 도달하는가?”가 단순 실행량보다 중요한 리뷰어에게 가장 유용합니다.

이 skill의 용도

coverage-analysis skill은 harness 버전을 비교하거나, dead path를 찾아내거나, fuzzer가 의미 있는 진전을 내고 있는지 판단해야 할 때 사용합니다. 일반적인 코드 품질 검사 도구가 아니라, harness 품질을 판단하기 위한 의사결정 보조 도구입니다.

가장 잘 맞는 경우

이미 대상 바이너리, corpus, 또는 fuzzing 환경이 있고 coverage report를 근거로 판단하고 싶을 때 가장 잘 맞습니다. 단순히 감으로 빠르게 훑어보는 수준이라면 일반 프롬프트로도 충분할 수 있지만, 반복 가능한 coverage 해석이 필요하다면 이 skill이 구조를 더해줍니다.

무엇이 다른가

핵심 가치는 초점에 있습니다. coverage-analysis는 coverage를 신호로 해석하고, 막는 요소를 찾고, 그 신호를 바탕으로 harness를 개선하는 데 집중합니다. 워크플로우나 판단 기준 없이 일반 모델에게 그냥 “coverage를 분석해줘”라고 하는 것보다 훨씬 실용적입니다.

coverage-analysis skill 사용 방법

coverage-analysis를 깔끔하게 설치하기

GitHub 호스팅 skill pack을 사용할 때는 skills runner가 기대하는 설치 흐름을 따르세요. 예를 들면 npx skills add trailofbits/skills --skill coverage-analysis 같은 방식입니다. 설치 후에는 프롬프트를 작성하기 전에 agent 환경에서 이 skill을 사용할 수 있는지 확인하세요.

먼저 읽어야 할 파일을 제대로 읽기

먼저 워크플로우와 범위를 설명하는 SKILL.md를 읽고, 이어서 환경에서 노출되는 연결된 저장소 가이드를 확인하세요. 이 skill에서는 보통 핵심 정보가 메인 지침과 예시에 들어 있으므로, 스스로 coverage 절차를 만들어내기 전에 그 부분부터 읽는 것이 중요합니다.

모델에 coverage 맥락을 분명히 주기

좋은 coverage-analysis 사용 프롬프트에는 대상, 측정 방법, 그리고 내리고 싶은 결정을 함께 넣어야 합니다. 예를 들어 “LLVM sancov로 libpng fuzz harness의 corpus A와 corpus B를 비교해 coverage를 분석해줘. 어떤 변경이 도달 가능한 코드를 늘렸는지, 그리고 어떤 남은 branch가 magic-value blocker처럼 보이는지 알려줘.”처럼 쓰는 것이 좋습니다. 이렇게 하면 시스템, metric, 원하는 결과가 모두 명시되므로 단순히 “이 coverage report를 봐줘”라고 하는 것보다 훨씬 낫습니다.

일회성 질문이 아니라 워크플로우로 사용하기

실용적인 coverage-analysis 방식은 단계적으로 묻는 것입니다. 먼저 현재 coverage 상황을 요약하게 하고, 그다음 blocker를 찾게 한 뒤, harness 변경안을 제안하게 하고, 마지막으로 다음 실행 결과를 기준선과 비교하게 하세요. 이렇게 하면 출력이 행동으로 이어지며, fuzzing에서 coverage analysis를 하는 목적과도 정확히 맞아떨어집니다.

coverage-analysis skill FAQ

coverage-analysis는 fuzzing에만 쓰는 건가요?

대체로 그렇습니다. 이 skill은 일반적인 source-code review가 아니라 fuzzing harness의 효과와 진행 상황을 추적하는 데 맞춰져 있습니다. coverage를 fuzz target이나 보안 테스트 harness 개선에 쓰지 않는다면 적합도가 떨어집니다.

일반 프롬프트와 무엇이 다른가요?

일반 프롬프트도 coverage 수치를 설명할 수는 있지만, coverage-analysis skill은 그 수치를 fuzzing 맥락에서 해석하기 위한 더 촘촘한 워크플로우를 제공합니다. 나쁜 harness와 접근하기 어려운 코드 경로를 구분해야 할 때 특히 중요합니다.

전문가가 아니어도 사용할 수 있나요?

네, 다만 대상, harness, coverage source를 정확히 지목할 수 있을 만큼의 맥락은 필요합니다. 초보자는 보통 하나의 report, 하나의 baseline, 그리고 하나의 구체적인 질문을 함께 제공할 때 가장 좋은 결과를 얻습니다.

언제는 쓰지 않는 것이 좋나요?

실행 가능한 target이 없거나, coverage 데이터가 없거나, fuzzing setup을 개선할 의도가 없다면 coverage-analysis를 쓰지 마세요. 그런 경우에는 신호가 너무 적어서 신뢰할 만한 권고를 내기 어렵습니다.

coverage-analysis skill을 개선하는 방법

baseline과 delta부터 시작하기

가장 좋은 coverage-analysis 결과는 비교에서 나옵니다. harness 변경 전후, corpus A와 corpus B, 또는 현재 실행과 마지막 안정 버전의 비교처럼 말입니다. 하나의 report만 있다면, 모델에게 부족한 맥락을 짚어 달라고 하고 어떤 비교가 결론을 더 강하게 만드는지도 물어보세요.

의심되는 blocker를 함께 적기

이미 checksum, format check, auth gate, magic constant 같은 요소를 의심하고 있다면 그 사실을 명시하세요. 그러면 모델이 어디를 봐야 할지 좁힐 수 있고, 실제로 coverage가 정체된 것인지 의도된 gate 때문인지 구분하는 데 도움이 됩니다.

정확한 coverage source를 제공하기

데이터가 LLVM source-based coverage, SanitizerCoverage, gcov, 또는 다른 collector에서 나온 것인지 알려주고, 관련 경로나 report 발췌본도 함께 넣으세요. coverage-analysis는 퍼센트 숫자만 있는 것보다 측정 시스템과 연결될 때 훨씬 유용합니다.

report만 보지 말고 harness 변경을 반복하기

첫 답변은 진단으로 받아들이세요. 그다음 harness를 다시 실행하고, 새로운 coverage report를 수집한 뒤, 무엇이 바뀌었고 무엇이 여전히 진전을 막는지 다시 물어보세요. 그 피드백 루프가 바로 coverage-analysis skill이 Security Audit 워크플로우에서 진가를 발휘하는 지점입니다.