CI/CD Pipeline Traffic Correlation for Endpoint Baselines and SBOM
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current solutions fail to effectively correlate outbound traffic with CI/CD pipeline steps, establish a baseline for allowed domain names and IP addresses, and generate comprehensive Software Bill of Materials (SBOM), leading to vulnerabilities in software supply chains.
Innovation Solution
A system that correlates outbound traffic with each step of a CI/CD pipeline by establishing a baseline for valid endpoints, alerts on unexpected calls, and generates SBOM using runtime events, comprising network and file monitors, a correlation server, and a data store to track and analyze network and file events during pipeline runs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If a list of known bad domain names/IP addresses is used for detection, then detection capability is improved, but the solution fails because the list is not complete or comprehensive and needs continuous updates
Solution Approach 1:
The system performs preliminary actions by establishing a baseline of allowed domain names and IP addresses before the pipeline execution. This baseline is created by analyzing the pipeline configuration files and documenting expected network calls in advance, allowing the system to proactively identify and alert on deviations from the expected behavior without relying on incomplete blacklists
Solution Approach 2:
Instead of using a blacklist approach (known bad addresses), the patent inverts the logic by using a whitelist approach (known good addresses). The system documents what domains/IPs should be called based on pipeline configuration, and any deviation from this documented baseline is flagged as suspicious, thereby achieving comprehensive detection without relying on incomplete negative lists
2Reliability
If a firewall is configured to allow only known good domain names/IP addresses, then security is improved, but the solution fails because it is hard to know what domains or IP addresses should be allowed when a pipeline is run
Solution Approach 1:
The system performs self-service by automatically analyzing pipeline configuration files (such as GitHub Actions workflow files, Jenkins pipeline scripts) to extract and document the domain names and IP addresses that the pipeline is expected to call. This automated documentation eliminates the manual effort required to configure firewalls, as the system generates the allowed list directly from the pipeline definitions without requiring user intervention
Solution Approach 2:
The patent replaces the manual mechanical process of configuring firewalls with automated computational analysis. Instead of users manually reading pipeline configurations and configuring firewalls, the system uses automated tools to parse pipeline configuration files, extract network endpoint information, and generate documented baselines, thereby substituting manual configuration with automated analysis
3Measurement precision
If computer programs are executed to see what domain names/IP addresses are called, then detection capability is improved, but the solution fails because it does not correlate outbound domain names and IP addresses with a pipeline or each step of a pipeline to establish a baseline
Solution Approach 1:
The system applies segmentation by breaking down the pipeline execution into discrete steps (such as checkout, build, test, deploy) and correlating outbound network calls with specific steps. By segmenting the analysis at the step level rather than treating the entire pipeline as a monolithic unit, the system can establish granular baselines for each step, providing contextual information about which step is making which network call and enabling more precise security monitoring
4Productivity
If Software Bill of Materials (SBOM) solutions rely on software dependency manifest and lock files, then SBOM generation is improved, but the solution fails because they provide incomplete information since exact version is determined at the time of software build in CI/CD
Solution Approach 1:
The system performs preliminary action by analyzing pipeline configuration files before the actual build execution to document the expected software dependencies and versions. By examining the pipeline configuration in advance (such as analyzing Go module files, npm package.json, or other dependency declarations in the context of the specific pipeline run), the system can prepare an accurate SBOM that reflects the exact versions that will be built, rather than relying on range specifications that may not resolve to exact versions
Data Source
AI summary
The disclosed system and process involve correlating outbound traffic with a CI/CD pipeline. CI/CD Pipelines consist of multiple jobs, and each job's steps execute on the same runner host. Network monitors relay information about domain names and network connections during job execution to the data store. Once all pipeline jobs are complete, the correlation server links domain names and connections to determine endpoints. This correlation, showing outbound traffic for each step, is accessible to the pipeline owner for review. An alert is triggered for new endpoints relative to the baseline. Owners can block unexpected endpoints based on explicitly defined lists. The correlation server also identifies file events, aiding in detecting suspicious file and software build overwrite events for combating software supply chain attacks. Observed file and network events contribute to generating a Software Bill of Materials (SBOM) through runtime events.