보안 가이드 룰(기준선 + 실시간 인텔)을 키워드로 검색합니다.

특정 취약점 유형의 근거 규정·안전한 대안이 궁금할 때, 또는 스캔 결과의 rule_id 외에 관련 룰을 더 찾고 싶을 때 사용하세요. 코드 검사가 목적이면 이 도구가 아니라 scan_code / scan_path 를 씁니다.

로컬에 적재된 룰만 조회하며 네트워크 호출이 없습니다. 반환되는 results의 각 항목에는 rule_id가 있어 get_rule 로 전문을 조회할 수 있습니다.

룰 ID로 보안 룰 전문(근거 출처·탐지 기준·안전한 수정 예시 포함)을 조회합니다.

스캔 결과의 finding.rule_id 나 search_rules 결과의 rule_id 로 "왜 이게 걸렸는지" 근거 규정과 상세 설명이 필요할 때 사용하세요. 네트워크 호출이 없으며, 없는 ID면 {"error": "rule not found"} 를 반환합니다.

코드 조각을 공공기관 보안 기준으로 점검(보안·검토·체크·검사)합니다.

사용자가 메모리에 있는 코드(붙여넣은 스니펫, 방금 생성한 코드)가 "안전한지", 개인정보·시크릿·SQL 삽입·위험한 코드 실행·LLM 위험이 있는지 묻거나, "보안 점검/검토/체크"를 요청하면 이 도구를 사용하세요. 파일·폴더 경로라면 대신 scan_path 를 씁니다.

코드를 외부 API로 보내지 않습니다. 시크릿·개인정보는 마스킹된 짧은 증거만 반환하며, 각 발견 사항에 why_it_matters(왜 위험한가)와 safe_fix(안전한 수정 방향)가 함께 담깁니다.

시크릿(API 키·비밀번호·토큰)과 한국형 개인정보(주민등록번호·전화번호 등), 내부망 주소만 집중 탐지합니다.

"이 코드에 키/개인정보 들어있어?"처럼 유출 항목만 빠르게 확인할 때 쓰는 부분 집합 검사입니다. SQL 삽입·위험 명령 등 전체 보안 점검이 목적이면 scan_code / scan_path 를 쓰세요(이 탐지를 포함합니다).

코드를 외부로 보내지 않으며, 탐지된 값은 마스킹된 짧은 증거로만 반환합니다.

단일 패키지의 실재·취약점·악성·발행경과일(쿨다운)을 설치 전에 확인합니다.

AI가 제안한 패키지를 pip/npm install 하기 전, 또는 이름이 수상한(오타 스쿼팅 의심) 패키지를 확인할 때 사용하세요. 매니페스트 전체를 검사하려면 scan_dependencies 를 씁니다.

판정(verdict): not_found=저장소에 없음(AI가 지어낸 이름 의심, 차단 권고) | malicious=악성 | vulnerable=알려진 취약점 | cooldown_hold=발행 직후라 대기 권고 | checked_clean=이상 없음 | unknown/error=판정 불가('안전' 아님) | registry_rejected=기관 레지스트리가 차단 | registry_approved=기관 레지스트리가 승인.

registry_* 는 이 도구의 관측이 아니라 기관의 결정입니다. 다만 malicious 는 승인보다 위입니다 — 승인은 시점의 판단이고 위협 정보는 그 뒤에도 갱신됩니다. registry_approved 인데 checked=false 면 '승인은 받았으나 이번에 로컬 위협 정보와 대조하지는 못했다'는 뜻입니다('안전 확인'이 아님).

네트워크: 온라인이면 공식 저장소(pypi.org/registry.npmjs.org)와 OSV.dev에 패키지명·버전만 전송합니다(코드 미전송). GVSKB_MODE=offline(망분리)이면 외부 호출 없이 로컬 인텔 캐시로 대체하며, 실재·발행일은 '미확인'으로 표시됩니다.

의존성 매니페스트를 파싱해 각 패키지의 실재·취약점·악성·쿨다운을 일괄 검사합니다.

scan_path 결과에서 requirements.txt·package.json 이 '검사 제외'로 표시되면 이 도구로 이어서 검사하세요.

네트워크: 온라인이면 공식 저장소와 OSV.dev에 패키지명·버전만 전송합니다 (소스 코드 미전송). GVSKB_MODE=offline(망분리)이면 외부 호출 없이 로컬 인텔 캐시로 대체하며, 실재·발행일은 '미확인'으로 표시됩니다.

