SYSTEM AND METHOD FOR PREDICTING PLATFORM SECURITY CONDITIONS - Patent application

Abstract

The system may be configured to evaluate the state or condition of a stack of services. Some embodiments may include monitoring the source code, base image, and runtime environment of each of a plurality of microservices in the stack via a set of first, second, and third security tools configured to generate first, second, and third vulnerability scores, respectively. Each of the tools may be selectable and may include at least one scanner or sensor configured to output historical data. The microservices may then operate with respect to the same business objectives or set of rules. The method may further include iteratively predicting a security assessment of the stack of microservices via the model based on the first, second, and third scores, and determining, based on the predicted assessment, the amount of resources required by a security team to enhance the security assessment via resource implementation.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Patent Application No. 17 / 980,336, filed November 3, 2022, entitled "SYSTEMS AND METHODS FOR PREDICTING A PLATFORM SECURITY CONDITION," the entire contents of which are incorporated herein by reference.

[0002] (Technical field) The present disclosure generally relates to systems and methods for monitoring a stack of cloud services.

[0003] (background) Security attacks can occur dynamically, for example, with computationally feasible timing, across one or more vulnerabilities. For example, as soon as one risk is resolved, another threat may emerge shortly thereafter. This makes it increasingly difficult for application security (AppSec) teams to fully assess the state of the entire cloud platform and resolve issues before users and / or the business are adversely affected.

[0004] AppSec can be measured as a performance metric, typically assessing success in terms of progress toward an organization's long-term goals. Application vulnerabilities contribute to information technology (IT) risk. They contribute to overall business risk, and businesses often intend to reduce IT risk to zero.

[0005] Known monitoring tools and / or security utilities are not capable of providing a complete overview of all ecosystems related to the platform needs of an application. Such tools are, for example, limited to assessing only the current state. However, security degradation (or enhancement) can only be detected and addressed after it occurs within the system. This creates a need for proactive methods that can predict changes in security value. Summary of the Invention

[0006] Systems and methods are disclosed for determining at least one of the overall state of a global cloud security platform, the history of previous components, and the state of current components. Accordingly, one or more aspects of the present disclosure relate to a method for monitoring (i) source code, (ii) base image (BI), and (iii) runtime environment of each of a plurality of microservices in a stack via a set of first, second, and third security tools configured to generate first, second, and third vulnerability scores, respectively. Each of the security tools may be selectable and may include at least one scanner or sensor configured to output historical data. The microservices (e.g., in a cloud platform) may operate in a unified manner. For example, the microservices may share a set of operating parameters, including the same business goals and / or set of rules. The method may further include iteratively predicting a security assessment of the stack of microservices via a model based on the first, second, and third scores, and determining, based on the predicted assessment, an amount of resources required by a security team to enhance the security assessment via resource implementation.

[0007] The methods are implemented by a system that includes one or more hardware processors configured with machine-readable instructions and / or other components. The system includes one or more processors and other components or media on which, for example, the machine-readable instructions may be executed. An implementation of any of the described techniques and architectures may include a method or process, an apparatus, a device, a machine, a system, or instructions stored on a computer-readable storage device.

[0008] Details of specific implementations are set forth in the accompanying drawings and the following description. Like reference numerals may refer to like elements throughout the specification. Other features will become apparent from the drawings and the following description, including the claims. However, the drawings are for the purpose of illustration and description only and are not intended as a definition of the scope of the present disclosure. [Brief explanation of the drawings]

[0009] [Figure 1] 1 illustrates an example system for dynamically predicting the security state of a microservices stack, according to one or more embodiments. [Figure 2] 1 illustrates aspects of an evaluated (e.g., containerized) software release, according to one or more embodiments. [Figure 3] 1 illustrates an example of data usable by a base image scanning tool, according to one or more embodiments. [Figure 4] 1 illustrates vulnerability mapping from quantitative scores to qualitative ratings, according to one or more embodiments. [Figure 5] 1 illustrates an example of data usable by an environmental scanning tool, according to one or more embodiments. [Figure 6] 1 illustrates a discrepancy between vulnerability scores and number of vulnerabilities, according to one or more embodiments. [Figure 7-8] 1 illustrates an example of data usable by a source code scanning tool, according to one or more embodiments. [Figure 9]1 illustrates an example of weighted values ​​and predicted values ​​that may be predicted by one or more embodiments. [Figure 10] 1 illustrates an example in which an increase in vulnerabilities may require the application of patches to maintain or reduce a vulnerability score, according to one or more embodiments. [Figure 11] 1 illustrates a process for predicting and reporting security conditions, according to one or more embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0010] As used throughout this application, the word "may" is used in its permissive sense (i.e., having the possibility) rather than its mandatory sense (i.e., meaning must). Words such as "include," "including," "includes," and the like mean including but not limited to. As used herein, the singular forms "a," "an," and "the" include the plural unless the context clearly requires otherwise. As employed herein, the term "number" shall mean one or an integer greater than one (i.e., plural).

[0011] As used herein, a statement that two or more parts or components are "coupled" shall mean that the parts are joined or cooperate directly or indirectly, i.e., through one or more intermediate parts or components, so long as a link occurs. As used herein, "directly coupled" means that the two elements are in direct contact with each other.

[0012] Unless otherwise indicated, throughout this specification, discussions utilizing terms such as "processing," "computing," "calculating," "determining," etc., are understood to refer to the actions or processes of a particular apparatus, such as a special purpose computer or similar special purpose electronic processing / computing device.

[0013] Disclosed herein is a method for creating a security score for a project using any number of security sensors. The sensors can be configured to output data in a particular manner. For example, a release checklist can be created for each microservice on a cloud platform. Third parties are risk factors, and reports contemplated herein can be more detailed regarding third parties, involving base image security and / or core reviews, etc. The reports can be user-customizable (e.g., via UI device 18 of FIG. 1 ). Using the security score, processor 20 of system 10 of FIG. 1 can be configured to determine quantitative and / or qualitative work that needs to be performed by a security team to maintain or improve at least the current security level or security posture of the project. For example, using a forecasting module, processor 20 can be configured to estimate a possible security posture for a subsequent release. In this or another example, system 10 can enable a security team to proactively take appropriate measures.

[0014] The approach disclosed herein improves upon known manual forms of testing, where AppSec teams may consider the behavior of each microservice and the relationships between them, for example, to identify potential business impacts. However, this testing methodology assumes errors in the business logic and cannot be easily automated.

