IP Library Granted Patent US 12,282,553
Granted Patent B1
US 12,282,553 · App. 18/055,684 · Granted Apr 22, 2025

Model-based process to validate build integrity of software products

Inventors: Jeremy W. Long (Herndon, VA); David Kenneth Eggen (St Louis Park, MN)
Assignee: Wells Fargo Bank, N.A.
G06F21/563G06F21/577G06F2221/033
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 12,282,553
App. No.
18/055,684
Granted
Apr 22, 2025
Kind
B1
Abstract

Techniques are described for a model-based process to validate build integrity of software products. A build integrity validation system generates a build artifact model including one or more software components extracted from a build artifact resulting from a software build process of source code and generates a source code including one or more software components extracted from the source code. The system compares the software components of the build artifact model and the software components of the source code model, and identifies at least one discrepancy between the build artifact model and the source code model. The system determines a level of risk associated with the at least one discrepancy and, in response to determining the level of risk associated with the at the least one discrepancy, generates a decision indicating whether the at least one build artifact is approved for use in a software product.

Claims (70)

1. A method comprising:

generating, by a computing system, a build artifact model from at least one build artifact resulting from a software build process of source code, wherein the build artifact model includes one or more software components extracted from the at least one build artifact;

generating, by a computing system, a source code model from the source code, wherein the source code model includes one or more software components extracted from the source code;

comparing, by the computing system, the one or more software components of the build artifact model and the one or more software components of the source code model;

identifying, by the computing system and based on the comparison, whether at least one discrepancy occurs between the one or more software components of the build artifact model and the one or more software components of the source code model, wherein identifying that the at least one discrepancy occurs comprises identifying at least one software component of the build artifact model that does not match with the one or more software components of the source code model such that the at least one build artifact is not producible by the source code;

in response to identifying the at least one discrepancy, determining, by the computing system, a level of risk associated with the at least one discrepancy; and

in response to determining the level of risk associated with the at the least one discrepancy, generating, by the computing system, a decision indicating whether the at least one build artifact is approved for use in a software product.

2. The method of claim 1 , wherein the source code is compiled into the at least one build artifact by a build server, and wherein the build server is independent from the computing system.

3. The method of claim 1 , further comprising, in response to determining that the level of risk associated with the at least one discrepancy exceeds a threshold, generating a report indicating the at least one discrepancy and that data was potentially modified during the software build process of the source code that produced the at least one build artifact.

4. The method of claim 1 , wherein generating the build artifact model comprises:

extracting tokens from the at least one build artifact,

determining the one or more software components from the tokens extracted from the at least one build artifact, and

assigning a threat level to each software component of the build artifact model, wherein the threat level indicates a level of risk if the respective software component of the build artifact model does not match with a corresponding software component of the source code model.

5. The method of claim 1 , wherein generating the source code model comprises:

extracting tokens from the source code,

determining the one or more software components from the tokens extracted from the source code, and

assigning a threat level to each software component of the source code model, wherein the threat level indicates a level of risk if the respective software component of the source code model does not match with a corresponding software component of the build artifact model.

6. The method of claim 1 , wherein identifying whether the at least one discrepancy occurs comprises generating an issue list including entries for the one or more software components of the build artifact model and the one or more software components of the source code model, wherein, for each software component, the issue list further includes an assigned threat level indicative of a level of risk if the respective software component of one of the models does not match with the one or more software components of the other one of the models, and an audit statement indicative of either a match or a discrepancy between the respective software component of the one of the models and the one or more software components of the other one of the models.

7. The method of claim 6 , wherein identifying that the at least one discrepancy occurs comprises identifying at least one entry in the issue list for the at least one software component of the build artifact model that includes an audit statement indicative of a discrepancy between the at least one software component of the build artifact model and the one or more software components of the source code model.

8. The method of claim 7 , wherein determining the level of risk associated with the at least one discrepancy comprises:

filtering the one or more software components of the build artifact model and the one or more software components of the source code model included in the issue list based on audit statements indicative of discrepancies;

