diff --git a/content/en/guide/supply-chain/for-suppliers/creation-guide/_index.md b/content/en/guide/supply-chain/for-suppliers/creation-guide/_index.md
index b80c30718..12bb04419 100644
--- a/content/en/guide/supply-chain/for-suppliers/creation-guide/_index.md
+++ b/content/en/guide/supply-chain/for-suppliers/creation-guide/_index.md
@@ -44,17 +44,13 @@ graph TD
     A --> G1
     A --> G2
     
-    %% Connect each group to its inner boxes
-    G1 --> M1_Sub
+    %% Connect only to the group borders (one arrow per box)
+    G1 --> M1
+    G2 --> M2
     
-    %% G2 feeds both inner boxes on the right
-    G2 --> M2_Top
-    G2 --> M2_Bottom
-    
-    %% Inner boxes flow to the next step
-    M1_Sub --> P(["Submit the SBOM"])
-    M2_Top --> P
-    M2_Bottom --> P
+    %% Groups flow to the next step
+    M1 --> P(["Submit the SBOM"])
+    M2 --> P
 
     classDef start fill:#F2F2F2,stroke:#171717,color:#171717,stroke-width:1.5px
     classDef typebox fill:#ffffff,stroke:#c8c8c8,color:#171717,stroke-width:1px
@@ -79,11 +75,9 @@ graph TD
 
 ```
 
-For software you developed yourself, scan the source code to produce the SBOM regardless of the delivery form. Even when you deliver an executable, a binary, or firmware, scan the source code that produced it, not the finished artifact. Scanning a finished binary directly yields no package manager metadata, so PURLs are omitted, vulnerability matching fails entirely, and the SBOM is rejected.
-
-Source code, an executable or binary, and firmware with no OS are all scanned from the source code with cdxgen or [BomLens](../skt-scanner/). This is the baseline for capturing transitive dependencies accurately.
+Source code and apps, executables or libraries, and firmware with no OS are all scanned from the source code you developed with cdxgen or [BomLens](../skt-scanner/). Scanning a finished binary directly yields no package manager metadata, so purls are omitted and the SBOM is rejected.
 
-When you ship an OS or base image as part of the delivery (a container image, a server, or firmware with an embedded OS), split it into two layers. Scan the source for the app layer, scan the image or rootfs as shipped with Syft or Trivy for the OS layer, then merge and submit. The OS-layer scan target is not the original base image you received but the image or rootfs actually delivered after the build, because it must include the OS packages installed during the build. For the full procedure, see [Server SBOM](../server-delivery/).
+When you ship an OS or base image as part of the delivery (a container image, a server, or firmware with an embedded OS), split it into two layers and scan each. Scan the image or rootfs as shipped with Syft or Trivy for the OS layer, scan the source code (the app layer) with cdxgen or BomLens, then merge and submit. The OS-layer scan target is not the original base image you received but the image or rootfs actually delivered after the build, because it must include the OS packages installed during the build. For the full procedure, see [Server SBOM](../server-delivery/).
 
 Statically linked libraries and manually vendored binaries are a blind spot that none of the scans above catch. For how to handle this case, see the statically linked libraries section of [Server SBOM](../server-delivery/).
 
diff --git a/content/ko/guide/supply-chain/for-suppliers/creation-guide/_index.md b/content/ko/guide/supply-chain/for-suppliers/creation-guide/_index.md
index 62eec448e..bd6d49cee 100644
--- a/content/ko/guide/supply-chain/for-suppliers/creation-guide/_index.md
+++ b/content/ko/guide/supply-chain/for-suppliers/creation-guide/_index.md
@@ -44,17 +44,13 @@ graph TD
     A --> G1
     A --> G2
     
-    %% 그룹에서 내부 서브 박스로 연결
-    G1 --> M1_Sub
+    %% 그룹 박스 경계로만 연결 (박스당 화살표 1개)
+    G1 --> M1
+    G2 --> M2
     
-    %% G2에서 우측 내부 박스들로 각각 연결선 진입
-    G2 --> M2_Top
-    G2 --> M2_Bottom
-    
-    %% 내부 서브 박스에서 다음 단계로 연결
-    M1_Sub --> P(["SBOM 제출"])
-    M2_Top --> P
-    M2_Bottom --> P
+    %% 그룹 박스에서 다음 단계로 연결
+    M1 --> P(["SBOM 제출"])
+    M2 --> P
 
     classDef start fill:#F2F2F2,stroke:#171717,color:#171717,stroke-width:1.5px
     classDef typebox fill:#ffffff,stroke:#c8c8c8,color:#171717,stroke-width:1px
@@ -79,11 +75,9 @@ graph TD
 
 ```
 
-자체 개발 소프트웨어라면 납품 형태와 무관하게 자기가 개발한 소스코드를 스캔해 SBOM을 만듭니다. 실행 파일이나 바이너리, 펌웨어로 납품하더라도 완성된 산출물이 아니라 그것을 만든 소스코드를 스캔합니다. 완성된 바이너리를 그대로 스캔하면 패키지 매니저 메타데이터가 없어 purl이 누락되고, 취약점 매칭이 전량 실패해 반려됩니다.
-
-소스코드, 실행 파일이나 바이너리, OS 없는 펌웨어는 모두 소스코드를 cdxgen 또는 [BomLens](../skt-scanner/)로 스캔합니다. 전이 의존성까지 정확히 잡으려면 이 방식이 기준입니다.
+소스코드·앱, 실행 파일이나 라이브러리, OS 없는 펌웨어는 모두 자기가 개발한 소스코드를 cdxgen 또는 [BomLens](../skt-scanner/)로 스캔합니다. 완성된 바이너리를 그대로 스캔하면 패키지 매니저 메타데이터가 없어 purl이 누락되고 반려됩니다.
 
-OS나 베이스 이미지를 포함해 공급하는 경우(컨테이너 이미지, 서버, OS 내장 펌웨어)는 두 층으로 나눕니다. 앱 층은 소스코드를 스캔하고, OS 층은 납품되는 상태의 이미지나 rootfs를 Syft 또는 Trivy로 스캔한 뒤 둘을 합쳐 제출합니다. 이때 OS 층의 스캔 대상은 받아온 원본 베이스가 아니라 빌드가 끝나 납품되는 이미지나 rootfs입니다. 빌드 과정에서 설치한 OS 패키지까지 포함해야 하기 때문입니다. 전체 절차는 [서버 SBOM 생성](../server-delivery/)을 참고하세요.
+OS나 베이스 이미지를 포함해 공급하는 경우(컨테이너 이미지, 서버, OS 내장 펌웨어)는 두 층으로 나눠 각각 스캔합니다. OS 층은 납품되는 상태의 이미지나 rootfs를 Syft 또는 Trivy로 스캔하고, 소스코드(앱 층)는 cdxgen 또는 BomLens로 스캔한 뒤 둘을 합쳐 제출합니다. 이때 OS 층의 스캔 대상은 받아온 원본 베이스가 아니라 빌드가 끝나 납품되는 이미지나 rootfs입니다. 빌드 과정에서 설치한 OS 패키지까지 포함해야 하기 때문입니다. 전체 절차는 [서버 SBOM 생성](../server-delivery/)을 참고하세요.
 
 정적 링크된 라이브러리나 수동으로 넣은 바이너리는 위 어느 스캔으로도 잡히지 않는 사각지대입니다. 이 경우의 처리는 [서버 SBOM 생성](../server-delivery/)의 정적 링크 라이브러리 절을 참고하세요.