egovframe-scaffold-mcp

SBOM 점검 (최소 요소·비교·VEX)

check_egovframe_sbom

Validate an existing CycloneDX SBOM for submission readiness, detect missing NTIA elements, re-check purl-based status, compare baselines, and draft VEX for new vulnerabilities.

Instructions

이미 만든 CycloneDX SBOM 을 제출물로서 점검합니다(SBOM 파일은 바꾸지 않음). (1) 최소 요소 7종 — 공급자·구성요소명·버전·고유식별자(purl/cpe)·의존관계·작성자·생성 시각(NTIA 최소 요소 = 국내 SW 공급망 보안 가이드라인 핵심 구성요소)을 component 마다 세어 '제출 가능/보완 필요'와 빠진 component 를 보고 (2) 빌드 도구 없이 purl 만으로 기준 판정을 다시 해 생성 당시와 달라진 판정을, offline=false 면 OSV 를 다시 조회해 생성 이후 새로 알려진 취약점을 보고(운영 중 주기 점검) (3) baselinePath(이전 SBOM)를 주면 추가·제거·버전 변경·판정 변화·새 취약점을 비교 (4) vex=true 면 CycloneDX VEX 초안(기본 sbom/vex.cdx.json)을 씁니다 — 새 취약점은 analysis.state=in_triage, affects 는 BOM-Link 로 원본 SBOM 참조, 기존 VEX 에 사람이 적은 판단(not_affected·exploitable 등)은 보존하고 새 취약점만 추가합니다(dryRun=true 면 미리보기). 2027년 공공 SBOM 제출 제도화 대비.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`vex`	No	true 면 VEX 초안 작성·갱신(판단 보존)
`dryRun`	No	vex=true 일 때 쓰지 않고 미리보기
`format`	No	응답 형식	markdown
`offline`	No	false 면 OSV 재조회로 생성 이후 새 취약점 확인
`vexPath`	No	VEX 파일(프로젝트 상대 경로)	sbom/vex.cdx.json
`sbomPath`	No	점검할 SBOM(프로젝트 상대 경로)	sbom/bom.cdx.json
`projectDir`	Yes	프로젝트 디렉터리(절대경로 권장)
`baselinePath`	No	비교할 이전 SBOM(프로젝트 상대 경로)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`vex`	No
`diff`	No
`notes`	Yes
`minimum`	Yes
`recheck`	Yes
`document`	Yes
`sbomPath`	Yes
`projectDir`	Yes
`absolutePath`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.40.0Oct 7, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) already flag that this writes and reaches the network. The description goes far beyond: it discloses that the SBOM itself is not mutated, that offline=false triggers OSV lookups, that dryRun previews instead of writing, that human-authored VEX judgments are preserved and only new vulns added, and that affects uses BOM-Link. This is rich, non-redundant behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single long sentence with embedded enumerations, front-loading the core purpose well, but the parenthetical asides and repeated clauses make it dense and harder to scan than it needs to be. Every clause carries meaning, so nothing is pure waste, but structure could be clearer with separation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 8-parameter tool with an output schema already present, the description supplies the operational context an agent needs: mode selection, what comparison produces, VEX write semantics, and preservation guarantees. Given the output schema handles return shape, nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description nonetheless adds semantic meaning beyond the schema prose: it explains what baselinePath compares (추가·제거·버전 변경·판정 변화·새 취약점), that vex=true writes a CycloneDX VEX draft with defaults, and that dryRun only applies when vex=true. It does not cover every param, so a 4 rather than 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('점검' = inspect/audit) and resource ('이미 만든 CycloneDX SBOM'), and explicitly distinguishes from a sibling by clarifying the SBOM file is not modified ('SBOM 파일은 바꾸지 않음'). This separates it from generate_egovframe_sbom, which produces the SBOM.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly enumerates four distinct use cases (minimum-element check, purl-based re-judgment + optional OSV re-query, baseline comparison, VEX draft) and ties each to a trigger (offline=false, baselinePath provided, vex=true). It also names operational scenarios ('운영 중 주기 점검') and the regulatory driver (2027 공공 SBOM 제출 제도화).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.