accumulating counters associated with the filtered software components, wherein the counters are weighted based on threat levels assigned to the filtered software components; and

determining the level of risk associated with the at least one discrepancy based on the accumulated counters associated with the filtered software components.

9. The method of claim 8 , wherein generating the decision indicating whether the at least one build artifact is approved for use in a software product comprises:

determining whether the accumulated counters associated with the filtered software components exceed a threshold;

in response to determining that the accumulated counters exceed the threshold, generating a decision that the at least one build artifact is not approved for use in a software product; and

in response to determining that the accumulated counters do not exceed the threshold, generating a decision that the at least one build artifact is approved for use in a software product.

10. The method of claim 7 ,

wherein determining the level of risk associated with the at least one discrepancy comprises identifying at least one entry in the issue list for the at least one software component of the build artifact model that includes an assigned threat level indicative of a high level of risk and an audit statement indicative of the at least one software component of the build artifact model not matching the one or more software components of the source code model; and

wherein generating the decision indicating whether the at least one build artifact is approved for use in a software product comprises, in response to the assigned threat level indicative of the high level of risk, generating a decision that the at least one build artifact is not approved for use in a software product.

11. The method of claim 1 , further comprising, in response to identifying no discrepancies between the one or more software components of the build artifact model and the one or more software components of the source code model, generating a decision indicating that the at least one build artifact is approved for use in a software product.

12. A computing system comprising:

a memory; and

one or more processors in communication with the memory, the one or more processors configured to:

generate a build artifact model from at least one build artifact resulting from a software build process of source code, wherein the build artifact model includes one or more software components extracted from the at least one build artifact;

generate a source code model from the source code, wherein the source code model includes one or more software components extracted from the source code;

compare the one or more software components of the build artifact model and the one or more software components of the source code model;

identify, based on the comparison, whether at least one discrepancy occurs between the one or more software components of the build artifact model and the one or more software components of the source code model, wherein to identify that the at least one discrepancy occurs, the one or more processors are configured to identify at least one software component of the build artifact model that does not match with the one or more software components of the source code model such that the at least one build artifact is not producible by the source code;

in response to identifying the at least one discrepancy, determine a level of risk associated with the at least one discrepancy; and

in response to determining the level of risk associated with the at the least one discrepancy, generate a decision indicating whether the at least one build artifact is approved for use in a software product.

13. The computing system of claim 12 , wherein the one or more processors are configured to, in response to determining that the level of risk associated with the at least one discrepancy exceeds a threshold, generate a report indicating the at least one discrepancy and that data was potentially modified during the software build process of the source code that produced the at least one build artifact.

14. The computing system of claim 12 , wherein to generate the build artifact model, the one or more processors are configured to:

extract tokens from the at least one build artifact,

determine the one or more software components from the tokens extracted from the at least one build artifact, and

assign a threat level to each software component of the build artifact model, wherein the threat level indicates a level of risk if the respective software component of the build artifact model does not match with a corresponding software component of the source code model.

15. The computing system of claim 12 , wherein to generate the source code model, the one or more processors are configured to:

extract tokens from the source code,

determine the one or more software components from the tokens extracted from the source code, and

assign a threat level to each software component of the source code model, wherein the threat level indicates a level of risk if the respective software component of the source code model does not match with a corresponding software component of the build artifact model.

16. The computing system of claim 12 , wherein to identify whether the at least one discrepancy occurs, the one or more processors are configured to generate an issue list including entries for the one or more software components of the build artifact model and the one or more software components of the source code model, wherein, for each software component, the issue list further includes an assigned threat level indicative of a level of risk if the respective software component of one of the models does not match with the one or more software component of the other one of the models, and an audit statement indicative of either a match or a discrepancy between the respective software component of the one of the models and the one or more software components of the other one of the models.

17. The computing system of claim 16 , wherein to identify that the at least one discrepancy occurs, the one or more processors are configured to identify at least one entry in the issue list for the at least one software component of the build artifact model that includes an audit statement indicative of a discrepancy between the at least one software component of the build artifact model and the one or more software components of the source code model.

