From SBOM Inventory to Package Intelligence

Most composition tools produce static CycloneDX/SPDX reports listing components, vulnerability and license metadata. Runtime-first products lack policy controls. Kodem unifies both, treating each package version as an accountable unit. Rather than a static report, SBOM packages connect discovery, investigation and enforcement across the platform, allowing AppSec and engineering teams to view what they run, prioritize relevant issues and decide what to fix, block and safely ignore.

SBOM Packages as Shared Data

Kodem treats SBOM packages as shared data across systems of work. Each package version carries static analysis results, container image details, runtime evidence including function-level execution and the outcomes of SCM and CI policies.

Each package record serves as a single source of truth across Discovery, Triage, Applications, Images, Base Images, runtime evidence and policy enforcement. The Base Images view links directly to a scoped Packages (SBOM) view showing only packages originating from that base image. 

Referencing the same data:

• Pull/Merge request checks (PR/MR)
• CI image scanning and exports: CSV, CycloneDX, SPDX

Kodem’s CI output includes human-readable tables in CI pipeline logs, terminal output and machine-readable SBOMs in CycloneDX and SPDX JSON formats for external governance workflows, customer reporting and downstream security tools. These SBOMs are enriched with dynamic VEX-style data - vulnerability presence and exploitability status), so external customers see not only which components are present by whether issues are exploitable in your environment.

Problem: SBOMs Without Decisions

Modern SCA and image scanners report which packages contain vulnerabilities, yet rarely indicate which ones matter to a specific environment.

A single container image can surface hundreds of CVEs across base images and application dependencies. Many teams see scans that report hundreds of critical issues on a single PR/MR, only to discover that most entries have no relevance or practical reachability inside their own environment. Traditional reachability analysis narrows the list yet still focuses on potential execution rather than actual behaviour.

Research on SBOM based vulnerability management reports extremely high false-positive rates when scanners act on raw SBOM data, often because they flag issues in code paths that never execute. Teams therefore face long triage queues and alert fatigue although they already invested in SBOM generation and scanning workflows.

Teams recognise this pattern:

• Noisy SBOM exports accumulate in shared drives and compliance folders.
• CI pipelines accumulate ad-hoc rules, inline suppressions and brittle exception files.
• Each new supply chain incident resets a painful manual search through images, repositories and services.

Most tooling that advertises SBOM capabilities concentrates on production of SBOM documents and compliance workflows rather than daily operations. When a new supply chain attack hits a common package, security teams do not want another JSON file; they want concise answers to four questions:

• Which package versions appear in the environment 
• Where do those versions run?
• How did those versions enter the environment?
• What will happen when those versions are blocked or upgraded?

Solution: SBOM Packages as the Unit of Ownership

Kodem treats each package version as the backbone that connects scanning, SBOM inventory and runtime evidence.