락파일을 넣으면 전이 의존성까지 검사합니다. 실무 취약점은 대부분 매니페스트에 적히지 않은 전이 의존성에 있으므로, 락파일이 있으면 그쪽을 넣는 편이 정확합니다 (버전도 범위가 아니라 고정값이라 판정이 확실해집니다).

결과를 scan_path 결과 JSON의 dependency_audit 필드에 넣어 render_report를 호출하면 사람용 보고서에 '의존성 취약점' 섹션이 함께 렌더됩니다.

truncated_count > 0 이면 limit 로 잘려 검사되지 않은 패키지가 있다는 뜻입니다 — '이상 없음'이 아니므로 limit 를 올려 재검사하세요.

건네받은 SBOM 의 컴포넌트를 검사합니다 — 소스 코드가 없어도 됩니다.

조달·협력사가 SBOM 만 제출하는 경우, 또는 빌드 파이프라인이 이미 SBOM 을 만들어 두는 경우에 씁니다. scan_dependencies 가 매니페스트/락파일을 받는 것과 짝입니다.

읽지 못한 컴포넌트는 버리지 않고 skipped 에 사유와 함께 돌려줍니다. purl 이 없거나 버전이 NOASSERTION 이면 취약점 판정이 불가능한데, 조용히 빼면 받는 쪽은 "그 컴포넌트는 안전하다"로 읽습니다 — 없는 것과 안 본 것은 다릅니다. truncated_count > 0 도 같은 뜻이니 limit 를 올려 재검사하세요.

반대 방향(우리 검사 결과를 SBOM 으로 내보내기)은 CLI 의 gvskb scan --check-deps --sbom <경로> 입니다.