[0015] Microservices as contemplated herein may have an architecture, structure, and / or style having some aspects of service-oriented architecture (SOA). These microservices may form a collection of loosely coupled services; for example, these services may be fine-grained, may have lightweight, non-change-forcing protocols (e.g., via containers), and / or may have reduced network communication requirements (e.g., to maintain loose coupling). Each microservice may, for example, comprise its own project by a team of developers, each with its own development lifecycle, practices, and routines. Microservices may have three layers, including microservice source code, source code dependencies (also known as third parties), and a runtime environment.

[0016] In some embodiments, microservices implemented on multiple cloud computers may be implemented using different programming languages, databases, hardware and software environments, and / or serverless computing based on business and / or application needs. Microservices scale up only the microservices that support resource-constrained functionality, thereby providing the benefits of resource and cost optimization. Microservices may be independently deployable and have endpoints that can be logically combined with other microservices to build various applications.

[0017] The approach disclosed herein allows AppSec teams to eliminate the effort that would otherwise be used in manual testing, for example, in scenarios where existing automated tools are insufficient. In this manner, system 10 defines implementations where additional effort and / or resources can be applied to fix one or more security issues identified by system 10.

[0018] The approaches disclosed herein may further enable a measurement of one or more information technology (IT) risks and at least a simple estimation of how much work may be required to at least maintain the security posture of the same components. The approaches disclosed herein may also enable an aggregation of the security posture of each of the components and / or the platform, e.g., into a single metric. In some embodiments, the security posture of each microservice component and / or the platform may be aggregated into a single metric (e.g., for simplification by summing or otherwise combining the scores of individual microservices).

[0019] The system 10 shown in FIG. 1 includes a processor 20 (with components described below), sensors 50 (described below), cloud computers 90 (e.g., 90-1, 90-2, . . . 90-n, where n is a natural number), a network 70, and the surrounding structure of the processor 20 (also described below). The approach disclosed herein may be further extensible by design, for example, considering whether all security tools provide historical data and the current state of the application. In a non-limiting example, if a seasonality application detects a composite forecast (seasonal and trend-based) that could result in CPU utilization exceeding 90% within the next hour, a user may request a trigger from the microservice manager. In one embodiment, when these triggers are met, they may trigger the output of time series data for consumption by the target microservice.

[0020] 1 , processor 20 is configured to execute one or more computer program components via machine-readable instructions. The computer program components may include one or more of an information component 30, a sensor scoring component 32, a monitoring component 34, a security assessment component 36, a resource estimation component 38, a microservice releasing component 40, a management / UI component 42, and / or other components. Processor 20 may be configured to execute components 30, 32, 34, 36, 38, 40, and / or 42 by software, hardware, firmware, a combination of software and hardware and / or firmware, and / or other mechanisms for configuring processing performance on processor 20.

[0021] 1 illustrates components 30, 32, 34, 36, 38, 40, and / or 42 as coexisting within a single processing unit, it should be understood that in embodiments in which processor 20 includes multiple processing units, one or more of components 30, 32, 34, 36, 38, 40, and / or 42 may be located remotely from the other components. For example, in some embodiments, processor components 30, 32, 34, 36, 38, 40, and 42 may each include a separate and distinct set of processors. The description of the functionality provided by different components 30, 32, 34, 36, 38, 40, and / or 42 described below is for purposes of illustration and not limitation, as any of components 30, 32, 34, 36, 38, 40, and / or 42 may provide more or less functionality than described. For example, one or more of components 30, 32, 34, 36, 38, 40, and / or 42 may be eliminated, and some or all of its functionality may be provided by other components 30, 32, 34, 36, 38, 40, and / or 42. As another example, processor 20 may be configured to execute one or more additional components that may perform some or all of the functionality attributed to one or more of components 30, 32, 34, 36, 38, 40, and / or 42.

[0022] Every day, there are at least several vulnerabilities that affect a (e.g., cloud) platform, making the metric of zero vulnerabilities nearly impossible to achieve. For example, the time required to apply a patch is often longer than the time to discover a new vulnerability in the software or technology that forms the component itself. However, reducing vulnerabilities is not the same as reducing risk. For example, vulnerabilities found in third-party dependencies or in the source code dependencies of one or more microservices may each have a different severity level and impact on the component compared to, for example, a vulnerability discovered manually.

[0023] A manually found vulnerability may not be associated with a platform component but may instead be a guess as to the platform's legitimate functionality. Thus, in some embodiments, the need for automated scan reviews may be reduced or eliminated. Fixing 1,000 critical vulnerabilities associated with third-party source code (e.g., via a predetermined amount of resources and / or at a specific time) in response to reports from one or more scanners 50 may (e.g., automatically) adjust the risk level associated with fixing one manually found critical vulnerability. Each microservice or utility may have its own vulnerability profile and / or associated database, including, for example, a separate set of Type 1 (false positive) and Type 2 (false negative) errors. In some embodiments, the monitoring component 34 may monitor each profile and / or database individually, and the security assessment component 36 may generate unified metrics, for example, to provide an overview of the application's state without considering the source of the information. For example, only historical data and a snapshot of the current state may be required.

[0024] The approaches disclosed herein may reduce IT risk levels over time to acceptable levels, for example, by predicting when to reserve and when resource-based effort will be needed, and / or may highlight trends to a developer or auditor. For example, these options may comprise updating the core image, updating core image components, updating a third party, removing a third party, replacing a third party, disabling code endpoints, adding a new layer of protection to the endpoint (e.g., input data sanitizer), and / or another suitable option.

[0025] Microservices of different types may be integrated or form part of a stack (e.g., integrated via the same business objectives and / or set of rules). In some embodiments, the monitoring component 34 may analyze the code, base image, and environment of each microservice in the stack. For example, the monitoring component 34 may obtain and store historical data via multiple predefined tools, such as, but not limited to, Anchore® / Trivy® (e.g., for checking base image (BI) vulnerabilities), DTRACK (e.g., for checking environment vulnerabilities), Sonar® (e.g., for checking source code vulnerabilities), and / or other image, environment, and / or code scanners.

[0026] In some embodiments, the historical data may be displayed to a user of the system 10 (eg, via the UI device 18).

