Patent Publication Number: US-2021173935-A1

Title: Method and system for automatically identifying and correcting security vulnerabilities in containers

Description:
FIELD OF THE INVENTION 
     The present disclosure relates in general to the fields of software security and containers that deploy applications, and in particular to methods and systems for scanning and rectifying security vulnerabilities in containers and updating security rules. 
     BACKGROUND 
     Basic techniques and platforms for running applications segregated by the use of kernel containerization are known in the art. Linux containers are commonly used to deploy applications. Containers improve reproducibility and scalability in software development. Containerization platforms, such as Docker, enable users to develop, deploy, and run applications inside containers. Containers allow a developer to package up applications with all of the necessary components, such as libraries and other dependencies, and ship out the bundle as one package. Containers are used for web, applications and caching services, network daemons, and small databases. 
     An image for a container may be a file comprised of multiple layers that may be used to execute code in the container. A container may be the instantiation of an image, such that the container may be the runtime instance of the image. An image may be built from the instructions for a complete and executable version of an application, which relies on the host operating system kernel. A container may be a virtual environment that runs an application that is not dependent on the operating system. The kernel of the host operating system may run the different functions of the application that are separated into containers. 
     Containers do not offer the same security and stability provided by virtual machines (VMs). A container may share the kernel of the host operating system to run all of the applications with the container. Thus, such apps may not run as isolated as a VM. Containers may be process-level isolated, but one container may affect other contains by compromising the stability of the kernel. A malware attack from a container into the operating system can propagate to other containers, and spread the attack in an uncontrolled manner. 
     Traditional approaches for running applications inside containers may not ensure sufficient security because containerization lacks isolation from the host OS. Further, conventional systems for scanning containers do not provide useful summary reports for security risks and automatic rule updates. More secure solutions are desired by software developers to automatically identify and rectify security vulnerabilities in containers, and automatically update the set of security rules for such vulnerabilities. Accordingly, there is a need for an automatic correction engine and automatic rule refresh engine to more efficiently and effectively reduce security risks in a containerization platform. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The foregoing and other objects, features, and advantages for embodiments of the present disclosure will be apparent from the following more particular description of the embodiments as illustrated in the accompanying drawings, in which reference characters refer to the same parts throughout the various views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating principles of the present disclosure. 
         FIG. 1  is a block diagram illustrating an example of an architecture for an exemplary system for identifying, reporting and rectifying security vulnerabilities in a containerization platform, and/or a system for updating security rules in containers, in accordance with certain embodiments of the present disclosure. 
         FIG. 2  is a block diagram illustrating an embodiment of a report engine for implementing the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 3  is a block diagram illustrating an embodiment of a scan engine for implementing the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 4  is a flow diagram illustrating an example of a method implemented by the scan engine depicted in  FIG. 3 , in accordance with certain embodiments of the present disclosure. 
         FIG. 5  is a block diagram illustrating an embodiment of an auto rule update engine for implementing the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 6  is a flow diagram illustrating an example of a method implemented by the auto rule update engine depicted in  FIG. 3 , in accordance with certain embodiments of the present disclosure. 
         FIG. 7  is a block diagram illustrating an embodiment of an auto correction engine for implementing the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 8  illustrates an exemplary graphical user interface through which a private image for a container may be scanned by the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 9  illustrates an exemplary graphical user interface through which a public image for a container may be scanned by the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 10  illustrates an exemplary graphical user interface for a dashboard depicting details of a scan of an image by the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 11  illustrates an exemplary graphical user interface for a dashboard depicting security vulnerabilities identified by a scan of an image performed by the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 12  illustrates an exemplary graphical user interface for a history of image scans performed by the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 13  illustrates an exemplary graphical user interface for comparing security vulnerabilities of images scanned by the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 14  illustrates an exemplary graphical user interface through which reference links may be clicked to access details of security vulnerabilities identified by scanning images with the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 15  illustrates an exemplary graphical user interface through which an user may be added to access reports, history data, and vulnerability comparisons for scans of images performed by the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 16  illustrates an exemplary graphical user interface listing updates for security vulnerabilities added to the scan engine depicted in  FIG. 3 , in accordance with certain embodiments of the present disclosure. 
         FIG. 17  illustrates an exemplary graphical user interface listing security guidelines, recommendations and/or practices for the secure use of containers through use of the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 18  illustrates an exemplary home screen view of a graphical user interface through which an user may access the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 19  illustrates an exemplary home screen view of a graphical user interface through which an admin may access the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
         FIG. 20  illustrates an exemplary list of CVEs that may be stored in a security vulnerability database, in accordance with certain embodiments of the present disclosure. 
         FIG. 21  illustrates two exemplary lists of CVEs and their corresponding severity ratings that catalogs the security vulnerabilities for versions of a container image, in accordance with certain embodiments of the present disclosure. 
         FIG. 22  is a flowchart illustrating an embodiment for a method performed by the exemplary system depicted in  FIG. 1 , in accordance with certain embodiments of the present disclosure. 
     
    
    
     DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION 
     Reference will now be made in detail to the embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. 
     The present disclosure may be embodied in various forms, including a system, a method, a computer readable medium, or a platform-as-a-service (PaaS) product for scanning and rectifying security vulnerabilities in containerization platforms and updating security rules. In some examples, a technical advantage of the present disclosures described herein is the identification of security vulnerabilities in containers and/or their associated images. Another technical advantage may be correcting such security vulnerabilities by updating the containers and/or their associated images with security updates. Yet another technical advantage may be an ability to automatically update a set of security rules that apply to the containers and/or their associated images. In certain examples, a technical advantage may include the reporting of security vulnerabilities identified by an image scan, and the reporting of vulnerability comparisons for an initial version of an image and an updated version of the image that includes the implemented security updates. 
       FIG. 1  illustrates an embodiment of such a system  100  that may be implemented in many different ways, using various components and modules, including any combination of circuitry described herein, such as hardware, software, middleware, application program interfaces (APIs), and/or other components for implementing the corresponding features of the circuitry. The system  100  may include a scan engine  101 , an auto correction engine  102 , an auto rule update engine  103 , and/or a report engine  104 . 
     In an embodiment, the system  100  may include a computing device  105 , which may include a memory  106  and a processor  107 . The system  100  may also include generated graphical user interfaces (GUIs), such as a scan user interface (UI)  108  and an admin UI  109 , that may be configured to communicate with an API layer  110 . As discussed below, users and administrators (admins) may interface with the system  100  via these UIs  108 / 109 . In some embodiments, the memory  106  may include the components and modules of the system  100 , including the scan engine  101 , the auto correction engine  102 , the auto rule update engine  103 , the report engine  104 , the scan UI  108 , the admin UI  109 , and the API layer  110 . 
     The scan engine  101  may be configured to scan a container image  111  for security vulnerabilities  112  (not shown). The image  111  may be a binary representation of a container  113  (not shown). The container  113  may be the runtime state of the corresponding image  111 . The image  111  may include stackable layers  114  (not shown), also known as intermediate images, which include read-only files that correspond to the filesystem (fs) for the container  113 . A container  113  may include a read-write top layer  114 , with a series of read-only layers  114  of the image  111  underneath it. The read-only layers  114  may be generated by commands executed when a container  113  is built. An image  111  may contain an executable application  115  (not shown) and its runtime dependencies, such as the modules, binaries, libraries, utilities, middleware, packages or configuration files required to setup and run the application  115 . A new layer  114  may be generated when a container  113  is run. A layer  114  may store the difference between the previous and the current version of the image  111 . Upon scanning an image  111  for security vulnerabilities  112 , the scan engine  101  may also rectify the identified security vulnerabilities  112 . In addition, the scan engine  101  may generate scan results  116  (not shown), which may be stored in a scan results database  117 . 
     The system  100  may also include a security vulnerability database  118  that stores the security vulnerabilities  112 , and/or security rules  119  (not shown) utilized to identify and/or rectify the security vulnerabilities  112  of the image  111 . The scan results database  117  and the security vulnerability database  118  may be logically and physically organized in many different ways, and may be implemented with different types of data structures such as linked lists, hash tables, or implicit storage mechanisms. In an embodiment, the scan results database  117  may be a relational database, such as a MySQL database. The security vulnerability database  118  may be an object-relational database, such as a PostgresSQL database. The databases may be stored in the memory  106  of the device  105 , or distributed across multiple devices, processing systems, or repositories. For example, the scan engine  101  and the auto rule update engine  103  may be configured to communicate with various external systems  120 . 
     The scan engine  101  may be further configured to receive container images  111 , which may already be stored in the memory  106  or may be received from external systems  120 . In an embodiment, a container image  111  may be received from a container image repository  121  of an external system  120 . The container image repository  121  may be private or public. In certain embodiments, the received image  111  may be scanned based on the security vulnerabilities  112  and/or the security rules  119  stored in the security vulnerability database  118 . In some embodiments, the scan engine  101  may identify certain security vulnerabilities  112  used to scan an image  111  based on security rules  119  (e.g., identifying only those security vulnerabilities  112  that have a certain severity rating  510 , as discussed below). The scan engine  101  may be further configured to rectify the identified security vulnerabilities  112  based on the security rules  119 , and/or security updates  123  (discussed below) stored in the security vulnerability database  118 . The scan engine  101  may then generate the scan results  116 , which may be stored in the scan results database  117 . Scan reports  122  (not shown) displaying the scan results  116  may be generated via the API Layer  110  and the report engine  104 . The scan reports  122  may be accessed by users and admins via the scan UI  108  and admin UI  109 , respectively. 
     In certain embodiments, the auto correction engine  102  may analyze scan results  116  for a container image  111  and update the image  111  based on the scan results  116 . A container  113  may be the instantiation of the image  111 . Accordingly, the code in the initial image  111  may be executed in order to generate an interactive container  113  that may be modified. That initial container  113  may be modified to rectify security vulnerabilities  112  identified in the scan results  116 . An updated image  111  may be generated from the modified container  113 . In some embodiments, the container  113  may be updated with security patches or update(s)  123  (not shown) based on security vulnerabilities  112  identified in the scan results  116 . The security update  123  may be stored in the security vulnerability database  118 . A new version of the image  111  may be generated based on the updated container  113  that includes the necessary security updates  123 . In some embodiments, the security vulnerabilities  112  and/or the security rules  119  that are stored in the security vulnerability database  118  may be updated based on the security updates  123 . The updated image  111  may be re-scanned, in the manner discussed above, and updated scan results  116  may be stored in the scan results database  117 . Updated scan reports  122  displaying the updated scan results  116  (based on the re-scan of the updated image  111 ) may be generated via the API Layer  110  and the report engine  104 . The updated scan reports  122  may be accessed by users and admins via the scan UI  108  and admin UI  109 , respectively. 
     The auto rule update engine  103  may be configured to receive Common Vulnerabilities and Exposures (CVEs)  124  from the external systems  120  of CVE Numbering Authorities (CNAs). As shown in  FIG. 20 , CVEs  124  may include a CVE identification number  125  and a CVE description  126 . Referring back to  FIG. 1 , in certain embodiments, CVEs  124  may be received from a CVE database  127 , such as the publically accessible database proffered by the external systems  120  for the U.S. National Institute of Standards and Technology (NIST), which is the U.S. government repository of standards based vulnerability management data. Software vendors (e.g., Debian or RedHat) may also be CNAs, which offer CVEs  124  relating to security vulnerabilities  112  specific to their software. The CVEs  124  may list the identifiable security vulnerabilities  112  that may affect a containerized application  115 , the source code and data of the container  113 , the layers of the image  111 , the container engine  128  (not shown), components shared across the containerization platform, the host operating system  129  and its kernel  130  (not shown), and/or the API server. The auto rule update engine  103  utilizes the CVEs  124  to enable automation of vulnerability management, security measurement, and compliance. 
     In an embodiment, the updated CVEs  124  that are received from a CVE database  127  may be stored in the security vulnerability database  118  in order to update the listing of CVEs  124 , and/or to update the security rules  119  stored in the security vulnerability database  118 . As discussed below, the stored CVEs  124  may be supplemented with additional CVEs  124  received from a CVE database  127  that may be checked for updates at regular intervals. The image  111  may be scanned by the scan engine  101  to identify security vulnerabilities  112  based on the updated CVEs  124 , and/or the updated security rules  119 . Accordingly, the scan engine  101  may scan an image  111  for identifiable security vulnerabilities  112 , which may include those security vulnerabilities  112  that are listed in the security vulnerability database  118 . The scan engine  101  may generate updated scan results  116 , which may be stored in the scan results database  117 . In addition, updated scan reports  122  displaying the updated scan results  116  (based on the re-scan of the image  111  using the updated CVEs  124  and/or the updated security rules  119 ) may be generated via the API Layer  110  and report engine  104 . The updated scan reports  122  may be accessed via the scan UI  108  and admin UI  109 , respectively, in order to compare the security vulnerabilities  112  between the two versions of the same image  111 . Based on such a vulnerability comparison, the system  100  may determine the success rate of the updated CVEs  124  and/or the updated security rules  119  based on the newly received CVEs  124  and/or the security patches/updates  123  used to update a container  113 . 
       FIG. 2  illustrates an embodiment of a report engine  104  for generating scan reports  122  based on scan results  116  generated by the scan engine  101 . In an embodiment, the report engine  104  receives scan results  116  that are stored in the scan results database  117  via the API Layer  110 . Based on scan results  116 , the report engine  104  may generate scan reports  122  in various formats. For example, the report engine  104  may generate downloadable files  201  (such as a PDF file or a Microsoft Excel file) that render the scan results  116 . In addition, the report engine  104  may render the scan results  116  through an API or GUI, such the scan UI  108  or the admin UI  109 . Such renderings may include a detailed view  202  and/or an executive view  203 . 
       FIG. 3  is a diagram showing components of the scan engine  101  and the interactions between the scan engine  101  and a container image repository  121  and a scan UI  108 , in accordance with certain embodiments. A container image  111  may be received by the scan engine  101  from the image repository  121 , which may reside in an external system  120  such as a Docker repository where collections of Docker images  111  are publically stored. Because images  111  and their corresponding containers  113  may be immutable, a new version of the image  111  may necessarily be generated if any changes are implemented to an existing image  111 . Accordingly, an image  111  may have an identifier such an unique hash. In addition, a container image  111  may be labeled with metadata  131  that further enable the management of the image  111  and its corresponding container  113 . For example, an image  111  may be tagged with labels or metadata  131  that describe the code used to build the image  111  and the repository  121  from which the image  111  was received. The metadata  131  may include an image URL that identifies a webpage having more information about the particular image  111 . A new version of an image  111  may include the labels/metadata  131  of its ancestor image  111  because metadata  131  may be inherited. 
     In some embodiments, the scan engine  101  may include an image extractor  301  and a Representational State Transfer (REST) API  302 . The image extractor  301  may receive the metadata  131  of the image  111  from the repository  121  and transfer the metadata  131  to the REST API  302 . The REST API  302  may include an image analyzer  303  and an image validator  304 . The image analyzer  303  may read the metadata  131  of an image  111  and analyze its individual image layers  114  for security vulnerabilities  112 . The image validator  304  may validate each image layer  114  against previous scan data  305  (not shown), such as metadata  131  of images  111  that were previously scanned by the scan engine  101 . An output composer  306  may collect scan data  305  of the scanned image  111  from the REST API  302 , and compose the scan data  305  in various formats (e.g., JSON and text) which can be further configured and transmitted to the scan UI  108  or the admin UI  109 . The scan data  305  may be configured by the API layer  110  and/or the report engine  104 . 
       FIG. 4  is a flowchart illustrating exemplary steps of processes and methods for scanning a container image  111  for security vulnerabilities  112  via a scan engine  101 , as implemented in accordance with certain embodiments. The processes described herein may be implemented by the system  100 , the computing device  105 , a computer readable medium, a PaaS product, and/or circuitry components as described herein. As shown in  FIG. 4 , a scan engine  101  may: access a container image repository  121  (block  401 ); and, search for a container image  111  (block  402 ). For example, the scan engine  101  may access a Docker repository  121  and search for a Docker image  111 . In an embodiment, the scan engine  101  may check the accessibility and permissions associated with the image  111  in order to determine any restrictions assigned by the repository  121  (block  403 ). The scan engine  101  may: receive and/or extract the image  111  (block  404 ); and, read the image  111  (block  405 ) (e.g., read the metadata  131  from the image layers  114  of the image file  111 ). These two steps may be performed by the image extractor  301  and the REST API  302 , respectively. The scan engine  101  may analyze the individual image layers  114  of the image  111  (block  406 ). For example, the metadata  131  of each image layer  114  may be analyzed and validated against previous scan data  305  by the image validator  304 . 
     In addition, the scan engine  101  may identify the version of the image  111  (block  407 ). In an embodiment, this may include identification of the executable software/application  115  of the image  111 . The scan engine  101  may search the security vulnerability database  118  for security vulnerabilities  112 , and/or any security rules  119  associated with such security vulnerabilities  112 . In an embodiment, this scan may be based on the identified version for the application  115  (block  408 ). In addition, the scan engine  101  may retrieving the identified security vulnerabilities  112  based on the version of the software/application  115 , and store the identified security vulnerabilities  112  as being associated with the scanned image  111  in the scan results database  117  (block  409 ). The security vulnerabilities  112  stored in association with the scanned image  111  in the scan results database  117  may be transmitted to the report engine  104 . 
     In an embodiment, as an initial step of the method, the scan engine  101  may receive (block  410 , not shown) a scan request  411  (not shown) to scan an image  111  based on an image name  412 , image type  413  (e.g., public or private), container image registry  414 , and/or project name  415 . Upon receiving such a scan request  411 , the scan engine  101  may access the container image repository  121  (block  401 ) and search for a container image  111  (block  402 ). In an embodiment, the scan engine  101  may download (block  416 , not shown) a private or public container  113  (not shown) for scanning (block  417 , not shown). The container  113  may be downloaded (block  416 ) from the repository  121 , and may correspond to the image  111  requested by the scan request  411 . The downloaded container  113  may be scanned (block  417 ) for security vulnerabilities  112  identified as being associated with the requested image  111 . In some embodiments, the scan request  411  may be received via the scan UI  108  or admin UI  109 . 
       FIG. 5  illustrates an embodiment of an auto rule update engine  103  for updating the security vulnerabilities  112 , and/or security rules  119 , stored in the security vulnerability database  118  based on CVEs  124  received from a CVE data source  501 , such as a CVE database  127  or an external system  120  of a CNA (e.g., Debian or RedHat). The auto rule update engine  103  may include a CVE data source connector  502  that connects to a CVE data source  501  based on an API call  503  (not shown) received from an API  504  of the auto rule update engine  103 . At regular intervals, a scheduler  505  may trigger the API  504  to initiate an update of the security vulnerabilities  112 , and/or security rules  119 , stored in the security vulnerability database  118 . In some embodiments, the API  504  may initiate an update upon such predetermined time intervals set by the scheduler  505 , and/or upon certain occurrences, events, or requests. For example, an update may be requested by the API  504  from the CVE data source  501  in response to a CVE update request  511  (not shown) received from the scan engine  101  upon the occurrence of a scan request  411 , as described above. Further, the API  504  may receive configuration data  506  (not shown) used to connect to the CVE data source  501 . The configuration data  506  may be received from a CVE data source configurator  507 , which may contain the configuration data  506  of the various CVE data sources  501 . The auto rule update engine  103  may also include a CVE data source parser  508  that may arrange CVE data  509  (not shown), which may be received from the CVE data source  501  in different formats, into a uniquely format compatible with the security vulnerability database  118 . The reformatted CVE data  509  may include the CVE identification numbers  125  and the CVE descriptions  126  of CVEs  124 , as illustrated in  FIG. 20 . 
     Referring back to  FIG. 5 , the CVE data source parser  508  may update the security vulnerability database  118 . In certain embodiments, this updating step may include adding new rows to a table in the security vulnerability database  118  that represent newly received CVEs  124 . In some embodiments, the CVE data  509  may also include severity ratings  510  (as shown in  FIG. 21 ) that characterize the severity of security vulnerabilities  112 . Such severity ratings  510  may be predetermined and assigned to CVEs  124  by the Common Vulnerability Scoring System (CVSS), which was launched by the U.S. National Infrastructure Advisory Council (NIAC) in 2005 and is currently maintained by the Forum of Incident Response and Security Teams (FIRST). In an embodiment, severity ratings  510  may be assigned and/or adjusted by the auto rule update engine  103 . 
     As shown in  FIG. 6 , the auto rule update engine  103  may implement a method that includes the initial steps of: pulling or receiving security vulnerabilities  112  from a CVE database(s)  127  (block  601 ); and, storing those security vulnerabilities  112  in the security vulnerability database  118  (block  602 ). These two steps (blocks  601 ,  602 ) may be part of a setup or installation of the system  100 , wherein the entire contents of the CVE database(s)  127  (i.e., security vulnerabilities  112  for a plurality of images  111 ) are loaded into the security vulnerability database  118 . Accordingly, such a “data dump” may not reference a particular image  111 . The method may further include the steps of: requesting the latest, updated security vulnerabilities  112  of an image  111  from the CVE database(s)  127  (block  603 ); receiving the updated security vulnerabilities  112  of an image  111  from the CVE database(s)  127  (block  604 ); and, storing the updated security vulnerabilities  112  in the security vulnerability database  118  (block  605 ). These three steps (blocks  603 ,  604 ,  605 ) may be performed at regular intervals, e.g. every two hours. For example, in certain embodiments, the scheduler  505  may be set to a predetermined time interval when the scheduler  505  triggers or prompts the API  504  to request/initiate (block  603 ) an update of the security vulnerabilities  112 , and/or security rules  119 , stored in the security vulnerability database  118 . In some embodiments, the API  504  of the auto rule update engine  103  may initiate (block  603 ) an update from the CVE data source  501  upon receiving (block  610 , not shown) a CVE update request  511  from the scan engine  101 , which may be transmitted upon the scan engine  101  receiving (block  410 ) a scan request  411  to scan an image  111 . 
       FIG. 7  illustrates an embodiment of an auto correction engine  102  for updating the container image  111 . In certain embodiments, the auto correction engine  102  may automatically initiate an update of an image  111  upon receiving the image  111  from a container image repository  121 . In some embodiments, the auto correction engine  102  may automatically initiate an update of an image  111  upon analyzing scan results  116  for an image  111  and determining that the security vulnerabilities  112  identified in the scan results  116  are severe enough to require a security patch/update  123  for the scanned image  111 . For example, such a severity determination may determine whether the security vulnerability  112  has a severity rating  510  that is high or critical, as defined by the current CVSS. According to the qualitative severity rating scale for the most recent version of the scoring system, CVSS v3.1, the qualitative severity ratings  510  are mapped to CVSS scores  700  (not shown), as follows: a CVSS score  700  of 0.0 receives a “None” severity rating  510 ; a 0.1-3.9 CVSS score  700  is assigned a “Low” severity rating  510 ; a CVSS score  700  of 4.0-6.9 is a “Medium” severity rating  510 ; a CVSS score  700  of 7.0-8.9 is a “High” severity rating  510 ; and, a CVSS score  700  of 9.0-10.0 is a “Critical” severity rating  510 . The CVEs  124  stored in the security vulnerability database  118  may include severity ratings  510  and/or CVSS scores  700 . In some embodiments, the CVE data  509  may include CVSS scores  700 , and the severity determination may be based on the CVSS score  700  for the security vulnerability  112  as opposed to the qualitative rating. 
     As shown in  FIG. 7 , an auto correction engine  102  may include an image loader  701  that may pull or receive the image  111  to be updated from a container image repository  121 . The repository  121  may be private or public. The auto correction engine  102  may further include a container executer  702 , which may execute the received image  111  in the form of an interactive container  113 . In addition, the auto correction engine  102  may include a container updater  703  that may update the container  113  with a security patches/updates  123  received from an image layer data source  704 . In an embodiment, the security update  123  may be stored in the security vulnerability database  118 , so that the auto correction engine  102  may first check the security vulnerability database  118  for a security update  123  to rectify a security vulnerability  112  identified in scan results  116  for images  111 . The auto correction engine  102  may also include an image rebuilder  705  that may save the security updates  123  made to the container  113 , and rebuild the image  111 . In certain embodiments, the auto correction engine  102  may include an image versioning  706  that may generate a new version of the image  111  that has the security updates  123 . 
     As referenced above, the memory  106  may include generated GUIs that the processor  107  is configured to cause to be displayed.  FIGS. 8-19  illustrate examples of such GUIs in accordance with certain embodiments of the present disclosure.  FIG. 8  is an example of an admin UI  109  through which a private image  111  (not shown) for a container  113  (not shown) may be scanned by the system  100 . The following information may be entered through the GUI to identify the private image  111  to be scanned: an image name  412 , image type  413 , container image registry  414 , project name  415 , and private registry login credentials  801 . Upon entering such information, an admin may click the “scan” button  802  to submit the scan request  411 . 
       FIG. 9  is an example of an admin UI  109  through which a public image  111  (not shown) for a container  113  (not shown) may be scanned by the system  100 . The following information may be entered through the GUI to identify the public image  111  to be scanned: an image name  412 , image type  413 , container image registry  414 , and project name  415 . Upon entering such information, an admin may click the “scan” button  901  to submit the scan request  411  to the scan engine  101  and initiate an image scan  902  (now shown). 
     Upon running an image scan  902 , a scan report  122  may be generated in various formats.  FIG. 10  illustrates an example of an admin UI  109  including a dashboard  1000  that depicts an executive view  203  generated by the report engine  104  for a scan of an image  111  (not shown) by the system  100 . The executive view  203  may render the following scan results  116 : the image name, the total layers scanned, the scan start time, the scan duration, the overall number of security vulnerabilities, and the number of security vulnerabilities based on the severity ratings  510  (e.g., critical, high, medium, and low). Graphical representations of the number of security vulnerabilities based on the severity ratings  510  may also be displayed via a pie chart, a bar graph, and a gauge chart. When an admin clicks the “Download PDF” button  1001  or the “Download Excel” button  1002  displayed in the dashboard  1000 , the report engine  104  may generate the requested downloadable file (not shown) that renders the scan results  116 . Such files may be transmitted to the admin via the admin UI  109 . 
       FIG. 11  is an example of an admin UI  109  including a dashboard  1000  that depicts CVEs  124  that were identified by the image scan  902 . The report engine  104  may generate such a CVE listing, which may include columns for the following information: the CVE identification numbers  125 , the CVE descriptions  126 , the severity ratings  510 , and CVE reference links (e.g., a URL or Uniform Resource Locator)  1100  linked to webpages that may provide additional details about the security vulnerabilities  112  identified by the image scan  902 . In an embodiment, the CVE reference links  1100  may be interactive, having embedded hyperlinks, so that an admin may click the links in order to be redirected to the referenced webpage via a web browser. 
       FIG. 12  is an example of an admin UI  109  depicting historical data  1200  for scans of images  111 . This scan history  1200  may be received by the report engine  104  from the scan results database  117 . The historical data  1200  may be filtered by project name  415 . In an embodiment, the historical data  1200  may be searched by image name  412 . This admin UI  109  may display historical data  1200  for each image scan  902 , including: image names  412 , project names  415 , scan date and time, the number of scanned image layers  114 , and a link  1204  to the scan reports  122 . In addition, the admin UI  109  may display checkboxes  1201  in order to select image scans  902  for vulnerability comparisons  1202  (not shown). Upon selecting two or more image scans  902  by checking their corresponding checkbox  1201 , an admin may click the “Compare Vulnerabilities” button  1203  in order to run a vulnerability comparison  1202 . As described above, the vulnerability comparison  1202  may compare the security vulnerabilities  112  between the two versions of the same image  111 . Accordingly, the vulnerability comparisons  1202  may identify the success rate of the updated CVEs  124  and/or the updated security rules  119  based on the newly received CVEs  124  and/or the security patches/updates  123  used to update a container  113 . 
       FIG. 13  is an example of an admin UI  109  depicting two checkboxes  1201  selected for two image scans  902  of two versions of the image  111 , which may have matching image names  412 . Upon clicking the “Compare Vulnerabilities” button  1203 , a vulnerability comparison  1202  (not shown) may be generated for each CVEs  124  identified by the selected image scans  902  for the scanned image  111 .  FIG. 14  is an example of an admin UI  109  rendering the vulnerability comparisons  1202  for those two image scans  902 . A vulnerability comparisons  1202  may list CVEs  124  for each security vulnerabilities  112  identified by the compared image scans  902 . This admin UI  109  may display the following information for each CVEs  124  identified by the image scans  902  for the scanned image  111 : the CVE identification number  125 ; a comparison link  1400  to the vulnerability comparisons  1202 ; and, the severity rating  510 . Such information may be received by the report engine  104  from the security vulnerability database  118 . 
       FIG. 15  is an example of an admin UI  109  for adding new users to the disclosed system  100 . The system  100  searches a user database (not shown) to verify that the user name  1500  for the new user is not already listed in the user database. The new user name  1500  can be assigned a user role  1501  of admin or user. In addition, the new user name  1500  can be assigned a user password  1502  (not shown). This admin UI  109  may be further configured to enable the deletion of a user name  1500 , or to edit the profile or user credentials  1504  (e.g., assigned name, password, role, and permissions) of a user name  1500 . Upon entering a new user name  1500 , password  1502  and user role  1501 , an admin may click the “ADD USER” button  1503  in order to add the new user name  1500  to the system  100 . 
       FIG. 16  is an example of an admin UI  109  for listing the latest CVEs  124  for security vulnerabilities  112  that have been added to the security vulnerability database  118 . This admin UI  109  may list the CVE identification number  125  for each CVEs  124 . The admin UI  109  may also list the CVE updated time  1600  for each CVEs  124 . As shown in  FIG. 17 , security guidelines and best practices  1700  may posted via an admin UI  109  in order to provide users with instructions and recommendations for the secure use of containers  113  and images  111 .  FIGS. 18-19  are examples of a scan UI  108  and an admin UI  109 , respectively. Such GUIs may include a drop-down menu  1900  to logout of the system  100 . 
     As noted above,  FIG. 20  illustrates an exemplary list of CVEs  124  that may be stored in a table residing in the security vulnerability database  118 . This table may include columns for the CVE identification number  125  and the CVE description  126 .  FIG. 21  illustrates two exemplary lists of CVEs  124  and their corresponding severity ratings  510 . These lists may be stored in a dataset or table/spreadsheet  2100  residing in the security vulnerability database  118 . These tables may each include columns for the CVE identification number  125 , the CVE description  126 , and the severity ratings  510  for each security vulnerability  112  compared between two versions of an image  111  (e.g., an initial image  111 , and the corresponding updated image  111  generated from a modified version of the initial container  113  instantiated from the initial image  111 ). 
     In some embodiments, the computer device  105  may include communication interfaces, system circuitry, input/output (I/O) interface circuitry, and display circuitry. The graphical user interfaces (GUIs)  210  displayed by the display circuitry may be representative of GUIs generated by the system  100  to present a query to an enterprise application or end user. The graphical user interfaces (GUIs) displayed by the display circuitry may also be representative of GUIs generated by the system  100  to receive query inputs. The GUIs may be displayed locally using the display circuitry, or for remote visualization, e.g., as HTML, JavaScript, audio, and video output for a web browser running on a local or remote machine. The GUIs and the I/O interface circuitry may include touch sensitive displays, voice or facial recognition inputs, buttons, switches, speakers and other user interface elements. Additional examples of the I/O interface circuitry includes microphones, video and still image cameras, headset and microphone input/output jacks, Universal Serial Bus (USB) connectors, memory card slots, and other types of inputs. The I/O interface circuitry may further include magnetic or optical media interfaces (e.g., a CDROM or DVD drive), serial and parallel bus interfaces, and keyboard and mouse interfaces. 
     The communication interfaces may include wireless transmitters and receivers (herein, “transceivers”) and any antennas used by the transmit-and-receive circuitry of the transceivers. The transceivers and antennas may support WiFi network communications, for instance, under any version of IEEE 802.11, e.g., 802.11n or 802.11ac, or other wireless protocols such as Bluetooth, Wi-Fi, WLAN, cellular (4G, LTE/A). The communication interfaces  202  may also include serial interfaces, such as universal serial bus (USB), serial ATA, IEEE 1394, lighting port, I 2 C, slimBus, or other serial interfaces. The communication interfaces may also include wireline transceivers to support wired communication protocols. The wireline transceivers may provide physical layer interfaces for any of a wide range of communication protocols, such as any type of Ethernet, Gigabit Ethernet, optical networking protocols, data over cable service interface specification (DOCSIS), digital subscriber line (DSL), Synchronous Optical Network (SONET), or other protocol. 
     The system circuitry may include any combination of hardware, software, firmware, APIs, and/or other circuitry. The system circuitry may be implemented, for example, with one or more systems on a chip (SoC), servers, application specific integrated circuits (ASIC), field programmable gate arrays (FPGA), microprocessors, discrete analog and digital circuits, and other circuitry. The system circuitry may implement any desired functionality of the system  100 . As just one example, the system circuitry may include one or more instruction processor  107  and memory  106 . 
     The processor  107  may be one or more devices operable to execute logic. The logic may include computer executable instructions or computer code embodied in the memory  106  or in other memory that when executed by the processor  107 , cause the processor  107  to perform the features implemented by the logic. The computer code may include instructions executable with the processor  107 . Logic, such as programs or circuitry, may be combined or split among multiple programs, distributed across several memories and processors, and may be implemented in a library, such as a shared library (e.g., a dynamic link library or DLL). 
     The memory  106  stores, for example, control instructions for executing the features of the disclosed system  100 , as well as the operating system  129 . Examples of the memory  106  may include non-volatile and/or volatile memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or flash memory. Alternatively or in addition, the memory  106  may include an optical, magnetic (hard-drive) or any other form of data storage device. In one implementation, the processor  107  executes the control instructions and the operating system  129  to carry out any desired functionality for the disclosed system  100 , including without limitation those attributed to data receiver (e.g., relating to the data receiver circuitry), GUI generation, image layer  114  generation, image  111  generation, and/or scan results  116  generation. The control parameters may provide and specify configuration and operating options for the control instructions, operating system  129 , and other functionality of the computer device  105 . 
     The computer device  105  may further include various data sources, as described herein. Each of the databases that are included in the data sources may be accessed by the system  100  to obtain data for consideration during any one or more of the processes described herein. For example, the data receiver circuitry may access the data sources to obtain the information for generating the images  111  and the scan results  116 . In an embodiment, a data receiver circuitry may be configured to receive an image  111 . 
     All of the discussion, regardless of the particular implementation described, is exemplary in nature, rather than limiting. For example, although selected aspects, features, or components of the implementations are depicted as being stored in memories, all or part of the system or systems may be stored on, distributed across, or read from other computer readable storage media, for example, secondary storage devices such as hard disks, flash memory drives, floppy disks, and CD-ROMs. Moreover, the various modules and screen display functionality is but one example of such functionality and any other configurations encompassing similar functionality are possible. 
     The respective logic, software or instructions for implementing the processes, methods and/or techniques discussed above may be provided on computer readable storage media. The functions, acts or tasks illustrated in the figures or described herein may be executed in response to one or more sets of logic or instructions stored in or on computer readable media. The functions, acts or tasks are independent of the particular type of instructions set, storage media, processor or processing strategy and may be performed by software, hardware, integrated circuits, firmware, micro code and the like, operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing and the like. In one embodiment, the instructions are stored on a removable media device for reading by local or remote systems. In other embodiments, the logic or instructions are stored in a remote location for transfer through a computer network or over telephone lines. In yet other embodiments, the logic or instructions are stored within a given computer, central processing unit (“CPU”), graphics processing unit (“GPU”), or system. 
       FIG. 22  illustrates another example of a method that may be implemented by the system  100  (not shown), the computing device  105  (not shown), a computer-readable medium  2200  (not shown), a PaaS product, and/or circuitry components as described herein. In such embodiments, the method may enable the identification of security vulnerabilities related to containerization platforms. The method may include the steps of: accessing a repository (block  221 ); searching the repository for an image (block  222 ); extracting the image from the repository (block  223 ). The repository may include a plurality of container images. The image may include layered code files. The processor may be adapted to execute the layered code files to generate an image container configured to deploy an executable application adapted to run on an operating system. 
     In addition, the method may include the steps of: identifying an initial version of the image based on the layered code files (block  224 ); and, scanning the initial version of image for identifiable security vulnerabilities (block  225 ). The identifiable security vulnerabilities may have Common Vulnerabilities and Exposures (CVE) identification numbers that may be stored in a security vulnerability database. The processor may be adapted to access the security vulnerability database. Further, the method may include the steps of: generating a first scan result listing the identified security vulnerabilities for the initial version of the image (block  226 ); and, storing the first scan result in a scan results database (block  227 ). The processor may be adapted to access the scan results database. 
     In certain embodiments, the method may include the step of updating the security vulnerability database with updated CVE information in response to a triggering event (block  228 ). The updated CVE information may be received from an external CVE database. The updated CVE information may comprise information relating to newly identified security vulnerabilities, and/or the latest information relating to the security vulnerabilities that are already stored in a security vulnerability database. The triggering event may be selected from a group consisting of a lapse of a predetermined time interval, and/or a scan request. In some embodiments, the method may include the steps of: generating a container based on the initial version of the image (block  229 ); updating the container with security updates (block  230 ); storing the security updates in the security vulnerability database with the corresponding identified security vulnerabilities for the initial version of the image (block  231 ); generating an updated version of the image based on the updated container (block  232 ); and, storing the updated version of the image (block  233 ). The security updates may be configured to remedy the identified security vulnerabilities. The updated container may be stored in the memory. 
     In an embodiment, the container may be automatically generated and updated with security updates when the initial version of the image is extracted and identified. The security vulnerability database may include severity ratings for the identified security vulnerabilities. In an embodiment, the container may be automatically generated and updated with security updates in response to a determination that the severity ratings for at least one of the identified security vulnerabilities for the initial version of the image is high or critical. 
     In yet another embodiment, the method may include the steps of: scanning the updated version of the image for identifiable security vulnerabilities (block  234 ); generating a second scan result listing the identified security vulnerabilities for the updated version of the image (block  235 ); and, storing the second scan result in a scan results database (block  236 ). Further, the method may include the steps of: comparing the security vulnerabilities identified for the initial version of the image with the security vulnerabilities identified for the updated version of the image (block  237 ); generating vulnerability comparisons based on the compared security vulnerabilities (block  238 ); and, storing the vulnerability comparisons (block  239 ). 
     A second action may be said to be “in response to” a first action independent of whether the second action results directly or indirectly from the first action. The second action may occur at a substantially later time than the first action and still be in response to the first action. Similarly, the second action may be said to be in response to the first action even if intervening actions take place between the first action and the second action, and even if one or more of the intervening actions directly cause the second action to be performed. For example, a second action may be in response to a first action if the first action includes setting a Boolean variable to true and the second action is initiated if the Boolean variable is true. 
     While the present disclosure has been particularly shown and described with reference to an embodiment thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present disclosure. Although some of the drawings illustrate a number of operations in a particular order, operations that are not order-dependent may be reordered and other operations may be combined or broken out. While some reordering or other groupings are specifically mentioned, others will be apparent to those of ordinary skill in the art and so do not present an exhaustive list of alternatives.