Software Container Attribution Through Deterministic Build-File Mapping

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current techniques for attributing vulnerabilities in software containers are inefficient, requiring significant time and resources, and often rely on subjective human analysis, leading to inconsistent and non-deterministic results, which hinders quick correction and prevention of similar vulnerabilities.

Innovation Solution

A method and system for deterministic attribution of software containers by de-compiling configuration files to identify candidate build files, matching them based on command similarity, creation time, and hierarchical relationships, and populating an inventory with vulnerability data to trace vulnerabilities to specific code lines.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If manual investigation by security researchers is used for cyber attribution, then flexibility and judgment in analysis is maintained, but significant time and resources are required

Engineering Contradiction:
Improveattribution accuracyVSAvoidinvestigation time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system performs preliminary actions by automatically de-compiling container images and extracting build information before actual vulnerability investigation occurs. The configuration files are pre-processed and indexed, creating a ready-to-query database that eliminates manual de-compilation during incident response, thus reducing investigation time while maintaining attribution accuracy.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent replaces the mechanical manual investigation process with an automated computer-based system. The manual de-compilation and analysis performed by security researchers is substituted with automated tools that extract, parse, and index container configuration files, build information, and dependency graphs, significantly reducing the time and resources required for cyber attribution.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

2Reliability

If manual analysis is used for vulnerability attribution, then subjective judgment is applied, but results are not deterministic and subject to debate

Engineering Contradiction:
Improveattribution consistencyVSAvoidattribution determinism
Core Design Contradiction:
ReliabilityVSMeasurement precision

Solution Approach 1:

The system implements feedback mechanisms where the automated attribution results can be validated and refined. The query results provide feedback about the attribution confidence levels and can trigger re-investigation when uncertainty is detected, ensuring consistent and deterministic results while maintaining the ability to handle complex edge cases.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The patent changes the parameters of analysis by systematically extracting and indexing specific attributes from container images such as build timestamps, layer hashes, dependency versions, and configuration metadata. These standardized parameters enable deterministic comparisons and attributions, eliminating the subjectivity inherent in manual analysis while maintaining comprehensive investigative capability.

Inventive Principle:
Principle #35Parameter changes

3Difficulty of detecting and measuring

If current container security techniques are used, then vulnerability identification is possible, but root cause cannot be identified

Engineering Contradiction:
Improvevulnerability detectionVSAvoidroot cause information
Core Design Contradiction:
Difficulty of detecting and measuringVSLoss of information

Solution Approach 1:

The system segments the container image into its constituent components: base images, layers, dependencies, build configurations, and runtime artifacts. Each segment is independently analyzed and tracked through the build process, allowing the system to trace vulnerabilities back to their specific sources in the segmented architecture, thereby identifying root causes that remain hidden in monolithic container images.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent performs preliminary actions by capturing and indexing build information, dependency relationships, and configuration data during the container creation process. This preliminary documentation of the build provenance and component relationships enables later root cause analysis without requiring re-decompilation or re-investigation, thus providing both vulnerability detection and root cause identification capabilities.

Inventive Principle:
Principle #10Preliminary action

4Productivity

If vulnerabilities are detected without root cause identification, then quick response is possible, but similar vulnerabilities cannot be prevented

Engineering Contradiction:
Improveresponse speedVSAvoidprevention capability
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The system performs preliminary actions by pre-indexing build information, dependency graphs, and configuration metadata during the container build process. This pre-prepared information enables rapid vulnerability response while simultaneously providing the contextual data needed to identify root causes and prevent recurrence, thus achieving both fast response and effective prevention without compromising either capability.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS20250258932A1Cyber attribution of software containers
Publication Date: 2025.08.14 WIZ INC
  • US20250258932A1 patent drawing
  • US20250258932A1 patent drawing
  • US20250258932A1 patent drawing

AI summary

A system and method for software containers attribution are provided. The method includes de-compiling a configuration file of a container image of a software container; identifying at least one candidate build file in the de-compiled configuration file, wherein the at least one candidate build potentially formed the container image; determining if at least one matching condition is satisfied between each of the at least one candidate build file and the de-compiled configuration file; associating the configuration file with each candidate build file satisfying the matching condition; and updating an inventory with the associated configuration file and the respective candidate build, wherein such association provides a direct mapping between the container image and the build files formed the container image.