[0027] In this or another example, the outputs of these tools or instruments may be combined. Each tool included in predictive database 60 may be used as a data source by monitoring component 34 and may be required to provide at least one of a list of security vulnerabilities or a vulnerability score (or a string that can be converted into a score) for each vulnerability included in the list. Optionally, a vulnerability score converter (e.g., EPSS) may instead or additionally be required.

[0028] The assumed analysis of at least one sensor 50 (e.g., by which sensor its score is calculated) may involve a runtime environment and / or runtime system, the latter typically being, for example, a gateway through which a running program interacts with the runtime environment. The environment may include subsystems present on both the computer on which the program was created and the computer on which the program is intended to run or execute. A stack of microservices may be an exemplary environment. The runtime system or environment may include managed structures (e.g., application memory, operating system interfaces, etc.).

[0029] A runtime environment may comprise state values ​​and / or active entities with which a program may interact during execution. For example, environment variables, which are features of the OS, may be part of the runtime environment, and a running program may access them through a runtime system. An execution model may be at least partially implemented in a runtime system, which may reside within the program itself. A programming language includes a runtime system (e.g., including facilities to help support type checking, debugging, code generation, optimization, etc.).

[0030] In some embodiments, security assessment component 36 can predict short-term security assessments when the requirements for the next platform release are known, and the requirements may be different for the next release, and such a predictive model may not be needed, although such a predictive model may be implemented long-term if needed, for example, based on historical factors and current dynamics.

[0031] In some embodiments, the security assessment component 36 may predict or forecast the security condition or risk level of a microservice's stack on a continuous (e.g., indefinite) basis, frequently, holistically, and / or repeatedly. The frequency of the predictions may be adjusted to occur daily or at another periodic and / or configurable interval. For example, several coefficients may be recalculated every time (e.g., in the backend, for the current period or less than required for the security assessment) to allow for expression as a new state prediction for the current interval, timeframe, time lapse, or cycle. In a non-limiting example, stack releases may be at an adjustable frequency (e.g., daily, monthly, etc.) and / or when required to check the stack's security conditions.

[0032] In some embodiments, the user may be provided with an option to select the level of understanding of the algorithm itself (e.g., formula level or basic explanation). For example, access to the algorithm may not be provided, but the ability to modify the coefficients of the Holt-Winters model may be enabled.

[0033] In some embodiments, in response to the sensor scoring component 32 obtaining historical data, the monitoring component 34 may track changes in the project's state according to its release lifecycle. In these or other embodiments, each layer may individually and automatically apply additional checks to filter out, for example, Type 1 (false positive) errors, while Type 2 errors may be false negatives. For example, Exploit Prediction Scoring System (EPSS) scores may be used by the monitoring component 34 and / or the security assessment component 36. The scores may each indicate the probability that a software vulnerability will be exploited upon deployment and may be used in prioritizing vulnerability remediation efforts. In one example, the higher the score, the more likely the vulnerability will be exploited.

[0034] In some embodiments, results from the sensor's scoring component 32 may be incomplete or unreliable as they are. For example, the resulting score (or calculations therefor) may need to be weighted, and some of the detected vulnerabilities may be substantially minor and distracting. In this manner, the disclosed embodiments may reduce time spent on the scanner 50 and increase time spent on field work, for example, by a security team.

[0035] In some embodiments, the monitoring component 34 and / or the security assessment component 36 may retrieve from the database 60 a model for predicting a value (e.g., release point) per microservice over at least one full cycle. As described in more detail below, in a non-limiting example, the monitoring component 34 and / or the security assessment component 36 may retrieve from the database 60 a Holt-Winters model for predicting a value (e.g., release point) per microservice over at least one full cycle. For example, there may be a large increase in vulnerabilities over a cycle, but the predicted value may then drop sharply and then trend upward (e.g., this may indicate the start of a new cycle). In this or another example, the component may not be included (e.g., previously used, etc.), and the information is considered as calculated by default in the system 10.

[0036] In some embodiments, security assessment component 36 and / or resource estimation component 38 may operate without filtering out Type 1 errors (i.e., false positives). For example, enriching data and leveraging it for higher latency may eliminate the possibility of missing or skipping vulnerabilities. Rather than unnecessarily obtaining irrelevant information, the disclosed embodiments may obtain more information than would otherwise be needed, e.g., increasing the number of false positives and decreasing the number of false negatives.

[0037] In some embodiments, the monitoring component 34 and / or the security assessment component 36 may use the time series to detect the presence of an anomaly and then alert the developer.

[0038] In some embodiments, monitoring component 34 and / or security assessment component 36 may obtain information for each season, timestamp, or another period according to a release cycle for all cloud microservices on cloud computer 90. For example, monitoring component 34 and / or security assessment component 36 may synchronize or otherwise enrich information for each microservice based on already enriched information. In this or another example, components of processor 20 may use available information (e.g., in information component 30) to measure all microservices in the stack, including cases where suitable information is currently missing for one or more of the microservices.

[0039] In one example, a component may be currently or recently released, and for example, the security assessment component 36 may have identified vulnerabilities in that component. However, this identification may be distributed across all projects, for example, as a combined / individual value pair. If this number increases, for example, beyond a base level, the resource estimation component 38 or the microservice releasing component 40 may generate and / or send a report (which may, for example, signal the need for a status review). Then, the manual score may be reduced because the prediction may not be valid or for another suitable reason. In some embodiments, additional scans by the sensors 50 may be performed to further enrich the collected information and modify variables. In this way, resource estimates (e.g., man-hours) may be reduced by obtaining updated information that would not otherwise have been collected.

[0040] In some embodiments, the security assessment component 36 may determine a security assessment by summing security scores or values ​​for each project or thread (e.g., associated with the output of one or more sensors 50 for each microservice at a particular point in time).

[0041] In some embodiments, if the security score meets a criteria (e.g., is too high), the developer may be triggered to provide a new release. The resulting new security score may then differ (e.g., be lower) from the previous security score. Thus, a security patch may be recommended. In some embodiments, the sensor scoring component 32, monitoring component 34, and / or security assessment component 36 may measure potential security values, including by adhering to certain boundaries. For example, if a project's security score exceeds 50, the administration / UI component 42 may communicate with the developer to determine what action to take and how that action will resolve the issue.