Kodem scans code repositories and container images for open-source vulnerabilities (and code weaknesses, then normalizes results into a single Packages table (default). That table merges:

• Code scan output from repositories and branches.
• Image scans from CI pipelines or registries.
• Runtime observations from sensors across Kubernetes, virtual machines and other cloud workloads.

Users then pivot into each package’s open-source issues, see exactly how that package was introduced into your environment and confirm whether the package ever loaded into memory and / or executed in production.

The workflow changes the key question. The vague statement that a vulnerable package might exist somewhere inside an image becomes a precise description that a specific CVE executed through a specific binary in a named service in production, along with a clear base image chain that pulled the package into that service and a recommended upgrade path.

How Kodem Builds a Dynamic SBOM

Kodem's SBOM model is continuously updated from three distinct sources, rather than depending on a single exported file.

• Code Repositories: Kodem connects to SCM systems (GitHub, GitLab,BitBucket, Azure Repos) to scan dependency manifests and lockfiles, linking each dependency version to its repository, branch, and Kodem project.
• Container Images: Kodem scans images during CI or in registries to identify OS and application dependencies, recording file locations, installation commands, and base image hierarchy. Scans focus on vulnerabilities and output human-readable tables or machine-readable JSON (CycloneDX, SPDX).
• Runtime Bill of Materials (RBOM): Kodem's runtime intelligence tracks loaded modules and processes in memory, building an RBOM that links execution back to vulnerable packages and CVEs, detailing load evidence, environment and function-level execution when available.

Packages (SBOM) view sits on top of this graph so that filters for severity, runtime evidence, direct or indirect dependency and base image origin interact with a real-time representation of the supply chain rather than a static export.

Together, these signals form dynamic VEX data for every package version: not just which vulnerabilities exist, but whether the package executes in your environment, where it runs and when it was last seen in production.

What AppSec Teams See: From Inventory to Investigation

AppSec teams use Packages (SBOM) to identify and investigate critical components. Typical workflows:

• Filter by risk and context. Use Insights to surface packages with runtime evidence, internet ingress, direct dependencies or base-image origin, then apply severity filters to highlight exposed, high-risk components.
• Review project and application impact. Project and application columns show where a package runs and how widely it spreads across the environment.
• Trace introduction paths. The Introduced Through drawer lists repositories, images and tags that contain the package, file locations, Docker history commands that installed it and whether each image in the base-image hierarchy remains in use (detected).

Instead of searching static SBOM files, teams work in a package-centric workspace that presents location, runtime indication, exploitable issues and required remediation. From this view they can:

• Examine open-source issues with runtime function details, exploit maturity and EPSS scores.
• Review recommended public fixes and Kodem remediation guidance.
• Decide whether to remediate, mitigate or enforce a policy.

Kai, Kodem’s AI AppSec engineer, sits alongside this view and answers questions such as “show packages with critical vulnerabilities executing in production” or “trace the supply chain for this package,” then guides users toward the next action.

What Developers See: From Packages to Concrete Remediation

The Open-Source Issues drawer links packages to issues. Each issue row shows Kodem Score, severity, exploit maturity, runtime usage, related applications, actions and last-seen timestamps. This issue view effectively serves as VEX for developers, combining vulnerability details with live exploitability context so they can focus on what is actually at risk.

• Fix Insights summarize when a fix or Kodem remediation exists, which versions represent the safest upgrade and when upgrades require base-image changes. For transitive dependencies, Kodem highlights the parent package to update so teams can resolve the issue with the minimum required change.
• Filters let developers focus on open issues, high or critical severities or specific CVEs relevant to an on-call incident.

Runtime evidence then anchors the guidance by showing:

• Package loaded into memory (runtime).
• Executing image and tag.
• Environment and namespace handling the workload.
• Process path for function-level details.

The How To Fix section turns this context into concrete remediation steps, suggesting precise base-image upgrades that resolve CVEs without unnecessary operating system jumps.

From Static List to Supply-Chain Control Plane

SBOM documents will remain mandatory for audits and regulatory frameworks, yet periodic exports alone cannot keep pace with modern supply-chain attacks or the vulnerability volume produced by scanners.

Kodem’s approach is to make SBOM packages the control plane filtering down to the affected components and turning package intelligence into immediate decisions: 

• Each row in the Packages (SBOM) view describes a package version that knows its origin, runtime footprint and issues. 
• Investigation paths reach from introduction history through RBOM, into individual open-source issues. 
• Remediation guidance reflects the environment and effort rather than generic CVSS scores. 
• SCM and CI policies then apply package intelligence to keep risk out of main and out of production images, while Scan History demonstrates whether behaviour actually improves over time.

How Teams Operationalise Package Intelligence

With package intelligence, runtime evidence, and policies in place, teams can use SBOM data as a daily control plane, rather than a static report.

Use Case: Responding to a Headline Supply-Chain CVE

A wormable CVE affects a popular base image. AppSec leader:

1. Filters Packages (SBOM) by vulnerability identifier, runtime evidence equals yes and environment equals production.
2. Opens the associated issues for each affected package and reviews runtime execution details and exposed applications.
3. Uses Kodem remediation suggestions to choose safe base-image upgrades.
4. Tightens SCM and CI policies so new builds cannot reintroduce the vulnerable base image.
5. Within a single workspace, the organization moves from uncertainty to a concrete list of images, services and upgrades.

‍Use Case: License and Malicious Package Guardrails

Legal leaders decide that specific copyleft licenses cannot appear inside customer-facing services. AppSec leader:

• Uses Packages (SBOM) to filter by license type and public-facing applications and identify services already relying on disallowed licenses.
• Configures SCM policies so new pull requests that introduce disallowed licenses in production projects are blocked, while non-production and internal tools receive warnings that support phased cleanup.
• Adds rules where issue type equals malicious package so merges and builds fail immediately when known malicious packages appear.
• Package intelligence combined with policies gives the organisation a consistent, auditable way to keep unwanted packages out of the estate without fragile naming conventions or ad hoc scripts.

‍Use Case: Stop Breaking the Build on Eight Hundred Criticals

A DevOps team enables container image scanning in CI. Soon most builds fail because the scanner reports hundreds of critical vulnerabilities, mainly in base images and many without runtime evidence or available fixes. Disabling scanning is not acceptable, yet every pull request shows red by default and slows releases. With Kodem, the team:

• Defines a protection policy that fails CI only when a vulnerability is critical, has a fix, appears in an image tagged for production and affects a package with runtime evidence in that environment.
• Adds rules that downgrade non-runtime packages, development tooling and findings without fixes to warnings they can schedule into normal sprints.
• Uses Scan History to confirm that builds stay mostly green while critical, exploitable risk is blocked.
• Kodem package intelligence and the policy engine give the team this level of control without weakening the security signal.