BomLens · Trusted OSS · TRUSCA
Haksung Jang · SK Telecom
SK Telecom requires every partner delivering software to it to submit an SBOM (Software Bill of Materials).
Much of what comes in is SBOM-shaped but can't be mapped against a vulnerability database. These are the three most common rejection reasons.
Scan a bare install directory or raw files, and the identifier drops out entirely.
Scanning source before the build step skips npm install or mvn package.
Shows up when the ecosystem can't be identified — the package stays unpinned.
The obligation existed. The tool didn't.
An SBOM generator that also runs open source risk assessment. No account, no upload required.
Apache-2.0 · github.com/sktelecom/bomlens
Source, container, or a received SBOM — the same scanner runs and produces the same result.
Before the demo, let's fix in advance where each of the three rejection reasons gets resolved on the results screen.
Ecosystem, name, and version all land on one row.
Even transitively-pulled components stay on the list as their own row.
Flows straight into the notice file from the same scan.
| Component | PURL | License | Origin |
|---|---|---|---|
| lodash 4.17.21 | pkg:npm/lodash@4.17.21 | MIT | Direct |
| commons-lang3 3.12.0 | pkg:maven/org.apache.commons/commons-lang3@3.12.0 | Apache-2.0 | Direct |
| requests 2.31.0 | pkg:pypi/requests@2.31.0 | Apache-2.0 | Transitive |
| urllib3 2.2.1 | pkg:pypi/urllib3@2.2.1 | MIT | Transitive |
| gin 1.9.1 | pkg:golang/github.com/gin-gonic/gin@1.9.1 | MIT | Transitive |
The three rejection reasons from slide 3 disappear one by one on this screen.
This is the answer to the first question in this morning's group discussion topic A — how do you actually review the license of an open model.
That's the supply chain half. What follows is a problem happening inside our own development organizations.
The policy existed. There was no way to enforce it.
A self-certification kit for ISO/IEC 5230 and 18974. At its core is a 5-level maturity model built for AI-coding conditions.
L1 and L2 are rules people follow. From L3 on, a tool enforces them instead.
No one can check L3-and-above by hand every time — you need a tool to stand in.
SCA (Software Composition Analysis): a category of tools that automatically finds open source components and checks their vulnerabilities and license obligations.
A document doesn't execute. A tool enforces it instead.
CVE tracking, license compliance, and SBOM management in one screen. It runs inside your own network, so neither code nor SBOMs ever leave it.
cdxgen covers 30+ language ecosystems, so it sweeps through whatever mix of languages sits in your internal repositories in one pass.
| Stage | What it does | With what |
|---|---|---|
| Detectdiscovery | Finds the components that made it into the repository | cdxgen, 30+ language ecosystems |
| Matchmatching | Attaches the CVEs tied to each component and version | Trivy's aggregated DB · NVD · OSV · GHSA · EPSS · KEV |
| Triagejudgment | Decides whether it's exploitable and records the reasoning | 7-state VEX management |
| Enforceenforcement | Blocks the build on a critical vulnerability or a banned license | CI gate, automatic NOTICE generation |
trusca-demo.duckdns.org · dev@demo.trustedoss.dev · read-only
An evaluation install takes 30 seconds — plenty to run before deciding whether to adopt it internally.
Production deployments support Docker Compose and a Helm chart.
Not three tools used separately — each holds a different spot on the same supply-chain line.
The three tools we saw today answer, respectively: an SBOM that gets rejected, a policy no one follows, and a gate that never enforces.
Today covered why these tools matter. Installing and actually running a scan is what the October 15 Tooling & Legal Subgroup meeting covers.
github.com/sktelecom/bomlens · github.com/trustedoss/trusca · trustedoss.github.io