[0042] In some embodiments, the score or representative value calculated by the security assessment component 36 may be intended to be reduced. For example, the resource estimation component 38 and / or the microservice releasing component 40 may (e.g., via a configured goal) reduce the amount of human labor required to correct one or more vulnerabilities in the microservice stack (e.g., implemented on the cloud computer 90). In this or another example, components of the processor 20 may be configured to adjust the time resources are required to make the corrections and / or address other security responsibilities associated with one or more microservices in the stack. Also, in any of these or another examples, the resource estimation component 38 and / or the microservice releasing component 40 may be involved in determining which tasks or projects should be given a higher priority to better address security goals. In making this determination, these components may further determine whether it is safe to delay the implementation of certain resources in favor of lower-priority security tasks, for example, without significantly increasing the risk of system crashes or fraud.

[0043] In some embodiments, the resource estimation component 38 and / or the microservice releasing component 40 may be configured to determine that certain resources (e.g., security experts and / or software tools) are needed at a particular time, enabling scheduling of the security team so that they are adequately staffed and / or otherwise prepared to resolve the issues predicted by the security assessment component 36.

[0044] In some embodiments, resource estimation component 38 may be more proactive by enabling it to estimate the amount of work that needs to be put into an application (e.g., to at least prevent a security rating from deteriorating and / or improve that rating).

[0045] In some embodiments, the resource estimation component 38 and / or the microservices releasing component 40 may obtain the security score (e.g., generated by the component 36 and / or the sensor scoring component 32), for example, when communicating with one or more developer teams. For example, a score, prediction, and / or an assessment exceeding a threshold may trigger a project measurement report.

[0046] In some embodiments, microservices releasing component 40 may be involved in multiple incremental releases, e.g., to improve security conditions in response to adjustments to one or more microservices. In these or other embodiments, the risk level associated with monitoring component 34 and / or security assessment component 36 may be configurable (e.g., by a user).

[0047] In some embodiments, the AppSec team and / or developers may determine the security level based on a set of documents (e.g., standards) that govern how they operate. For example, the more stringent the requirements of the set of documents, the lower the security score may be.

[0048] In some embodiments, resource estimation component 38 may predict a lower security rating determined by component 36. For example, an AppSec team may be triggered to respond based on a violation of a security level before a risk materializes, and / or a developer may be triggered to respond to one or more vulnerabilities based on a violation of another security level. In this or other examples, the AppSec team may be triggered to get involved earlier, resulting in a more secure outcome than receiving a score when it may be too late for the security team to provide a patch or other countermeasure.

[0049] In some embodiments, the management / UI component 42 or another component of the system 10 may be configured to provide a selectable set of components and / or microservices requested by a user (e.g., in a table via the UI device 18). Once one or more of these sets are selected, the monitoring component 34 may then be configured to begin evaluating one or more of them to determine an overall score for the next release of the stack of microservices 90.

[0050] In some embodiments, the monitoring component 34 may determine that not all of the microservices have been updated or changed, but may then need to recalculate the overall score (i.e., for all of the microservices involved and / or selected by the user). For example, components or analysis tools may not be updated for months, while other components or analysis tools may be updated on a weekly basis. Fixing only vulnerabilities in recently updated components may be insufficient, as not changing or updating components of the stack 90 that have not been recently updated may continue to increase the number of vulnerabilities.