18. The computing system of claim 17 , wherein to determine the level of risk associated with the at least one discrepancy, the one or more processors are configured to:

filter the one or more software components of the build artifact model and the one or more software components of the source code model included in the issue list based on audit statements indicative of discrepancies;

accumulate counters associated with the filtered software components, wherein the counters are weighted based on threat levels assigned to the filtered software components; and

determine the level of risk associated with the at least one discrepancy based on the accumulated counters associated with the filtered software components.

19. The computing system of claim 18 , wherein to generate the decision indicating whether the at least one build artifact is approved for use in a software product, the one or more processors are configured to:

determine whether the accumulated counters associated with the filtered software components exceed a threshold;

in response to determining that the accumulated counters exceed the threshold, generate a decision that the at least one build artifact is not approved for use in a software product; and

in response to determining that the accumulated counters do not exceed the threshold, generate a decision that the at least one build artifact is approved for use in a software product.

20. The computing system of claim 17 ,

wherein to determine the level of risk associated with the at least one discrepancy, the one or more processors are configured to identify at least one entry in the issue list for the at least one software component of the build artifact model that includes an assigned threat level indicative of a high level of risk and an audit statement indicative of the at least one software component of the build artifact model not matching the one or more software components of the source code model; and

wherein to generate the decision indicating whether the at least one build artifact is approved for use in a software product, the one or more processors are configured to, in response to the assigned threat level indicative of the high level of risk, generate a decision that the at least one build artifact is not approved for use in a software product.

21. The computing system of claim 12 , wherein the one or more processors are configured to, in response to identifying no discrepancies between the one or more software components of the build artifact model and the one or more software components of the source code model, generate a decision indicating that the at least one build artifact is approved for use in a software product.

22. A computer-readable medium storing instructions that, when executed, cause one or more processors to:

generate a build artifact model from at least one build artifact resulting from a software build process of source code, wherein the build artifact model includes one or more software components extracted from the at least one build artifact;

generate a source code model from the source code, wherein the source code model includes one or more software components extracted from the source code;

compare the one or more software components of the build artifact model and the one or more software components of the source code model;

identify, based on the comparison, whether at least one discrepancy occurs between the one or more software components of the build artifact model and the one or more software components of the source code model, wherein to identify that the at least one discrepancy occurs, the instructions cause the one or more processors to identify at least one software component of the build artifact model that does not match with the one or more software components of the source code model such that the at least one build artifact is not producible by the source code;

in response to identifying the at least one discrepancy, determine a level of risk associated with the at least one discrepancy; and

in response to determining the level of risk associated with the at the least one discrepancy, generate a decision indicating whether the at least one build artifact is approved for use in a software product.

