A Software Bill of Materials (SBOM) is a structured inventory of the components used to build a software product. It can identify open-source libraries, third-party packages, software versions, and dependency relationships, helping organisations understand their software supply chain.
SBOMs are particularly valuable when a vulnerability affects a widely used dependency or when a malicious package is discovered in a software ecosystem. Security teams can use them to identify affected applications, trace dependencies, prioritise remediation, and assess exposure.
However, an SBOM is not a malware scanner. It can reveal which components are present, but identifying malicious behaviour requires additional analysis, such as package reputation checks, vulnerability intelligence, software provenance verification, and runtime monitoring.
Modern applications rarely consist entirely of code written by their developers. They depend on external libraries, open-source frameworks, package-manager dependencies, and components maintained by third parties.
A single application may contain hundreds or thousands of dependencies. These components can introduce vulnerabilities, become unsupported, or be compromised by malicious actors.
Consider an organisation that deploys a web application using several JavaScript packages, a Python library, and multiple system components. A vulnerability is subsequently discovered in one of those dependencies.
Without an accurate inventory, the security team may struggle to answer three basic questions:
Which applications contain the affected component?
Which versions are present, including indirect dependencies?
Where should remediation begin?
A Software Bill of Materials helps answer these questions by documenting the components that make up a software product.
Instead of investigating every application from scratch, security teams can use an SBOM to identify potentially affected systems and begin a targeted assessment.
An SBOM is a formal record of the software components included in a product. Depending on its format and the process used to generate it, an SBOM can include component names, versions, suppliers, identifiers, dependency relationships, and integrity information.
A typical SBOM may contain:
Component name: The name of a library, package, or software component.
Version: The recorded version of the component.
Supplier or author: Available information about who provides or maintains it.
Package identifier: A standard identifier, such as a Package URL (PURL).
Dependency relationships: Information describing how components relate to one another.
Integrity information: Checksums or hashes when included in the SBOM.
Licensing information: Available information about component licences.
External references: Links to repositories, advisories, or other component records.
The exact fields depend on the SBOM format and the quality of the source data.
Two widely used SBOM formats are:
SPDX: A standard for representing software components, licences, and related supply chain information.
CycloneDX: A standard designed to represent software component inventories and other security-related information, including vulnerabilities and dependency relationships in supported use cases.
Both formats help organisations exchange software inventory information in a structured way.
SBOMs support several security activities, particularly when organisations need to understand their exposure to third-party software risks.
When a new vulnerability is disclosed, security teams can search SBOM inventories for affected components and versions.
This helps reduce the time needed to identify potentially exposed applications.
However, the presence of a vulnerable version does not automatically mean that an application is exploitable. Analysts must also assess configuration, reachable functionality, mitigations, and the conditions required for exploitation.
An SBOM helps organisations understand which external components their applications depend on.
This is useful when assessing third-party libraries, evaluating software suppliers, and responding to disclosures involving compromised dependencies.
If a malicious package or compromised component is identified, security teams can use SBOMs to find applications that may contain it.
The investigation can then focus on whether the component was installed, executed, or able to access sensitive resources.
SBOMs can help identify outdated, unsupported, or poorly maintained components.
They also support dependency reviews, software inventory management, and more informed decisions about upgrading or replacing components.
One of the most important aspects of SBOM analysis is understanding dependency relationships.
A direct dependency is a component explicitly included by a project.
For example, a Node.js application might declare an HTTP client library in its package.json file.
The developer knows that the application directly depends on this package.
A transitive dependency is introduced through another dependency.
For example:
<escape> Web Application └── HTTP Client Library └── Utility Package └── Vulnerable Component </escape>
The application may never directly reference the vulnerable component, but it can still be included in the dependency tree.
This is why reviewing only top-level dependencies is insufficient.
An SBOM that captures dependency relationships can help analysts trace how a vulnerable or malicious component enters an application.
A common use case is determining whether software contains a component affected by a known vulnerability.
Generate or obtain an SBOM for the application, container image, or software release being assessed.
Where possible, ensure that the inventory corresponds to the exact version or build deployed in the environment.
An outdated SBOM may omit dependencies introduced by later builds or updates.
Review component names, versions, package identifiers, and dependency relationships.
Standardised identifiers such as PURLs help distinguish packages that have similar names but belong to different ecosystems or suppliers.
Compare the component inventory against trusted vulnerability sources, such as the National Vulnerability Database (NVD), vendor advisories, and ecosystem-specific security advisories.
Check whether the recorded component version falls within the affected range described by the advisory.
Do not rely on the component name alone when determining whether a vulnerability applies.
Determine whether the vulnerable functionality is present, enabled, and reachable in the deployed application.
Consider:
The vulnerable version and affected version range.
Whether the component is actually included in the deployed build.
Whether the vulnerable functionality is used.
Whether configuration or compensating controls reduce exposure.
The severity and potential impact of exploitation.
Prioritise components according to risk, taking into account vulnerability severity, known exploitation, exposure, asset criticality, and the availability of a safe fix.
Update or replace affected dependencies according to the vendor's guidance and test the application before deployment.
SBOMs are useful for identifying which components are present, but detecting malicious packages requires additional evidence.
A malicious component might be published under a new package name, introduced through a compromised maintainer account, or inserted into an otherwise legitimate package update.
Look for unexpected packages, unfamiliar suppliers, typosquatting, or dependencies that appeared without a clear development requirement.
A new or unfamiliar package is not automatically malicious. Its identity should be assessed alongside provenance, source code, and behaviour.
Review dependency updates that introduce new packages, unusual version changes, or unexpected modifications to transitive dependencies.
Compare the dependency tree with a previously approved SBOM to identify what changed.
Examine the package registry, source repository, release history, maintainer information, and available provenance attestations.
A package whose published contents cannot be reconciled with its expected source or release process warrants further investigation.
Use source-code analysis, malware scanning, and controlled dynamic analysis to investigate behaviours such as unexpected access to credentials, unexplained file modifications, or connections to suspicious external infrastructure.
Where hashes are available, compare them against trusted references or verified release artefacts.
A matching hash establishes that the compared files are identical, but it does not independently establish that the component is benign. A malicious component can be consistently packaged and distributed.
Important distinction: An SBOM tells analysts what software is reported to be present. It does not, by itself, prove that a component is safe, vulnerable, malicious, or actively exploited.
Consider a fictional organisation that operates an online service built with Node.js. Its SBOM identifies a third-party package called request-helper at version 2.4.1.
A security advisory later reports that a particular range of versions contains a vulnerability.
Stage 1 — Identify the component
Search the SBOM inventory for the package name, ecosystem, version, and package identifier.
Stage 2 — Determine dependency paths
Identify which applications include the package and whether it is a direct or transitive dependency.
Stage 3 — Validate the advisory
Confirm the affected version range using the relevant vendor or ecosystem advisory.
Stage 4 — Assess exposure
Determine whether the affected application uses the vulnerable functionality and whether the relevant attack conditions are present.
Stage 5 — Remediate and verify
Upgrade to a fixed version where available, test the application, redeploy, and generate an updated SBOM.
Stage 6 — Preserve the record
Document the affected applications, remediation actions, validation results, and any residual risk.
This example illustrates vulnerability management, not proof of malicious package activity. If the concern involves malware, investigators must additionally establish whether suspicious code executed and whether any sensitive data or systems were affected.
An SBOM-related alert may arise from a newly disclosed vulnerability, a suspicious dependency change, or a newly identified malicious package.
A structured investigation helps distinguish inventory exposure from confirmed compromise.
Identify the affected software product, build, container image, repository, or deployed application.
Record the SBOM generation time, software version, and environment to establish which release the inventory represents.
Identify new, removed, or changed components.
Investigate unexpected package additions, version changes, and dependency paths. Confirm that differences reflect actual software changes rather than differences in SBOM generation tools or metadata.
Check vulnerability advisories, package registry information, supplier notices, and available threat-intelligence reporting.
For a suspected malicious package, obtain validated package identifiers, versions, hashes, and other campaign-specific indicators from trusted sources.
If malicious activity is suspected, review endpoint or build-runner telemetry for package installation, script execution, file access, process creation, and outbound network activity.
Determine whether the component was merely present in the inventory or actually executed.
Identify what privileges and resources the component could access.
For a library executed during a build, this may include CI/CD secrets, repository tokens, signing credentials, and cloud deployment identities.
For a runtime component, consider the application permissions, data accessible to the process, and network connections available to it.
Correlate findings with identity logs, cloud audit records, package registry activity, and deployment logs.
Look for evidence of credential misuse, unauthorised package publication, suspicious cloud API calls, or modified software artefacts.
Update or remove the affected component, rebuild the application, and generate a fresh SBOM.
Where malicious execution or credential exposure is confirmed, investigate persistence and downstream access, rotate affected credentials, and validate the integrity of dependent systems.
SBOM investigations require both software inventory data and operational evidence.
Evidence sourceWhat to collectPurposeSBOMComponent names, versions, identifiers, dependency relationshipsIdentifies potentially affected softwareDependency lockfilesResolved versions and integrity metadataValidates the dependency treeVulnerability advisoriesAffected version ranges and remediation guidanceDetermines known vulnerability exposurePackage registry recordsPublication dates, maintainers, release historySupports provenance investigationSource repositoriesCode changes and dependency modificationsIdentifies suspicious changesBuild and endpoint logsInstallation, execution, and file activityEstablishes whether a component ranNetwork telemetryDNS requests, destinations, connection metadataInvestigates potential command-and-control or exfiltrationIdentity and cloud logsToken use, API activity, access changesAssesses downstream impactHashes and attestationsIntegrity values and provenance evidenceSupports validation of software artefactsNo single evidence source is sufficient for every case. The strongest conclusions come from correlating the software inventory with execution, network, and identity evidence.
SBOM analysis itself is a defensive activity, not an adversary technique. ATT&CK mappings apply when the investigation identifies associated malicious behaviour.
Potential mappings include:
T1195.001 — Compromise Software Dependencies and Development Tools: Relevant when a dependency or development tool is compromised.
T1195.002 — Compromise Software Supply Chain: Relevant when the software build or distribution process is compromised.
T1059 — Command and Scripting Interpreter: Relevant when malicious components execute commands or scripts.
T1552 — Unsecured Credentials: Potentially relevant when evidence shows that credentials were obtained from insecurely stored locations.
T1041 — Exfiltration Over C2 Channel: Relevant when evidence supports data exfiltration through a command-and-control channel.
These mappings must be based on observed behaviour. A vulnerable component or suspicious dependency does not, by itself, prove that an attack occurred.
Several standards and tools help organisations create, analyse, and maintain SBOM inventories.
SPDX supports structured representation of software packages, licensing, and related component information.
Official resource: https://spdx.dev/
CycloneDX supports software component inventories and can represent dependency relationships and other security-related information.
Official resource: https://cyclonedx.org/
Syft can generate SBOMs from container images, filesystems, and other supported software artefacts.
Official resource: https://github.com/anchore/syft
Grype scans software artefacts and SBOMs for known vulnerabilities.
Official resource: https://github.com/anchore/grype
Dependency-Check helps identify publicly disclosed vulnerabilities associated with dependencies, using supported ecosystem analysers and vulnerability data sources.
Official resource: https://owasp.org/www-project-dependency-check/
These tools serve different purposes. Generating an SBOM, identifying known vulnerabilities, and detecting malicious runtime behaviour are separate tasks that may require multiple controls.
Create inventories during development and build processes, and maintain records for released software. Generate new SBOMs when dependency changes materially alter the component inventory.
Associate each SBOM with a specific software version or build. Define how inventories are refreshed, stored, and matched to deployed assets.
Automatically compare component inventories with relevant vulnerability intelligence, then route validated findings to the teams responsible for affected applications.
Ensure that the inventory captures indirect dependencies wherever possible. Review dependency paths to identify how a vulnerable component enters an application.
Use package metadata, trusted registries, signatures, hashes, and provenance attestations where supported. Assess whether the software artefact corresponds to the expected build and release process.
SBOMs may reveal internal dependencies, product architecture, and software versions. Store and distribute them according to organisational sensitivity requirements.
Track how quickly affected applications are identified, how long remediation takes, and whether fixed versions are present in the next verified build.
A Software Bill of Materials gives organisations visibility into the components that make up their applications. It helps security teams identify vulnerable dependencies, investigate suspicious package changes, assess software supply chain exposure, and prioritise remediation.
However, an SBOM is an inventory rather than a complete security verdict. Vulnerability assessment requires advisory correlation and exposure analysis, while malicious-component investigations require additional evidence from package provenance, code analysis, endpoint telemetry, network monitoring, and identity logs.
The real value of an SBOM is not simply knowing what software is present. It is being able to identify where a risk exists, understand how it entered the environment, and respond before that risk becomes a wider incident.
CISA — Software Bill of Materials
NTIA — The Minimum Elements for a Software Bill of Materials
SPDX — Official Specification and Resources
CycloneDX — SBOM Standard
NIST — Secure Software Development Framework (SSDF)
OWASP — Dependency-Check
Continue reading
Supply Chain Attacks
[{"type":"text","text":" The npm ecosystem enables developers to integrate third-party JavaScript packages into applications quickly. However, malicious packages can abuse this tru...
Supply Chain Attacks
[{"type":"text","text":" GitHub Actions automates software development workflows, including building, testing, and deploying applications. However, if attackers compromise a reposi...
Supply Chain Attacks
The 3CX supply chain attack, disclosed in March 2023, was a significant cyber incident in which attackers compromised the software distribution chain of 3CX, a business communicati...
3 entries, most recent posts.
Cybersecurity researchers have uncovered an AI-assisted cybercrime operation attributed to CyberXero, a financially motivated initial access broker th...
Senior Hosting Security Engineer
The convergence of Operational Technology (OT), the Internet of Things (IoT), and traditional enterprise IT networks is transforming how organisations...
