US-12619737-B2 - Method and system for security risk identification and controlling release management of software application with vulnerable codes

US12619737B2US 12619737 B2US12619737 B2US 12619737B2US-12619737-B2

Abstract

The embodiments herein provide a method and a system for security risk identification and controlling release management of software application. The method provides security risk identification in a software application as well as integrated tools to direct the efforts of developers to build and maintain secure software. The method provides a unique approach of defining a plurality of Service Level Agreement (SLA) to control a release build for a software application by checking vulnerabilities. Furthermore, the method is flexible enough to adapt in most complicated enterprises and different Software Development Life Cycle (SDLC) processes.

Inventors

ANANT MISRA
Nikhil Gupta
MARK LLOYD LAMBERT

Assignees

ArmorCode Inc.

Dates

Publication Date: 20260505
Application Date: 20230606

Claims (14)

1 . A method for identifying security risks and controlling a release of at least one software applications containing vulnerable codes, the method comprising the steps of: a. defining a plurality of service level agreements (SLAs) for the release of the software application, wherein the release includes a global release of the software application and a specific release of the software application, and wherein defining the plurality of SLAs for the global release further includes applying the plurality of SLAs to products, subproducts, and microservices, and wherein defining the plurality of SLAs for the specific release further includes applying the plurality of SLAs to at least one of a specific product, a specific subproduct, and a specific environment, at at least one of an application level, a microservice level, and an environment level; b. prioritizing the plurality of service level agreements (SLAs) into Level 1 SLAs, Level 2 SLAs, and Level 3 SLAs, and wherein the Level 1 SLAs comprise a predetermined number of critical, high, medium, and low vulnerabilities allowed to pass through the release, and wherein any number of the critical, high, medium, and low vulnerabilities exceeding the predetermined number of critical, high, medium, and low vulnerabilities are blocked from the release, and wherein the Level 2 SLAs define a list of critical tools, that when not executed, cause the release of the software application to be blocked, and wherein the Level 3 SLAs define flexible risk parameters, including a threat intelligence score and compliance deviance to be implemented during the release of the software application; c. downloading a script from a vulnerability management platform, wherein the script contains a vulnerability management platform API, and inserting downloaded script into a release build pipeline created by a build and continuous integration (CI) tools, and wherein the vulnerability management platform ingests vulnerabilities from a plurality of vulnerability detection tools, penetration testing results, manual security research results, and secure code review results; d. triggering the release build pipeline and the downloaded script embedding the vulnerability management platform API; e. checking a vulnerability state for a specific release build of the software application by the vulnerability management platform API, by using at least one scanning tools, and wherein the vulnerability management platform records the release of the software application and a status of the vulnerability state at a time of the release of the software application, and wherein in an event the vulnerability state of the release exceeds a predetermined threshold, the vulnerability management platform API returns a FAIL code and blocks the release build pipeline of the software application; f. allowing the release of the software application if the vulnerability state is determined to be below the predetermined threshold and blocking the release of the software application if the vulnerability state is determined to be above the predetermined threshold, and wherein the vulnerability state is determined based on the Level 1 SLAs, the Level 2 SLAs, and the Level 3 SLAs; g. recording each failed release attempt of the software application in the vulnerability management platform, along with issues present at a time of the failed release attempt; and h. implementing an exception release approval procedure by setting a baseline, the baseline defining a predetermined set of vulnerabilities, and wherein the exception release approval procedure includes approving exceptions in the software application and allowing the release of the software application in a subsequent release attempt performed on the release build pipeline, and wherein the step of implementing the exception release approval by setting the baseline further includes: ignoring specific vulnerabilities in the baseline during the subsequent release attempt and applying the baseline to incremental vulnerabilities; allowing a current set of vulnerabilities to pass through, even when the exceptions corresponding to the current set of vulnerabilities violate at least one of the plurality of SLAs; and wherein the release of the software application is allowed over the baseline, in an event the software application contains vulnerabilities that are a subset of the predetermined set of vulnerabilities defining the baseline, and wherein new vulnerabilities that do not belong to the predetermined set of vulnerabilities are tested against a predefined release gate criteria.
2 . The method according to claim 1 , wherein the products to which the plurality of SLAs are applied for the global release are abstract entities composed of a plurality of smaller software products, and wherein the products and the sub-products define a hierarchy of related software applications.
3 . The method according to claim 1 , wherein the method ( 100 ) further includes supporting different environments within the products, and the subproducts to reflect a software development process at an organization, and wherein the different environments comprise code branch and deployment environment.
4 . The method according to claim 1 , wherein the threat intelligence score is used to selectively allow and disallow the release of the software application, and wherein implementation of the compliance deviance includes halting the release in an event the release is deviating from a specific compliance, and wherein the compliance deviance is implemented based on security rules selected from a group consisting of Application Security Verification Standard (ASVS) 4.0.2, Open Web Application Security Project (OWASP) Top 10-2021, Common Weakness Enumeration (CWE) Top-25, Payment Card Industry data Security Standard (PCI DSS) 3.2, and Health Insurance Portability and Accountability Act (HIPAA) security standards.
5 . The method according to claim 1 , wherein the step of downloading the script from the vulnerability management platform further includes the following steps: a. ingesting the vulnerabilities, by the vulnerability management platform, from the plurality of vulnerability detection tools, the penetration testing results, the manual security research results, and the secure code review results; b. normalizing the vulnerabilities to a common framework, and deduplicating the vulnerabilities, in an event substantially similar vulnerabilities are identified; c. triaging the vulnerabilities; d. creating reports on vulnerability data using application security posture management (ASPM) tools; and e. creating remediation workflows for identified and prioritized vulnerabilities.
6 . The method according to claim 1 , wherein the at least one scanning tool includes an infrastructure security scan tool, a Static Application Security Testing (SAST) tool, a Software Composition Analysis (SCA) tool, a secret scanning tool, Interactive Application Security Testing (IAST) tool, Dynamic Application Security Testing (DAST) tool, bug bounty platforms, Runtime Application Self Protection (RASP) tool, and a manual pen testing tool.
7 . The method according to claim 1 , wherein the method further includes the steps of: a. triggering, by a build automation platform, a vulnerability management platform release gate API; b. informing the vulnerability management platform about creation of the specific release build of the software application; c. triggering the vulnerability management platform to provide the status of the vulnerability state, and to determine whether the release can be deployed; d. selectively deploying the specific release build of the software application, by the build automation platform; and e. generating the script, by the vulnerability management platform.
8 . A computer-implemented system for identifying security risks and controlling a release of at least one software application containing vulnerable codes, said system comprising: a processor; and a memory storing computer-executable instructions, which when executed by the processor cause the processor to: generate a specific release build of the software application, and check for a vulnerability state of the specific release build check for vulnerabilities and the security risks in the software application; define a plurality of service level agreements for a release of the software application, and wherein the release includes a global release of the software application and a specific release of the software application, and wherein defining the plurality of SLAs for the global release further includes applying the plurality of SLAs to all products, subproducts, and microservices, and wherein defining the plurality of SLAs for the specific release further includes applying the plurality of SLAs to at least one of a specific product, a specific subproduct, and a specific environment, at at least one of an application level, a microservice level, and an environment level; prioritize the plurality of service level agreements (SLAs) into Level 1 SLAs, Level 2 SLAs, and Level 3 SLAs, and wherein the Level 1 SLAs comprise a predetermined number of critical, high, medium, and low vulnerabilities allowed to pass through the release, and wherein any number of the critical, high, medium, and low vulnerabilities exceeding the predetermined number of critical, high, medium, and low vulnerabilities are blocked from the release, and wherein the Level 2 SLAs define a list of critical tools, that when not executed, cause the release of the software application to be blocked, and wherein the Level 3 SLAs define flexible risk parameters, including a threat intelligence score and compliance deviance to be implemented during the release of the software application; download a script from a vulnerability management platform, wherein the script contains a vulnerability management platform API, and insert downloaded script into a release build pipeline created by a build and continuous integration (CI) tool, and trigger the vulnerability management platform to ingest vulnerabilities from a plurality of vulnerability detection tools, penetration testing results, manual security research results, and secure code review results; trigger the release build pipeline and the downloaded script embedding the vulnerability management platform API; check the vulnerability state for the specific release build by using at least one scanning tool, and trigger the vulnerability management platform to record the release of the software application and a status of the vulnerability state at a time of the release of the software application; trigger the vulnerability management platform API to return a FAIL code and block the release build pipeline of the software application in an event the vulnerability state of the release exceeds a predetermined threshold; trigger the vulnerability management platform API to allow the release of the software application in an event the vulnerability state is determined to be below the predetermined threshold and further trigger the vulnerability management platform API to blocking the release of the software application if the vulnerability state is determined to be above the predetermined threshold, and further trigger the vulnerability management platform API to determine the vulnerability state based on the Level 1 SLAs, the Level 2 SLAs, and the Level 3 SLAs; trigger the vulnerability management platform to record each failed release attempt of the software application, along with issues present at a time of the failed release attempt; and implement an exception release approval procedure by setting a baseline, the baseline defining a predetermined set of vulnerabilities, and wherein the exception release approval procedure includes approving exceptions in the software application and allowing the release of the software application in a subsequent release attempt performed on the release build pipeline, and wherein an implementation of the exception release approval procedure by setting the baseline further includes: ignoring specific vulnerabilities in the baseline during the subsequent release attempt and applying the baseline to incremental vulnerabilities; allowing a current set of vulnerabilities to pass through, even when the exceptions corresponding to the current set of vulnerabilities violate at least one of the plurality of SLAs; and wherein the release of the software application is allowed over the baseline, in an event the software application contains vulnerabilities that are a subset of the predetermined set of vulnerabilities defining the baseline, and wherein new vulnerabilities that do not belong to the predetermined set of vulnerabilities are tested against a predefined release gate criteria.
9 . The system according to claim 8 , wherein the products to which the plurality of SLAs are applied for the global release are abstract entities composed of a plurality of smaller software products, and wherein the products and the subproducts define a hierarchy of related software applications.
10 . The system according to claim 8 , wherein the system supports for different environments within the products and the subproducts to reflect a software development process, and wherein the different environments comprise code branch and deployment environment.
11 . The system according to claim 8 , wherein the threat intelligence score is used to selectively allow and disallow the release of the software application, and wherein implementation of the compliance deviance includes halting the release in an event the release is deviating from a specific compliance, and wherein the compliance deviance is implemented based on security rules selected from a group consisting of Application Security Verification Standard (ASVS) 4.0.2, Open Web Application Security Project (OWASP) Top 10-2021, Common Weakness Enumeration (CWE) Top-25, Payment Card Industry data Security Standard (PCI DSS) 3.2, and Health Insurance Portability and Accountability Act (HIPAA) security standards.
12 . The system according to claim 8 , wherein the processor is further configured to: a. trigger the vulnerability management platform to ingest the vulnerabilities from the plurality of vulnerability detection tools, the penetration testing results, the manual security research results, and the secure code review results; b. normalize the vulnerabilities to a common framework, and deduplicate the vulnerabilities, in an event substantially similar vulnerabilities are identified; c. triaging the vulnerabilities; d. creating reports on vulnerability data using application security posture management (ASPM) tools; and e. creating remediation workflows for identified and prioritized vulnerabilities.
13 . The system according to claim 8 , wherein the at least one scanning tool includes an infrastructure security scan tool, a Static Application Security Testing (SAST) tool, a Software Composition Analysis (SCA) tool, a secret scanning tool, Interactive Application Security Testing (IAST) tool, Dynamic Application Security Testing (DAST) tool, bug bounty platforms, Runtime Application Self Protection (RASP) tool, and a manual pen testing tool.
14 . The system according to claim 8 , wherein the processor is further configured to: a. trigger a build automation platform to invoke a vulnerability management platform release gate API; b. informing the vulnerability management platform about creation of the specific release build of the software application; c. trigger the vulnerability management platform to provide the status of the vulnerability state, and to determine whether the release can be deployed; d. trigger the build automation platform to selectively deploy the specific release build of the software application; and e. trigger the vulnerability management platform to generate the script.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS The present application claims the priority from the US Provisional Application with Ser. No. 63/349,572 filed on Jun. 6, 2022, with the title “A METHOD AND SYSTEM FOR SECURITY RISK IDENTIFICATION AND CONTROLLING RELEASE MANAGEMENT OF SOFTWARE APPLICATION WITH VULNERABLE CODES”. The contents of the abovementioned Provisional Application are included in entirety as reference herein. BACKGROUND Technical Field The embodiments herein are generally related to the field of application security. The embodiments herein are particularly related to a method and system for security risk identification in a software application as well as integrated tools to direct the efforts of developers to build and maintain secure software. The embodiments herein are more particularly related to a method and system for security risk identification in a software application and controlling release of software application with vulnerable codes having vulnerabilities which may pose risk in providing secure software services. Description of the Related Art Information security in software is important for all software applications, including those whose primary function is not security. For software developers challenged with coding and maintaining software, there is an overwhelming amount of security-related information, a variety of tools, and numerous identified and unidentified security risks, weaknesses and vulnerabilities that are frequently updated and whose status and level of risk is under constant changes. Software analysts, developers, and testers are often not trained on integrating security features into their code and potential software breaches are too often brought to the attention of developers during emergency situations and/or during quality review and audit. With the ever-changing electronic security landscape, software requires constant updating with relevant security to reduce security risks and prevent breaches. Prevention of security breaches is often more economical than remediation, however keeping abreast of requirements, fixes and breaches can be onerous during the software development and maintenance lifecycle. Software analysts, developers, and testers can therefore be overwhelmed with the amount of available information and variety of tools they can employ and be required to consider long lists of security requirements, guidelines, and standards, and to provide tangible and auditable evidence that software products comply with security guidelines. Security guidance documents are also often static and not updated when modern technologies and vulnerabilities become known, becoming outdated within a short period of time. Software applications which contain vulnerabilities lead to security and compliance breaches of computer systems. If this occurs, the business of the organization running the application is endangered through loss of critical or protected data, loss of reputation, loss of business, or lawsuits. In addition, the computer system may be damaged or impaired. Therefore, it is best practice of the industry to perform dedicated Application Security Testing (AST) to effectively mitigate these risks. An established method for looking for security defects Static Application Security Testing (SAST). They analyze an application's source code or bytecode for security vulnerabilities, typically at the initial stages of the software development life cycle (SDLC). Traditional SCA tools were designed for languages with a static type of system. A static type of system enforces certain properties of the code at design time, which cannot be altered at runtime based on the code's control flow. A static type of system therefore makes reasoning about code's behavior without executing the code reliable, while yielding an acceptable false positive rate. “False positive” refers to an erroneously identified problem by the code analysis tool that does not exist. Another standard analysis method is to observe an application in its dynamic running state during execution. It simulates attacks against an application to analyze the reaction of the application to determine whether the software application is vulnerable. This is commonly known as dynamic code analysis or Dynamic Application Security Testing (DAST). The advantage of this approach is the precision of the analysis since no guesses about the code's behavior are necessary. Furthermore, Interactive AST (IAST) combines inside-out observation of a running application being tested with DAST simultaneously. IAST is typically implemented as an agent within the test runtime environment, for example, instrumenting the Java Virtual Machine (JVM), that observes operation or attacks from within the application and identifies vulnerabilities. In the following, IAST is considered as a special type of DAST. However, Both the DAST and IAST approach have the following limitations. Firstly, to observe the behavior of an application, its co