Projects
Understand what Projects are in SBOM Observer, how they differ from Applications, and why this matters for impact analysis.
A Project in SBOM Observer is a user-defined grouping that allows you to look at several related components as one unit. Unlike the raw data extracted from SBOMs and attestations, Projects are something you define to give structure and meaning to your software inventory.
What Projects are
Projects are organizational containers that let you group components logically, even when those components come from different SBOMs or sources. For example, a platform made up of multiple services, a set of related libraries, or a collection of containers that work together can all be tracked as a single Project.
This concept is useful as while SBOMs describe individual artifacts, your actual systems often consist of many related pieces working together. Projects bridge that gap by letting you impose your own structure on top of the raw SBOM data.
Projects are user-defined. They don't come from your SBOMs. You create them to reflect how your organization thinks about and manages software.
Projects vs Applications
Projects and Applications are both diffrent types of components that can have dependencies.
The difference is that projects and their dependencies are defined by users in the UI, while Applications are imported from SBOMs.
Why Projects matter for impact analysis
The real value of Projects becomes clear when you need to understand the impact of a vulnerability across your infrastructure. Projects give you a focused view of what's affected within a specific system or platform.
When analyzing impact for a Project, SBOM Observer can visualize dependency relationships and show which components in your Project are affected by a vulnerability, including transitive dependencies through containers and libraries.
This visualization helps you:
- Quickly assess the blast radius within a specific system
- Understand which applications need updates
- See dependency chains that connect vulnerable components to your root applications
- Coordinate remediation efforts across related services
Projects are especially useful for microservices architectures where a single business capability is delivered by multiple services that need to stay synchronized.
You're not limited to tracking only the root components from SBOMs. You can add components at any level, like a specific library version, a shared dependency, or a transitive component deep in the dependency tree.
This means you can create Projects that reflect your actual operational needs:
- Monitor a critical shared library across all applications that use it
- Track a specific container image version deployed across multiple environments
- Group all components maintained by a particular team
- Organize components by business domain or compliance boundary
When to use Projects
Projects are most valuable when:
- You need to monitor multiple related components as a single unit
- Your system architecture spans multiple SBOMs
- You want focused impact analysis for a specific platform or service
- You need to organize components by team, domain, or business function
- You want to track dependencies that aren't the main subject of an SBOM
By defining Projects that match how your organization actually builds and operates software, you gain practical insight that goes beyond what raw SBOM data can provide on its own.
Next steps
- Follow the Create and manage Projects guide to set up a Project and add components.