[0051] Known security tools may create snapshots of the current state, but only at compile time or product preparation time (e.g., delivery time). Thus, in contrast to approaches where sensors are simply not triggered to gather information, the sensor scoring component 32 may communicate with sensors 50 associated with these tools to, for example, trigger the collection of data about relevant operations and then generate a report. The monitoring component 34 may then eliminate blind spots in the visibility of the component's surroundings. For example, the monitoring component 34 and / or the security assessment component 36 may identify one or more trends (e.g., the behavior of another component) associated with an increasing number of risk factors. An increase in vulnerabilities may provide adverse feedback to a feedback-driven link on the component's backend. In some embodiments, the security assessment component 36 may estimate a value or security score for the component that describes the situation (e.g., for the next day's release).

[0052] In some embodiments, the sensor or scanner 50 may include tools or applications that collect data and make reactive inferences. For example, the information component 32 and / or the sensor scoring component 32 may obtain network data from the security sensor 50 and generate vulnerability notifications regarding attacks (e.g., those that are measurable with a high degree of probability by the monitoring component 34).

[0053] In some embodiments, the management / UI component 42 can perform operations to deploy the platform via one or more configuration control files, including predicting the state of the microservice stack. For example, this component can make available all components that each provide collectable output data and synchronize them in a backend. As a result, the user experience is not impacted by eliminating security vulnerability contingencies because the security assessment calculated by component 36 is based on all relevant microservices. In this or another example, the resource estimation component 38 can determine the amount of technical effort, the type of resources, and / or the time required to perform the effort.

[0054] Each microservice release may be implemented according to a release quality checklist. For example, an AppSec team may check and determine the level or amount of security success, such as the absence of predicted vulnerabilities. This approach may eliminate manual testing. In this or another example, vulnerabilities may not have a degrading impact on a microservice with respect to layers such as the microservice source code, source code dependencies, and runtime environment.

[0055] FIG. 2 illustrates aspects of an evaluated (e.g., containerized) software release, according to one or more embodiments. As shown in the example of FIG. 2, each microservice tool (e.g., one that may operate using the sensor's scoring component 32) may focus on the security of one such layer 99 (e.g., code 99-1, environment 99-2, ..., and / or dependencies 99-n, where n is any natural number) and may provide at least the current application state for subsequent analysis. In some embodiments, another layer may be added to contribute to an automated Java bytecode security review upon developing an appropriate coding and configuration model (e.g., a fuzzer for the application). In some embodiments, the application may be based on the Spring Boot application framework.

[0056] In some embodiments, the tools implemented by sensors 50 may vary by use case due to the preferences and / or requirements of the associated AppSec team and due to continuous integration (CI) that may constitute part of a continuous development / delivery (CD) process. In this manner, components of processor 20 may be configured to interoperate with a set of security sensors 50 that output any amount of data (e.g., with any depth). Third-party functionality may also be encapsulated within each other, e.g., covering their respective functionality or source code. As a result, security assessments computed by components 36 and outputs from resource estimation component 38 may be more accurate and / or precise.

[0057] With the monitoring component 34 relying on the scores of three different sensors and the component 36 making proactive predictions therefrom, the resulting security assessment may be, for example, more accurate and / or precise. Thus, the techniques envisioned for system 10 may be improved not only by using the Exploit Prediction Scoring System (EPSS) and the Common Vulnerability Scoring System (CVSS), but also by the way the values ​​from sensors 50 are recalculated.

[0058] As mentioned above, fuzzing techniques can be used against APIs, for example, to measure security levels. Fuzzing results can be treated as data that can be mapped to (e.g., predetermined) requirements. Because fuzzing results can be used to build upon, they may be used as an additional layer. That is, the tool may not be intended as an implementation for checking base image, environment, or source code vulnerabilities, but rather as an additional aspect or layer.

[0059] 3 illustrates an example of data available by a base image scanning tool. In one example, SysDig may be used as the BI review tool. In another example, Anchore may be used as the BI review tool, which may provide all of the data needed as shown in FIG. 3.

[0060] Figure 4 illustrates vulnerability mapping from quantitative scores to qualitative ratings. An example of a sensor-based vulnerability reporting tool is Anchore. For example, let P be an Anchore project with m vulnerabilities. Anchore may not be able to provide the number of vulnerabilities. As shown in Figure 4, for each vulnerability D, the CVSS D The total score of an Anchore project can be mapped using the metrics: It can be characterized as TIFF2025541982000002.tif30159.

[0061] FIG. 5 illustrates an example of data available for use by an environmental scanning tool. DTrack, for example, can be an example of an environmental review tool for providing all the required data, as shown in FIG. 5. DTrack can also provide a vulnerability number converter to EPSS scores. As shown in the example of FIG. 6, the number of EPSS scores available for vulnerability checks may not match the number of vulnerabilities. FIG. 6 illustrates the discrepancy between vulnerability scores and the number of vulnerabilities.

[0062] In some embodiments, the sensor scoring component 32 may implement a converter, for example, to convert the sensor scores to an EPSS or similar value. For example, a deeply nested vulnerability may actually be determined (e.g., via DTrack) to have a lower level of risk than initially or previously estimated. This may then be targeted across releases. DTrack or another tool may not display two or more nested vulnerabilities, but may detect them. For example, a critical vulnerability (e.g., with an increased chance of being hit with a fatal blow) may be detected. This may be yet another layer of dependency.

[0063] The approaches disclosed herein may resolve typos, for example, by providing additional nesting information and / or by providing an EPSS value if the Common Vulnerabilities and Exposures (CVE) does not have one.

[0064] In some embodiments, a component or microservice may be configured to read the JSON file. However, in some cases, converting JSON to HTML may not be implemented, allowing for the use of specific dependencies added to the source code by a third party. This third party may, for example, convert JSON to an HTML file as needed. One or more dependencies inherent in each microservice may contribute to security risks and / or other vulnerabilities. Components of a microservice may be considered third parties.

[0065] In one example, let P be a DTrack project with n dependencies D. The DTrack EPSS dependency score ES D is the dependency score multiplied by the EPSS vulnerability score, e.g. TIFF2025541982000003.tif20156. The dependency is related to the EPSS D If you do not have CVSS, as shown in Figure 4 D A metric may be used (which may be mapped, for example, as follows, or may be mapped to other values ​​depending on experience):

[0066] EPSS D For dependencies that do not have a value, DTrack uses CVSS D For each range, a worst-case scenario may be estimated. For example, there may be no actionable work done on the project in that scenario. And in another example or scenario, a moderate vulnerability may be evaluated based on experience with CVSS. D =0.69 or other values.

[0067] In one example, EPSS D Let P be k vulnerabilities with a CVSS score, and let l vulnerabilities be P. D Suppose you have a score. DTrack EPSS Project Score ES P is the sum of all dependency scores multiplied by the EPSS dependency score, i.e. It could be TIFF2025541982000004.tif15158.

[0068] In one example, P may be given the vulnerabilities found in components nested in m layers of dependencies. The nested dependency score DS Dm is the CVSS dependency score and Multiplication with the depth value of TIFF2025541982000005.tif3017, i.e. TIFF2025541982000006.tif30121. And nested dependency project score DS P is the sum of all nested dependency scores, i.e. It could be TIFF2025541982000007.tif30142.

[0069] Total DTrack Project Score TS p The total score is the sum of the nested dependency score and the DTrack EPSS project score, i.e. It could be TIFF2025541982000008.tif30170.

[0070] In one example, ShiftLeft may be used for vulnerability checking of source code. In another example, Sonar may be used as a static code review tool to provide all the required data, as shown, for example, in Figure 7-8, which illustrates an example of data available by a source code scanning tool.

[0071] In one example, a sonar dashboard may include a list of vulnerabilities, including, for example, the severity value for each. The names of the severities may differ from the names in CVSS, but these values ​​may be the same on the backend. In this or another example, for example, Blocker may relate to Critical, which may relate to High. P may be given a Sonar project with m vulnerabilities. Sonar may not provide the number of vulnerabilities. Thus, for each vulnerability D, the CVSS D We can use metrics, which can be mapped as in the example in Figure 4. Then, the total sonar project score is TIFF2025541982000009.tif30157. Total Project Security Score (TPSS) P is the sum of all independent tool scores for each of the layers, i.e. It could be TIFF2025541982000010.tif20144.

[0072] Holt-Winters is a model of time series behavior, for example, a way to model three aspects of a time series. The first can be a typical value (representative), the second can be the slope over time (trend), and the third can be a cyclical repeating pattern (seasonality). In one example, a release lifecycle is cyclical, and seasonality requirements can be considered by default. In this or another example, an assumption can be made that the slope is at least the same as before. Also, an average can be calculated as a representative value from past project data history.

[0073] With a time-point model, the security value may be assumed as the sum of a base (raw) value, a slope value, and a seasonal value, where, for example, the seasonal value is associated with the slope. The seasonal component in the model may describe periodic changes around the slope, which may be characterized, for example, by the length of the season.

[0074] The security assessment component 36 may implement predictive methods because historical data for all layers may be defined and obtained by the information component 30. The collected data may contain additional extractable information because it may be associated with a fixed time, as opposed to random data.

[0075] In some embodiments, the models in predictive database 60 may be based on a Holt-Winters implementation, which may involve, for example, estimating a slope and determining a representative or average value. For example, a release cycle for the Holt-Winters model may comprise a point in time when a product, component, or microservice (e.g., which may be fully functional) is ready for release. In this or another example, the slope may be sufficient to facilitate one or more peer requests from customers and corresponding modifications (e.g., with associated dates).

[0076] In some embodiments, each season may include timing information, e.g., from the beginning to the moment when components are periodically released. In each exemplary cycle, the number of vulnerabilities may increase relatively over the period but decrease absolutely over several cycles. Because a release may be the end of a cycle, the release date may be relevant to the project at its best. The worst security score among all releases may be the threshold beyond which the project is marked as "no go" for the release. That is, even though the security score for each cycle may continually increase, this does not mean that the threshold will be reached in one, two, or N cycles. For example, a score of 50 may be obtained at the end of a cycle, but a score of 2 may be achieved at the beginning of a new cycle. During a cycle, the score may increase by up to 15. That is, the relative score may be +13, but the absolute score may be -35.

[0077] Starting from the simple idea that tomorrow will be the same as yesterday, a reasonable assumption can be that the future depends on the median of n past values. This is called a moving average, and can be calculated as follows: TIFF2025541982000011.tif30139. A weighted average, a simple modification of the moving average, allows for more precise predictions through the addition of a weight parameter (the sum of the weights is 1). The value can be calculated as follows: TIFF2025541982000012.tif30165.

[0078] The idea behind Brown's model is to weight all available historical data, with the weights decreasing exponentially: TIFF2025541982000013.tif20142. The model value can be a weighted average between the current and past history values. The weight α is a smoothing factor, defining, for example, how quickly the last available history value is forgotten. For example, decreasing α can increase the influence of historical data on the predicted result. And adding α values ​​can create only one predicted value. For example, multiplying it by the value of y from t can directly affect the value.

[0079] The Holt et al. model can be modified to allow for splitting the series into two parts: level (l) and trend / slope (b). For example, the forecast can be found as follows: x =α*y x +(1-α)*(l x-1 +b x-1 );b x =β*(l x -l x-1 )+(1-β)*b x-1 ; and TIFF2025541982000014.tif3041=l x +b x

[0080] The first function (l x) may define levels depending on the current value, for example. However, the values ​​may be divided based on past historical data values ​​and trends. x ) may define a trend depending on, for example, the level change of the current value and the past trend value. β may be a new weight value for the weight function.

[0081] The model in database 60 can then be modified again to implement the Holt-Winters model, for example, by adding a new (e.g., seasonal) component. In some implementations, the seasons can be software release cycles. The seasonal component can account for periods around trends and levels, for example. Thus, values ​​can be predicted as follows: x =α*(y x -s x-L )+(1-α)*(l x-1 +b x-1 );b x =β*(l x -l x-1 )+(1-β)*b x-1 ;s x =γ(y x -l x )+(1-γ)s x-L ; and TIFF2025541982000015.tif3072=l x +mb x +s x-L+1+(m-1)modL

[0082] The coefficients α, β, and γ may be calculated using time-series cross-validation. Historical data may have a time-based basis, and this dependency may be preserved. Therefore, some implementations may involve stepwise cross-validation. In one example according to the present model, at any point in time, the security value may be assumed to be the sum of a base (raw) value, a slope value, and a seasonal value. The seasonal component in the model may describe cyclical changes around the slope and may be characterized by the length of the season.

[0083] In some embodiments, an algorithmic Holt-Winters model may be implemented for short-term (i.e., for the next release) predictions to, for example, identify security values ​​likely achievable by an application or microservice. For example, a new database of software releases may describe multiple nested vulnerabilities in a third-party component. FIG. 9 shows an exemplary chart of weighted predictions for the same, and FIG. 10 shows information about score-reducing patches (e.g., that may be applied in response to an increase in detected vulnerabilities). FIG. 10 illustrates an example in which it may be determined that no further steps are necessary to secure the project because the current project score may be 2.3 and the predicted value may be 7.52. Because the project average may be 3.0, the component may be acceptable and releasable because it is at least currently worse than what may have already been released. In other embodiments, the monitoring component 34 and / or security assessment component 36 may adjust the model (e.g., retrieved from the prediction database 60) for one or more long-term predictions. The time period criteria met during monitoring to make a short-term prediction may be longer than the length of each iteration.

[0084] In some embodiments, stepwise time-series cross-validation may be used to determine the set of coefficients. For example, the above cross-validation may involve assuming a security value at each time point as the sum of a base (raw) value, a slope value, and a seasonal value according to the model. The seasonal value may be associated with the slope value. The seasonal component in the model may describe periodic changes around the slope and may be characterized by the length of the season.

[0085] Also, the project average value is taken into account since application degradation may appear as a trend, so the method will take this as a feature and not issue an alert.

[0086] 1 comprises an electronic storage medium that electronically stores information. The electronic storage medium of electronic storage 22 may comprise system storage that is provided integrally with system 10 (i.e., substantially non-removably) and / or removable storage that is removably connectable to system 10 via, for example, a port (e.g., a USB port, a FireWire port, etc.) or a drive (e.g., a disk drive, etc.). Electronic storage 22 may be a separate component (in whole or in part) within system 10, or electronic storage 22 may be provided integrally (in whole or in part) with one or more other components of system 10 (e.g., user interface (UI) device 18, processor 20, etc.). In some embodiments, electronic storage 22 may be located in a server with processor 20, in a server that is part of external resources 24, in UI device 18, and / or elsewhere. Electronic storage 22 may comprise a memory controller and one or more of an optically readable storage medium (e.g., optical disk, etc.), a magnetically readable storage medium (e.g., magnetic tape, magnetic hard drive, etc.), a charge-based storage medium (e.g., EPROM, RAM, etc.), a solid-state storage medium (e.g., flash drive, etc.), and / or other electronically readable storage medium. Electronic storage 22 may store software algorithms, information obtained and / or determined by processor 20, information received via UI device 18 and / or other external computing systems, information received from external resources 24, and / or other information that enables system 10 to function as described herein.

[0087] External resources 24 may include information sources (e.g., databases, websites, etc.), external entities participating in system 10, one or more servers external to system 10, networks, electronic storage, equipment associated with Wi-Fi technology, equipment associated with Bluetooth technology, data entry devices, power sources (e.g., battery-powered or directly connected to 110 volts AC or indirectly connected to line power via AC / DC conversion), transmit and receive elements (e.g., antennas configured to transmit and / or receive wireless signals), network interface controllers (NICs), display controllers, graphics processing units (GPUs), and / or other resources. In some embodiments, some or all of the functionality attributed herein to external resources 24 may be provided by other components or resources included in system 10. The processor 20, external resources 24, UI device 18, electronic storage 22, network, and / or other components of system 10 may be configured to communicate with each other via wired and / or wireless connections, such as a network (e.g., a local area network (LAN), the Internet, a wide area network (WAN), a radio access network (RAN), a public switched telephone network (PSTN), etc.), cellular technology (e.g., GSM, UMTS, LTE, 5G, etc.), Wi-Fi technology, another wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.), base station, and / or other resources.