벤더링된 프런트엔드 라이브러리(static/*.min.js)의 컴포넌트 취약점을 검사합니다.

scan_path 결과에 vendor_bundles 가 비어 있지 않으면 반드시 이 도구로 이어서 검사하세요. 이 파일들은 소스 룰 검사에서는 제외되지만(미니파이드라 오탐만 나옴) 그 자체가 프로젝트가 실행하는 남의 코드이고 알려진 취약점이 붙습니다. package.json 도 node_modules 도 없는 프로젝트에서는 이것이 유일한 컴포넌트 발견 경로입니다(실측: xlsx 0.18.5 → CVE-2023-30533 등).

버전을 확정하지 못한 번들은 조회하지 않고 '판정 불가'로 남깁니다 — 추측한 버전으로 취약점을 단정하지 않기 위해서입니다. 판정 불가는 '안전'이 아닙니다.

결과를 scan_path 결과 JSON 의 dependency_audit 에 넣어 render_report 를 호출하세요. 이미 scan_dependencies 결과가 있다면 {"audits": [<의존성 결과>, <이 결과>]} 형태로 합쳐 넣습니다.

발견 사항(finding)에 대한 공무원 친화적 안전 수정 방향을 반환합니다.

스캔 결과의 특정 finding을 "어떻게 고치죠?"라고 물을 때 rule_id로 호출하세요. 쉬운 제목(plain_title), 안전한 수정 방향(safe_fix), 자동 수정 가능 여부(can_auto_fix)를 돌려줍니다. 네트워크 호출이 없으며, 자동 수정은 diff 미리보기 후 담당자 확인을 거쳐 적용해야 합니다.

파일 또는 폴더를 공공기관 보안 기준으로 점검(보안·검토·체크·검사)합니다.

사용자가 "이 폴더/프로젝트 보안 점검해줘", "이 파일 검토/체크해줘", "안전한지 검사해줘"처럼 로컬 경로를 가리키면 이 도구를 사용하세요. 메모리의 코드 조각이면 대신 scan_code 를 씁니다. "기존 코드베이스 감사" 흐름의 진입점입니다.

경로를 로컬에서 순회하며 빌드·vendor 디렉터리를 건너뛰고 바이너리는 무시하며, 소스 코드를 외부 API로 전혀 보내지 않습니다. 각 발견 사항에는 why_it_matters 와 safe_fix 가 포함됩니다. 검사 후 render_report 로 한국어 보고서를 만드세요.

ScanReport(scan_code / scan_path 결과)를 한국어 보고서로 만들고 파일로 저장합니다.

⚠️ 중요 — 반환된 내용을 별도 파일로 다시 저장하지 마세요. 이 도구가 이미 표준 위치에 저장했습니다. 반환값의 saved 에 담긴 경로를 사용자에게 그대로 알려 주세요. 에이전트가 임의 위치·이름으로 다시 저장하면 조직의 점검 이력이 흩어져 나중에 찾을 수 없습니다.

저장 규약: <검사한 경로>/.check-reports/YYYY-MM-DD_HHMM_보안점검.{html,md,json} (기관 공용 폴더로 모으려면 환경변수 GVSKB_REPORT_DIR 을 설정합니다)

형식:

• format="markdown": Markdown 본문(기본)

• format="html": 자체 포함 단일 HTML(외부 CDN·JS 없음, 인쇄→PDF·이메일 가능)

• format="both": Markdown + HTML 모두

• format="sarif": SARIF 2.1.0 (CI·보안도구 연동, GitHub code scanning 업로드)

저장이 필요 없으면 save=False 로 문자열만 받습니다(파이프 연결 등). 출력은 자체 완결적이라 비전공 이해관계자 공유나 내부 승인 기록 첨부에 적합합니다.

점검 보고서를 파일로 저장하고 저장 경로를 알려줍니다.

render_report 는 본문 문자열만 돌려주므로, 그대로 두면 보고서가 대화창에만 남고 사라집니다. 결재·보고에 첨부하려면 이 도구로 저장하세요.

저장 규약: <검사한 프로젝트>/.check-reports/YYYY-MM-DD_HHMM_보안점검.{html,md,json}

• HTML: 인쇄하면 그대로 PDF 결재 문서가 됩니다(외부 CDN 없음)

• MD: 텍스트 편집·재가공용

• JSON: 재검사·이력 비교용 원본 데이터 기관 공용 폴더로 모으려면 환경변수 GVSKB_REPORT_DIR 을 설정하세요.

실제로 설치된 패키지까지 훑어 취약점·라이선스를 검사합니다.

scan_dependencies 는 requirements.txt·package.json 에 적힌 것만 봅니다. 그런데 취약점은 대개 그 파일에 없는 전이 의존성에 있습니다. 이 도구는 폴더 안의 설치 흔적을 직접 읽어 그 격차를 메웁니다:

• .venv/site-packages 의 *.dist-info/METADATA (이름·버전·라이선스)

• 오프라인 반입용 *.whl 파일명

• node_modules/*/package.json

패키지를 임포트·실행하지 않고 메타데이터 텍스트만 읽습니다. 네트워크는 취약점 조회에만 쓰이며 패키지명·버전만 전송합니다(GVSKB_MODE=offline 이면 로컬 인텔 캐시 사용). 라이선스 정보는 설치 메타데이터에서만 얻을 수 있어 이 도구에서만 함께 반환됩니다.

현재 서버에 적재된 전체 보안 룰 목록(ID·제목·심각도·계층)을 반환합니다.

디버깅·감사용입니다: 룰이 몇 개 적재됐는지, 특정 룰이 포함됐는지 확인할 때 쓰세요. 룰 내용 검색은 search_rules, 전문 조회는 get_rule 이 적합합니다. 네트워크 호출이 없습니다.

Return runtime diagnostics: install identity, rules dir, rule counts, env.

Use this from any MCP client (Claude, Cursor, Codex, ...) to verify the server is healthy and to see which rules are loaded. No network calls.

설치 신원을 함께 돌려준다 — 버전 문자열만 믿지 마세요:

• runtime_freshness.process_stale — 먼저 이것을 보세요. 돌고 있는 프로세스가 디스크의 현재 코드·룰을 쓰고 있는지. true 면 판정 결과가 낡은 룰에서 나온 것이므로, 결과를 해석하기 전에 remedy 대로 서버를 재시작해야 한다(재설치가 아니다 — 룰과 코드는 프로세스 시작 시점에 한 번만 읽힌다).

• commit_id — 이 프로세스가 임포트한 시점의 커밋(pip direct_url.json 또는 소스 체크아웃의 .git/HEAD). 디스크의 현재 커밋은 install_identity.disk_commit_id 이고, 둘이 다르면 낡은 것이다. __version__ 은 릴리스 사이에 고정돼 최근 변경분을 구분하지 못한다.

• total_rules — 메모리에 올라간 룰 수(rule_count_source 로 출처 표기). 디스크를 다시 읽은 수가 아니므로, 이 값이 늘었다고 최신인 것은 아니다. 인텔 캐시 룰이 섞여 최신처럼 보인 사례가 있다.

• mcp_tools / missing_tools — 이 설치본이 실제로 제공하는 도구 목록. 필요한 도구 이름이 mcp_tools 에 없으면 낡은 설치본이므로, 호출 실패 증상으로 역추적하지 말고 재설치하면 된다.