— Scanning alone is not enough: why you need an SBOM-based response framework
React2Shell was rated a critical issue enabling remote code execution (RCE) in Next.js-based services, pushing many organizations into emergency response mode.
Yet the most fundamental question most security teams faced was the same:
“Instead of ad-hoc fixes, don’t we need a fundamental framework to prepare for recurring vulnerabilities?”
This incident went beyond a single vulnerability and clearly showed why an SBOM-based response framework is necessary.
1. Scanning Only Tells You “Where to Patch Right Now”
An exploit scanner quickly confirms whether vulnerable versions exist and whether they are actually exploitable.
But scan results alone cannot determine the full scope of response across the organization. The reason lies less in technical limits than in how the organization operates.
Recurring problems when relying on scanners alone
A company-wide survey of all services every time a CVE hits
No SBOM, so no record of how far updates have gone
Rising investigation costs for both development and security teams
Longer response times that leave the organization needlessly exposed
In short, scanners alone enable “short-term fixes,” but are limited in building “organizational security”.
2. The Key to Broadening Response Scope: Building an SBOM
An SBOM (Software Bill of Materials) is a company-wide inventory that continuously tracks and manages which libraries, packages, and versions make up all of the organization’s services and products.
Products and services go through the following changes every week.
New feature releases
Bug patches
Dependency updates
Remaining legacy code
In other words, the SBOM keeps changing.
Without an SBOM, every CVE announcement goes like this:
“Re-examine every repository.”
“Dig through internal services too and confirm the impact.”
An SBOM eliminates all of this cost and time.
Questions an SBOM lets you answer immediately
Where is the vulnerable library used?
How many services have the vulnerable version?
How many are affected company-wide, including internal networks, test, and legacy systems?
What is the patch priority?
An SBOM shows the company-wide risk scope at a glance.
3. Version Detection Alone Is Not Enough: VEX Analysis
Even with the same vulnerable version, actual exploitability depends on configuration, network, and code paths.
The vulnerable code is never actually called
There is no authentication/authorization bypass path
Vulnerable only with a specific option combination, but that option is unused
External input is blocked, so there is no attack surface
The framework that distinguishes these differences is VEX.
VEX status definitions
affected: vulnerability that affects the product
not_affected: vulnerability that does not apply
fixed: remediated
under_investigation: under investigation
VEX justifications and examples
Code not present
Bluetooth-related modules are not included in the build because the product does not use Bluetooth
The USB storage driver does not exist at all because the kernel is configured with CONFIG_USB_STORAGE=n
The OpenSSL library has been removed from the firmware image, so the vulnerable code itself does not exist
Code not reachable
The function exists, but there is no logic in the product that calls the feature
Debug code is included but never called at runtime
SMB protocol support code remains, but the port is not open and the service is never started
Requires configuration
A vulnerability that only occurs if an admin manually turns on an “advanced features” option
The option exists in the kernel but is turned off at the product configuration stage
An SSH root login vulnerability, but root login is blocked by default
Requires dependency
The vulnerable module requires a Python 3 environment → the product has no Python environment
A vulnerability in a specific DB client, but the product does not use any DB features
A vulnerability in a specific file system (ext4), but the product uses only squashfs
Requires environment
Physical console access is required, but the product is fully sealed
The vulnerability requires the attacker to connect to Wi-Fi, but the product does not support Wi-Fi
The attacker would need to open a debug port, but UART/JTAG is blocked
Protected at runtime
Runtime security features such as ASLR, Stack Protector, AppArmor, and SELinux are applied
Boundary checks run automatically before dangerous functions are called
Memory obfuscation and integrity-check modules are applied on memory access
Protected by compiler
FORTIFY_SOURCE and stack canaries are applied at compile time
Dangerous code is automatically removed by a static analyzer
The problematic code is excluded from compilation by optimization options
Protected by mitigating control
The vulnerable feature is blocked by a firewall
The endpoint where the vulnerability occurs requires authentication at the reverse proxy
Dangerous API calls are blocked by product-level policy
Protected at perimeter
The relevant port is not reachable from the WAN
The vulnerable protocol is exposed only on the internal network
The service is reachable only inside the VPN → external attack is impossible
Business value of VEX
Prevents wasted development resources
Prevents outages caused by unnecessary patches
Clarifies emergency patch priorities
Automates audit/compliance response
4. Z-BOM: A Tool That Puts an SBOM-Based Response Framework into Practice
Z-BOM integrates SBOM + VEX + workflow and is built so companies can actually operate the response framework just described.
Key features of Z-BOM:
Automatic SBOM generation · standards support (SPDX/CycloneDX)
AI-based vulnerability mapping and risk assessment
Framework vulnerabilities like React2Shell will keep recurring. Response speed will clearly separate organizations with an SBOM framework from those without one.
{# 쿠키 수집 안내 팝업 — 선택 전 방문자에게만(cookie-consent '쿠키 안내 팝업'). 버튼은 폼 POST 라 JS 없이 동작하고, 닫기(×)는 '거부' 와 같이 저장된다.
source·close 는 누른 버튼별 집계용 — 닫기를 거부와 따로 센다(cookie-consent '쿠키 선택 집계'). #}