[0088] UI device 18 of system 10 may be configured to provide an interface between one or more users and system 10. In some embodiments, UI device 18 can be configured to provide information to and / or receive information from one or more users. UI device 18 includes a UI and / or other components. The UI may be and / or include a graphical UI configured to present views and / or fields configured to receive inputs and / or selections and / or provide and / or receive other information related to particular functionality of system 10. In some embodiments, the UI of UI device 18 may include multiple separate interfaces associated with processor 20 and / or other components of system 10. Examples of interface devices suitable for inclusion in UI device 18 include a touchscreen, keypad, touch-sensitive and / or physical buttons, switches, keyboard, knobs, levers, display, speaker, microphone, indicator light, audible alarm, printer, and / or other interface devices. The present disclosure also contemplates that UI device 18 may include a removable storage interface. In this example, information may be loaded onto UI device 18 from removable storage (eg, smart card, flash drive, removable disk) that allows a user to customize the implementation of UI device 18.

[0089] In some embodiments, UI device 18 can be configured to provide a UI, processing capabilities, a database, and / or electronic storage for system 10. As such, UI device 18 can include processor 20, electronic storage 22, external resources 24, and / or other components of system 10. In some embodiments, UI device 18 can be connected to a network (e.g., the Internet). In some embodiments, UI device 18 does not include processor 20, electronic storage 22, external resources 24, and / or other components of system 10, but instead communicates with these components via dedicated lines, buses, switches, networks, or other communication means. Communication may be wireless or wired. In some embodiments, UI device 18 can be a laptop, desktop computer, smartphone, tablet computer, and / or other UI device.

