Method and apparatus for implementing a release automation dashboard module

1. A method for implementing a release automation dashboard module by utilizing one or more processors and one or more memories, the method comprising:

creating a release;

checking, in response to creating, the release for violations against a set of Sarbanes-Oxley (SOX) audit rules;

determining, in response to checking, whether the release complies with the SOX audit rules;

scanning, in response to determining that the release complies with the SOX audit rules, the release for cyber vulnerabilities in accordance with an organization's established practices;

validating, in response to scanning, that the release is scanned for cyber vulnerabilities in accordance with the organization's established practices; and

authorizing deployment of the release based on a determination that one or more features from the release does not violate the set of SOX audit rules and that the one or more features from the release meet a predetermined threshold for the cyber vulnerabilities;

creating a release label corresponding to the release in a project management tool;

creating a release branch corresponding to the release in a version control system; and

displaying status and summary of the release on a graphical user interface (GUI) corresponding to the release label and the release branch,

wherein the GUI displays cyber issues related to the release in a table format that illustrates status of the release as scannable components have not been scanned, wherein the table includes a column for component, a column for non-volatile storage hyperlinked to a private cloud build, a column for existing product vulnerabilities, and a column for vulnerability changes in the release.

2. The method according to claim 1 , wherein the release label corresponds to a version of a software including owner information of the release which is represented in the project management tool.

3. The method according to claim 1 , wherein each feature is a unit of functionality of a software system that satisfies requirements, represents a design decision, and provides a configuration option.

4. The method according to claim 1 , further comprising:

determining that one or more of the features violate the set of SOX audit rules; and

notifying a user of the release, by utilizing an electronic messaging tool, thea status of the release and a list of violations of the SOX audit rules.

5. The method according to claim 1 , further comprising:

identifying one or more features of the release that violate the set of SOX audit rules; and

discarding the identified one or more features that violate the set of SOX audit rules from the release.

6. The method according to claim 1 , further comprising:

identifying one or more features from the release that fail to meet the predetermined threshold for the cyber vulnerabilities; and

displaying the identified one or more features that fail to meet the predetermined threshold for the cyber vulnerabilities onto a graphical user interface (GUI).

7. The method according to claim 1 , further comprising:

receiving a request from a user's device to deploy the release into a production server;

validating authenticity whether the user has permission to deploy the release into the production server by verifying the user's credentials with pre-stored credential information; and

executing deployment of the release into the production server based on a positive verification.

8. A system for implementing a release automation dashboard module, the system comprising:

a database that stores a set of Sarbanes-Oxley (SOX) audit rules; and

a processor coupled to the database via a communication network, wherein the processor is configured to:

create a release;

check, in response to create, the release for violations against the set of Sarbanes-Oxley (SOX) audit rules;

determine, in response to check, whether the release complies with the SOX audit rules;

scan, in response to determine that the release complies with the SOX audit rules, the release for cyber vulnerabilities in accordance with an organization's established practices;

validate, in response to scan, that the release is scanned for cyber vulnerabilities in accordance with the organization's established practices;

authorize, in response to validate, deployment of the release based on a determination that one or more features from the release does not violate the set of SOX audit rules and that the one or more features from the release meet a predetermined threshold for the cyber vulnerabilities;

create a release label corresponding to the release in a project management tool;

create a release branch corresponding to the release in a version control system; and

display status and summary of the release on a graphical user interface (GUI) corresponding to the release label and the release branch,

wherein the GUI displays cyber issues related to the release in a table format that illustrates status of the release as scannable components have not been scanned, wherein the table includes a column for component, a column for non-volatile storage hyperlinked to a private cloud build, a column for existing product vulnerabilities, and a column for vulnerability changes in the release.

9. The system according to claim 8 , wherein the release label corresponds to a version of a software including owner information of the release which is represented in the project management tool.

10. The system according to claim 8 , wherein each feature is a unit of functionality of a software system that satisfies requirements, represents a design decision, and provides a configuration option.

11. The system according to claim 8 , wherein the processor is further configured to:

determine that one or more of the features violate the set of SOX audit rules; and

notify a user of the release, by utilizing an electronic messaging tool, thea status of the release and a list of violations of the SOX audit rules.

12. The system according to claim 8 , wherein the processor is further configured to:

identify one or more features of the release that violate the set of SOX audit rules; and

discard the identified one or more features that violate the set of SOX audit rules from the release.

13. The system according to claim 8 , wherein the processor is further configured to:

identify one or more features from the release that fail to meet the predetermined threshold for the cyber vulnerabilities; and

display the identified one or more features that fail to meet the predetermined threshold for the cyber vulnerabilities onto a graphical user interface (GUI).

14. The system according to claim 8 , wherein the processor is further configured to:

receive a request from a user's device to deploy the release into a production server;

validate authenticity whether the user has permission to deploy the release into the production server by verifying the user's credentials with pre-stored credential information; and

execute deployment of the release into the production server based on a positive verification.

15. A non-transitory computer readable medium configured to store instructions for implementing a release automation dashboard module, wherein, when executed, the instructions cause a processor to perform the following:

creating a release;

checking, in response to creating, the release for violations against a set of Sarbanes-Oxley (SOX) audit rules;

determining, in response to checking, whether the release complies with the SOX audit rules;

scanning, in response to determining that the release complies with the SOX audit rules, the release for cyber vulnerabilities in accordance with an organization's established practices;

validating, in response to scanning, that the release is scanned for cyber vulnerabilities in accordance with the organization's established practices;

authorizing, in response to validating, deployment of the release based on a determination that the one or more features from the release does not violate the set of SOX audit rules and that one or more features from the release meet a predetermined threshold for the cyber vulnerabilities;

creating a release label corresponding to the release in a project management tool;

creating a release branch corresponding to the release in a version control system; and

displaying status and summary of the release on a graphical user interface (GUI) corresponding to the release label and the release branch,

wherein the GUI displays cyber issues related to the release in a table format that illustrates status of the release as scannable components have not been scanned, wherein the table includes a column for component, a column for non-volatile storage hyperlinked to a private cloud build, a column for existing product vulnerabilities, and a column for vulnerability changes in the release.

16. The non-transitory computer readable medium according to claim 15 , wherein the instructions, when executed, further cause the processor to perform the following:

determining that one or more of the features violate the set of SOX audit rules; and

notifying a user of the release, by utilizing an electronic messaging tool, a status of the release and a list of violations of the SOX audit rules.

17. The non-transitory computer readable medium according to claim 15 , wherein the instructions, when executed, further cause the processor to perform the following:

identifying one or more features from the release that fail to meet the predetermined threshold for the cyber vulnerabilities; and

displaying the identified one or more features that fail to meet the predetermined threshold for the cyber vulnerabilities onto a graphical user interface (GUI).

18. The non-transitory computer readable medium according to claim 15 , wherein the instructions, when executed, further cause the processor to perform the following:

receiving a request from a user's device to deploy the release into a production server;

validating authenticity whether the user has permission to deploy the release into the production server by verifying the user's credentials with pre-stored credential information; and

executing deployment of the release into the production server based on a positive verification.