GitLab

Abstract A method for assessing vulnerable flows in a cloud-native application, the method including the steps of: mapping runtime functions in microservices in the cloud-native application; mapping the application cloud-native stack infrastructure configurations; mapping logical flows between microservices and third-party components in the cloud-native application; creating and executing security tests on the mapped logical flows, infrastructure configurations and runtime functions to return tested runtime behavior; and analyzing the tested runtime behavior of the cloud native application to validate the potential vulnerable logical flows so as to return validated vulnerable flows.

Abstract Embodiments described herein are directed to determining whether an application executing on a compute instance has been corrupted or compromised by malicious code. This may achieved by statically analyzing an image file from which the application is based to determine characteristics thereof. Such characteristics are representative of the behavior that is expected to be performed by the application during execution. During execution of the application, runtime characteristics of the application are determined, which are determined based on an analysis of the address space in memory allocated for a computing process of the application. The statically-determined characteristics are compared to the determined runtime characteristics to determine discrepancies therebetween. In the event that a discrepancy is found, a determination is made that the application has been compromised or corrupted and an appropriate remedial action is automatically performed.

Abstract Resources, like source code, can be stored in a repository and managed through a resource repository system. The resource repository system includes a processor and a memory for storing a plurality of data structures, each data structure comprising a current version of a corresponding resource and at least one past version of the corresponding resource. The processor is communicatively coupled to the memory and configured to: request a transaction on a resource of a repository; create a snapshot of the repository; perform reads and/or writes of the transaction against the snapshot; evaluate potential conflicts between concurrently committed transactions; if no conflict is found, commit the transaction by persisting it to a write-ahead log; and update the repository based on the write-ahead log.

Abstract A method or system for testing and benchmarking commits made on source code. The system extracts commits from a history of a first code history that records a sequence of commits made thereon. The extracted commits are then combined into a sequence of patches, each of which includes changes made during consecutive commits. The system also establishes a connection with a system under test (SUT) having a second code repository corresponding to a historical version of the first code repository before the extracted commits were made, and sequentially applies the sequence of the patches to the second code repository. Performance of the SUT is monitored during the application of the sequence of the patches to determine whether the SUT performs as expected after the application of each patch.

Abstract A system or a method for analyzing a software project for vulnerabilities. The system extracts scopes of source code, each of which is a source code block that contains a definition of an entity. The system also receives a vulnerability report relating to the source code. The vulnerability report identifies a vulnerability at a line of the source code. The system identifies a subset of the scopes of source code that contains the line of source code where the vulnerability is identified. The system identifies, based on smatch values, a minimum scope among the subset of the scopes that contains the line of source code where the vulnerability is identified, and generates a scoped vulnerability report recording the minimum scope and the vulnerability.

Abstract A system and method to adaptively generate a program model. Source code of a program to be tested for code issues, and a set of predefined patterns to be tested in the source code are received. Feature configuration data is generated by determining a set of features corresponding to the received set of predefined patterns. A set of program models is identified by selecting, for each feature in the set of features, a program model from among a plurality of program models that is optimized for the feature. A dynamic program model is built based on the identified set of program models, the dynamic program model being adapted to resolve each of the patterns included in the received set of predefined patterns. And the source code is tested for code issues by extracting from the dynamic program model instances of each of the set of predefined patterns.