Assignments (2)
REQUEST FOR ADDRESS CHANGE Recorded Dec 5, 2025
From: WELLS FARGO BANK, N.A.
To: WELLS FARGO BANK, N.A.
Reel/Frame 073895/0426 →
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jan 23, 2023
From: LONG, JEREMY W.; EGGEN, DAVID KENNETH
To: WELLS FARGO BANK, N.A.
Reel/Frame 062454/0559 →
References Cited (37)
US 6536037B1 · Guheen et al. · 2003 [cited by applicant]
US 8429628B2 · Spurlin · 2013 [cited by applicant]
US 9063672B2 · Madl et al. · 2015 [cited by applicant]
US 11055077B2 · Krishnamoorthy · 2021 [cited by applicant]
US 11055418B2 · McDuff · 2021 [cited by examiner]
US 11494493B1 · Baird · 2022 [cited by applicant]
US 11640282B2 · Giltner et al. · 2023 [cited by applicant]
US 20060110043A1 · Reissman · 2006 [cited by examiner]
US 20140282403A1 · Frenkiel · 2014 [cited by examiner]
US 20200004519A1 · Ryall et al. · 2020 [cited by applicant]
US 20220058011A1 · Scheinkman et al. · 2022 [cited by applicant]
US 20220164171A1 · Johnson et al. · 2022 [cited by applicant]
US 20220300280A1 · Rafey · 2022 [cited by examiner]
US 20220398308A1 · Zerah · 2022 [cited by examiner]
CN 103559125A · 2014 [cited by applicant]
CN 110263539A · 2019 [cited by applicant]
JP 2013152559A · 2013 [cited by applicant]
JP 2019220110A · 2019 [cited by applicant]
WO 2020240830A1 · 2020 [cited by applicant]
Office Action from U.S. Appl. No. 17/650,346 dated May 17, 2024, 29 pp. [cited by applicant]
“Binary Authorization for Borg: how Google verifies code provenance and implements code identity”, Google Cloud, accessed on Feb. 8, 2022, Retrieved from: https://cloud.google.com/security/binary-authorization-for-borg/… [cited by applicant]
“Image Layer Details—owasp/dependency-check:6.2.2”, Dockerhub, Accessed on Feb. 8, 2022, Retrieved from: https://hub.docker.com/layers/owasp/dependency-check/6.2.2/images/sha256-4c02a0955cc085b10d6360063eeb78486bfc19782… [cited by applicant]
“JAR File Specification”, ORACLE, accessed on Feb. 8, 2022, Retrieved from: https://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html, 14 pp. [cited by applicant]
“Linux Foundation Announces Free sigstore Signing Service to Confirm Origin and Authenticity of Software”, Linux, Mar. 9, 2021, 3 pp. [cited by applicant]
“Sample application”, Docker Doc, Accessed on Feb. 8, 2022, Retrieved from: https://docs.docker.com/get-started/02_our_app/, 4 pp. [cited by applicant]
“SUNSPOT: An Implant in the Build Process”, CrowdStrike Intelligence Team, Jan. 11, 2021, 8 pp. [cited by applicant]
Bhardwaj et al., “Reverse Engineering—A Method for Analyzing Malicious Code Behavior”, 2021 International Conference on Advances in Computing, Communication, and Control, Dec. 3, 2021, 5 pp., URL: https://ieeexplore.iee… [cited by applicant]
Long, “DependencyCheck/Dockerfile”, Github, Accessed on Feb. 8, 2022, Retrieved from: https://github.com/jeremylong/DependencyCheck/blob/v6.2.2/Dockerfile, 2 pp. [cited by applicant]
Oracle et al., “Chapter 4. The class File Format”, 41 pp., Retrieved from the Internet on Feb. 8, 2022, from URL: https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html .. [cited by applicant]
Ramakrishna, “New Findings From Our Investigation of Sunburst”, Jan. 11, 2021, 5 pp. [cited by applicant]
Shi et al., “Reverse Engineering of Design Patterns from Java Source Code”, 21st IEEE/ACM International Conference on Automated Software Engineering, IEEE, Sep. 18, 2006, pp. 123-134, URL: https://ieeexplore.ieee.org/ab… [cited by applicant]
Thompson, “Reflections on Trusting Trust”, Turing Award Lecture, vol. 27, No. 8, Aug. 1984, 3 pp. [cited by applicant]
U.S. Appl. No. 17/650,346, filed Feb. 8, 2022, naming inventors Long. [cited by applicant]
Wheeler, “David A. Wheeler's Page on Fully Countering Trusting Trust through Diverse Double-Compiling (DDC)—Countering Trojan Horse attacks on Compilers”, accessed on Jan. 25, 2021, retrieved from https://dwheeler.com/t… [cited by applicant]
Response to Office Action dated May 17, 2024 from U.S. Appl. No. 17/650,346, filed Jul. 26, 2024, 3 pp. [cited by applicant]
Office Action from U.S. Appl. No. 17/650,346 dated Nov. 18, 2024, 21 pp. [cited by applicant]
Response to Office Action dated Nov. 18, 2024 from U.S. Appl. No. 17/650,346, filed Feb. 18, 2025, 12 pp. [cited by applicant]
Cited By (2)
US 12,475,230 US 12,665,922