SBOM Generation via Build Segmentation and Feedback
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional software bill of materials (SBOMs) are not configured to trigger threat mitigation and are often overly inclusive or underinclusive, leading to inaccurate risk assessments and unnecessary remedial actions, especially in large distributed builds.
Innovation Solution
The system identifies and parses programs to generate a modified SBOM by adding new declarations for undeclared code segments similar to existing ones, and uses configuration restriction records to assess and mitigate threats, ensuring accurate risk analysis and resource conservation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional SBOMs include all files from all underlying programs, then the SBOM is comprehensive in identifying potential files, but it results in overinclusiveness and false vulnerability identification
Solution Approach 1:
The patent segments the SBOM into multiple hierarchical levels: build-level SBOM containing only files actually present in the final build, component-level SBOMs for individual programs, and library-level SBOMs. This segmentation allows the system to distinguish between files that are merely available in the build environment versus files that are actually incorporated, thereby reducing false positives while maintaining comprehensive vulnerability tracking.
Solution Approach 2:
The system performs preliminary analysis during the build process to determine which files are actually incorporated into the final build before generating the SBOM. By pre-identifying the exact set of files that will be present in the deployed program, the system avoids including files that would later be identified as false positives in vulnerability assessments.
2Adaptability or versatility
If SBOMs are created during development cycle prior to compilation, then they capture all declared components, but they cannot verify whether components actually exist or are utilized in the final program
Solution Approach 1:
The system implements feedback loops where the SBOM generation process incorporates actual build output information. After compilation and linking, the system feeds back the actual set of files present in the final executable to update and correct the SBOM, thereby verifying which declared components actually exist and are utilized in the final program.
Solution Approach 2:
The SBOM is treated as a dynamic document that evolves through different build stages. Rather than being a static declaration created once during development, the SBOM is continuously updated and refined based on actual build outcomes, allowing it to adapt and reflect the true state of the final program with high precision.
3Adaptability or versatility
If programs are modified during or after compilation to utilize additional files, then the program gains flexibility, but the SBOM no longer represents an exact list of all components
Solution Approach 1:
The system performs periodic updates to the SBOM at key milestones in the software lifecycle: during initial build, after compilation, after linking, and after any post-compilation modifications. Each periodic update re-evaluates the actual file set and synchronizes the SBOM accordingly, ensuring the SBOM remains an accurate representation despite program modifiability.
4Reliability
If conventional systems perform remedial actions on all programs identified in SBOMs, then they ensure thorough security coverage, but they waste resources on unaffected programs
Solution Approach 1:
The system applies partial action by performing remedial actions only on the specific files that are actually present in the final build and identified as vulnerable. Rather than applying remediation to all declared components in the SBOM, the system precisely targets only those files that exist in the deployed program, thereby maintaining security coverage while eliminating waste on non-existent or unaffected files.
Data Source
AI summary
Systems are provided for generating, modifying and using SBOMs for facilitating risk assessment and threat mitigation for corresponding programs, and particularly for large programming builds. The creation and modification of the SBOMs includes processes for omitting declarations referenced in chunk SBOMs of program chunks incorporated into a final programming build associated with a build SBOM, but which are not actually utilized by the final programming build, as well as processes for adding new declarations for code segments that are not declared in the related chunk SBOMs, even though the code segments are utilized by the final programming build. Systems are also configured to use SBOMs in combination with configuration restriction records to assess and resolve threat events in a manner that can prevent unnecessary remedial actions for threat events that appear to be relevant to one or more files or dependencies incorporated into a program.