Comparison · Cybersecurity
SBOM, SCA and VEX: Inventory, Scanning and Exploitability
An SBOM inventories components in a software release; SCA analyzes them against vulnerability and license information. VEX expresses affectedness for a specific product/version context.…
Technical review:
Architecture and operating model
An SBOM inventories components in a software release; SCA analyzes them against vulnerability and license information. VEX expresses affectedness for a specific product/version context. These outputs complement rather than replace one another.
Matching only package names may misidentify components. Preserve versions, package ecosystem, hashes and dependency relationships. Do not treat a VEX not_affected statement as a blanket exception without checking justification, issuer and signature.
The comparison metric is not simply CVE count. Measure direct/transitive coverage, database freshness, reproducibility and false-positive review on the same build. Tie operational decisions to the deployed artifact.
- 1Build artifact
- 2SBOM inventory
- 3SCA matching
- 4VEX and remediation
Design parameters
- Artifact binding
- Verify that the source SBOM represents the same hash/version as the deployed container.
- Statement validity
- Scope VEX by product, version, component and date; review it when scope changes.
Platform implementation
Service names are reference points. Scope, defaults, region availability and operating requirements differ; they are not interchangeable guarantees.
| Output | Question answered | Limitation |
|---|---|---|
| SBOM | What is included? | Not a vulnerability decision. |
| SCA | Which components match risks? | Contextual review is required. |
| VEX | Is this product affected? | Justification has a limited scope. |
Worked example
A lab product contains 120 components and scanning returns eight CVEs. Two are version mismatches, one has a justified unaffected VEX statement and five need review. Avoid summarizing this as eight confirmed flaws or complete safety; retain evidence for each decision.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Two scanners disagree | Component identity or vulnerability data differs. | Compare the same artifact, database timestamps and package coordinates. |
| Exception carries into a new release | VEX scope was applied too broadly. | Revalidate product version and justification. |
Acceptance checks
- Bind the SBOM release to an artifact hash.
- Check transitive dependencies.
- Record scanner database date.
- Validate the VEX issuer.
- Limit exceptions to a release.
- Rescan after remediation.
Related concepts
Dependencies and restart order
Services commonly depend on identity, DNS, time, networking, databases and licensing. Record a dependency graph describing conditions for operation, not merely an equipment list. Recovery order follows that graph; circular dependencies may require emergency access paths. Distinguish restored infrastructure from resumed business activity. Assign an owner, validation method and alternative access path to each dependency. Test assumptions by deliberately making one component unavailable in a controlled end-to-end exercise.
Version and support lifecycle
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. An unrepresentative test environment can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behaviour. A log describes an event, a metric shows behaviour over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Policy lifecycle
A policy needs management as its scope changes, not just when it is enabled. Separate drafting, observation, pilot deployment, enforcement and periodic review. Every exception needs an owner, reason, scope and expiry date. A successful pilot can still cause production false positives if test data does not represent real user behaviour. Identify affected users and applications before deploying with measurable acceptance criteria. A rollback path should identify who may reverse the change and under which conditions, rather than merely locating an interface button.
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new accesses are denied when the identity provider becomes unavailable.
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.