[0090] Data and content may be exchanged between the various components of system 10 through communication interfaces and paths using any one of a number of communication protocols. In one example, data may be exchanged employing protocols used to communicate data across packet-switched internetworks, e.g., using the Internet Protocol suite, also known as TCP / IP. Data and content may be delivered from a sending host to a destination host using datagrams (or packets) based solely on their addresses. To this end, the Internet Protocol (IP) defines an addressing method and structure for encapsulating datagrams. Of course, other protocols may also be used. Examples of Internet protocols include Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6).

[0091] In some embodiments, processor 20 may form part of (e.g., in the same or a separate housing) a user device, consumer electronic device, mobile phone, smartphone, personal digital assistant, digital tablet / pad computer, wearable device (e.g., wristwatch), augmented reality (AR) goggles, virtual reality (VR) goggles, reflective display, personal computer, laptop computer, notebook computer, workstation, server, high-performance computer (HPC), vehicle (e.g., a computer embedded in the dashboard of an automobile or airplane, in front of a seated passenger, etc.), gaming or entertainment system, set-top box, monitor, television (TV), panel, spacecraft, or other device. In some embodiments, processor 20 is configured to provide information processing capabilities in system 10. Processor 20 may comprise one or more of a digital processor, an analog processor, a digital circuit designed for information processing, an analog circuit designed for information processing, a state machine, and / or other mechanism for electronically processing information. Although processor 20 is shown in FIG. 1 as a single entity, this is for illustrative purposes only. In some embodiments, processor 20 may comprise multiple processing units. These processing units may be physically located within the same device (e.g., a server), or processor 20 may represent the processing functionality of multiple devices working together (e.g., one or more servers, UI device 18, devices that are part of external resources 24, electronic storage 22, and / or other devices).

[0092] FIG. 11 illustrates a method 100 for obtaining information for adjusting platform security conditions, according to one or more embodiments. Method 100 may be performed by a computer system including one or more computer processors and / or other components. The processor may be configured with machine-readable instructions for executing computer program components. The operations of method 100 presented below are intended to be exemplary. In some embodiments, method 100 may be achieved by one or more additional operations not described and / or without one or more of the operations described. Additionally, the order of operations of method 100 illustrated in FIG. 11 and described below is not intended to be limiting. In some embodiments, method 100 may be implemented in one or more processing devices (e.g., digital processors, analog processors, digital circuits designed for information processing, analog circuits designed for information processing, state machines, and / or other mechanisms for electronically processing information). A processing device may include one or more devices that perform some or all of the operations of method 100 in response to instructions stored electronically on an electronic storage medium. The processing device may include one or more devices configured through hardware, firmware, and / or software specially designed to perform one or more of the operations of method 100.

[0093] In operation 102 of method 100, (i) source code, (ii) base image (BI), and (iii) runtime environment of each of a plurality of microservices in the stack may be obtained and monitored, e.g., via first, second, and third sets of security tools configured to generate first, second, and third vulnerability scores, respectively. In some embodiments, operation 102 is performed by processor components the same as or similar to information component 30, sensor scoring component 32, and monitoring component 34 (shown in FIG. 1 and described herein).

[0094] At operation 104 of method 100, a security assessment of the stack of microservices may be iteratively predicted, e.g., via a model based on the first, second, and third scores. In some embodiments, operation 104 is performed by a processor component the same as or similar to security assessment component 36 (shown in FIG. 1 and described herein). Security assessment component 36 may not detect intrusions or react therefrom in real time. As such, in some embodiments, this component may instead track potential vulnerabilities. In some embodiments, possible fixes for the situation may be generated. For example, the operations contemplated herein may be rule-based and / or behavior-based (e.g., on a backend).

[0095] At operation 106 of method 100, an amount of resources required for the security team may be determined based on the predicted rating, for example, to increase the security rating through the implementation of resources. In some embodiments, operation 106 is performed by a processor component that is the same as or similar to resource estimation component 38 (shown in FIG. 1 and described herein).

[0096] Operation 108 of method 100 may determine a time to reserve an amount of resources. In some embodiments, operation 108 is performed by a processor component that is the same as or similar to resource estimation component 38 (shown in FIG. 1 and described herein).

[0097] Operation 110 of method 100 may determine the security state of the next release of a stack of microservices. In some embodiments, operation 110 is performed by a processor component that is the same as or similar to microservice releasing component 40 (shown in FIG. 1 and described herein).

[0098] At operation 112 of method 100, a UI configured to obtain a selection of an information technology f3) risk level over a configurable time period may be provided. In some embodiments, operation 112 is performed by a processor component that is the same as or similar to management / UI component 42 (shown in FIG. 1 and described herein).

[0099] Operation 114 of method 100 may aggregate or sum the average values ​​with the estimated slope value and with the seasonality value associated with the slope value. In some embodiments, operation 114 is performed by the same or similar processor component as monitoring component 34 and / or security assessment component 36.

[0100] Operation 116 of method 100 may track project state changes from each layer separately according to the release lifecycle and automatically apply additional checks to, for example, filter out false positives in one or more security tool reports. In some embodiments, operation 116 is performed by a processor component that is the same as or similar to monitoring component 34.

[0101] In operation 118 of method 100, the model may be adjusted so that long-term predictions are made, for example, in subsequent iterations. In some embodiments, operation 118 is performed by a processor component that is the same as or similar to management / UI component 42.

[0102] In operation 120 of method 100, the periodicity of the recurrence may be adjusted via the UI. In some embodiments, operation 120 is performed by a processor component that is the same as or similar to management / UI component 42.

[0103] The techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or combinations thereof. The techniques may be implemented as a computer program product, i.e., as a computer program tangibly embodied in an information carrier, e.g., a machine-readable storage device, machine-readable storage medium, computer-readable storage device, or computer-readable storage medium, for execution by or control the operation of a data processing apparatus, e.g., a programmable processor, computer, or multiple computers. The computer program may be written in any type of programming language, including compiled or interpreted languages, and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. The computer program may be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communications network.

[0104] The method steps of the present technique may be performed by one or more programmable processors executing a computer program to perform the functions of the present technique by operating on input data and generating output. Method steps may also be performed by, and apparatus of the present technique may be implemented as, special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0105] Processors suitable for executing a computer program include, by way of example, both general-purpose and special-purpose microprocessors, and one or more processors of any kind of digital computer. Typically, a processor receives instructions and data from a read-only memory or a random-access memory, or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include, or be operatively coupled to receive and / or transfer data from, one or more mass storage devices, such as magnetic, magneto-optical, or optical disks, for storing data. Information carriers suitable for incorporating computer program instructions and data include all forms of non-volatile memory, including, by way of example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices, magnetic disks such as internal or removable hard disks, magneto-optical disks, and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, special-purpose logic circuitry.

[0106] Several embodiments of the present disclosure have been specifically illustrated and / or described herein. Modifications and variations are contemplated and are within the scope of the appended claims.

Claims

1. 1. A computer-implemented method comprising: providing first, second, and third sets of security tools configured to generate first, second, and third vulnerability scores, respectively; monitoring (i) source code, (ii) base image (BI), and (iii) runtime environment of each of a plurality of microservices in the stack via the first, second, and third sets of security tools, each of the security tools being selectable and comprising at least one scanner or sensor configured to output historical data, and wherein the microservices operate with respect to the same set of operational parameters; iteratively predicting, via a model, a security assessment of the stack of microservices based on two or more of the first, second, and third scores; and determining, based on the predicted assessment, an amount of resources required to enable a security team to enhance security through implementation of the resources.

2. The method of claim 1 , further comprising determining a time to implement the reservation of the amount of resources, the reservation including allocation or scheduling of resources for the security team.

3. The method of claim 1 , further comprising determining a security posture for a next release of the stack of microservices.

4. The method of claim 1 , wherein the microservices comprise a set of one or more cloud services.

5. The method of claim 1 , further comprising providing a user interface (UI) configured to capture a selection of an information technology (IT) risk level over a configurable time period.

6. The method of claim 1 , wherein each of the scores is a representative value.

7. The method of claim 6 , further comprising aggregating or summing the representative values ​​by estimated slope values ​​and by seasonality values ​​associated with the slope values.

8. The method of claim 1 , wherein each of the repeated predictions occurs within a first period, the first period being longer than the length of time of each of the repeated predictions, and the repeated predictions are periodic.

9. The method of claim 8 , wherein each of the first and second time periods is configurable via the UI.

10. transmitting a notification based on the determination, the amount of the resource being determined based on the security assessment meeting a first criterion; 2. The method of claim 1, wherein the notification enables activating a team of developers if, in a subsequent iteration, the security assessment is predicted to meet a second criterion having a higher risk level than the first criterion.

11. 2. The method of claim 1, wherein each of the predictions is made to enable a first amount of false positives to be increased and a second amount of false negatives to be decreased.

12. 10. The method of claim 1, further comprising tracking project state changes from each layer separately according to a release lifecycle and automatically applying additional checks to filter out false positives in one or more security tool reports.

13. 9. The method of claim 8, further comprising adjusting the model so that long-term predictions are made in subsequent iterations, wherein the model is a Holt-Winters model.

14. The method of claim 1 , further comprising adjusting the periodicity of the repetitions via a UI.

15. a memory having computer readable instructions stored thereon; and a processor, providing first, second, and third sets of security tools configured to generate first, second, and third vulnerability scores, respectively; monitoring (i) source code, (ii) base image (BI), and (iii) runtime environment of each of a plurality of microservices in the stack via the first, second, and third sets of security tools, each of the security tools being selectable and comprising at least one scanner or sensor configured to output historical data, and wherein the microservices operate with respect to the same set of operational parameters; iteratively predicting, via a model, a security assessment of the stack of microservices based on two or more of the first, second, and third scores; and determining, based on the predicted assessment, an amount of resources required to enable a security team to enhance security through implementation of the resources.

16. the processor:

16. The system of claim 15, further configured to determine a time to implement the reservation of the amount of resources, the reservation including allocation or scheduling of resources for the security team.

17. the processor:

16. The system of claim 15, further configured to determine a security posture for a next release of the stack of microservices.

18. 16. The system of claim 15, wherein the microservices comprise a set of one or more cloud services.

19. the processor:

16. The system of claim 15, further configured to provide a user interface (UI) configured to capture selection of information technology (IT) risk levels over a configurable period of time.

20. the processor: further configured to aggregate or sum the representative values ​​by an estimated slope value and by a seasonality value, the seasonality value being associated with the slope value; The system of claim 15 , wherein each of the scores is one of the representative values.

Images