VERIFICATION OF A PUBLISHED IMAGE HAVING A PREDEFINED PORTION THAT HAS BEEN ALTERED BY A CLOUD PROVIDER PRIOR TO BEING MADE AVAILABLE VIA A MARKETPLACE OF THE CLOUD PROVIDER

Systems and methods for verifying an executable portion of a published cloud image represents an unaltered version of an executable portion of a corresponding original cloud image are provided. In one embodiment, modification of a predefined portion of a cloud image by a cloud provider prior to its publication via a marketplace of the cloud provider is proactively addressed as part of (i) an automated signing process performed by a software publisher on the original cloud image prior to delivery to the cloud provider and (ii) a corresponding background verification process performed on the published cloud image on behalf of users by a management platform. The signing and verification processes are operable to exclude the predefined portion when creating their respective digests, thereby allowing the signed digest created prior to the modification to remain useful as part of a subsequent digest comparison performed by the verification process.

BACKGROUND

Field

Various embodiments of the present disclosure generally relate to automated means for enhancing software supply chain security and prevention of cyber incidents. In particular, some embodiments relate to facilitating the verification of an image file of a software product published to a marketplace of a cloud provider in which alterations are made by the cloud provider to a predefined portion of the image file prior to publication thereof.

Description of the Related Art

Cloud provider marketplaces (e.g., Microsoft Azure marketplace, Google Cloud Platform (GCP) marketplace, and Amazon Web Services (AWS) marketplace) provide customers (users) with access to software applications and/or services (which may be collectively referred to herein as software products) that may be built on, integrate with, or complement the cloud provider's offerings. Such software products may include native cloud applications (e.g., NetApp Cloud Volumes ONTAP by NetApp, Inc. of San Jose, CA) and approved apps that have been created by third-party developers (or software publishers).

Prior to delivering a cloud image to a cloud marketplace for publication, a software publisher may create a signed digest (or signature) of the cloud image using a private key of the software publisher, thereby allowing a user that obtains the published version of the cloud image from the cloud marketplace to verify the published cloud image represents an unaltered version of the original cloud image created by the software publisher. For example, the user may compare a first digest extracted from the signed digest using a corresponding public key of the software publisher to a second digest of the published cloud image.

SUMMARY

Systems and methods are described for verifying an executable portion of a published cloud image file represents an unaltered version of an executable portion of a corresponding original cloud image file. According to one embodiment, a signed digest associated with the original cloud image file of a software product of a software publisher may be downloaded from the software publisher. The original cloud image file includes an executable portion and a non-executable portion. The signed digest is created by excluding the non-executable portion. A published version of the software product may be downloaded in a form of the published cloud image file from a marketplace of a cloud provider. The published cloud image file includes an executable portion and a non-executable portion. The non-executable portion of the published cloud image file is modified by the cloud provider during staging and/or publication of the published version of the software product to the marketplace. The executable portion of the published cloud image file is verified to represent an unaltered version of the executable portion of the original cloud image file by: (i) extracting a first digest from the signed digest by using a public key of the software publisher; and (ii) creating a second digest of the published image file by excluding the non-executable portion of the published cloud image file; and (iii) comparing the first digest to the second digest.

Other features of embodiments of the present disclosure will be apparent from accompanying drawings and detailed description that follows.

DETAILED DESCRIPTION

Systems and methods are described for verifying an executable portion of a published cloud image file represents an unaltered version of an executable portion of a corresponding original cloud image file. Executive Order (EO) 14028, “Improving the Nation's Cybersecurity” and subsequently released recommended practice guides associated therewith published by the Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency, and the Office of the Director of National Intelligence (ODNI) provide examples of threat scenarios and recommended mitigations. EO 14028 and the subsequently released recommended practice guides may be collectively referred to as EO 14028 herein. An example of a recommended mitigation by EO 14028 is “[d]eliver digitally signed code and associated supporting files using a code-signing system that protects sensitive signing keys and that uses hardware protection such as a Federal Information Processing Standards (FIPS) 140-2/-3 Hardware Security Module (HSM).”

While both signing and verification of a cloud image file is conceptually fairly straightforward when the cloud provider does not make any alterations to the original cloud image file prior to publication to the cloud marketplace, there are situations in which a cloud provider may have a need to modify a defined non-executable portion (e.g., metadata contained in a header, footer, leading portion, or trailing portion) of the cloud image file, for example, for accounting and/or self-protection purposes. Such an alteration, however, destroys the ability of the pre-modification signed digest to be used in connection with verifying the published cloud image.

As such, embodiments described herein seek to improve the technological processes of image signing and verification to proactively address the modification of a predefined portion of a cloud image by a cloud provider prior to the cloud provider making the cloud image available for consumption by users via a marketplace of the cloud provider. Various embodiments of the present technology provide a range of technical effects, advantages, and/or improvements to image signing and verification. For example, by proactively excluding the predefined portion from a pre-publication signing process performed on an original cloud image file and correspondingly excluding the predefined portion from a post marketplace acquisition verification process performed on the published cloud image, the usefulness of a first digest extracted from the signed digest produced by the pre-publication signing process and a second digest generated based on the published cloud image as part of a digest comparison performed by the verification process is retained despite the modification. Additionally, by periodically performing an automated and scheduled image verification process in the background by a management platform, the efficiency of deploying the software product may be enhanced by hiding the latency of various asynchronous processes, including, for example, the downloading of multi-GB published cloud image files.

While various examples herein are described with reference to a cloud image file that includes a predefined portion that may be altered by a cloud provider during staging and/or publication to a marketplace of the cloud provider, it is to be appreciated the methodologies described herein are also applicable to scenarios in which the cloud image file has multiple predefined portions that may be altered by cloud provider.

In the following description, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, to one skilled in the art that embodiments of the present disclosure may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form.

Terminology

A “computer” or “computer system” may be one or more physical computers, virtual computers, or computing devices. As an example, a computer may be one or more server computers, cloud-based computers, cloud-based cluster of computers, virtual machine instances or virtual machine computing elements such as virtual processors, storage and memory, data centers, storage devices, desktop computers, laptop computers, mobile devices, or any other special-purpose computing devices. Any reference to “a computer” or “a computer system” herein may mean one or more computers, unless expressly stated otherwise.

As used herein a “cloud” or “cloud environment” broadly and generally refers to a platform through which cloud computing may be delivered via a public network (e.g., the Internet) and/or a private network. The National Institute of Standards and Technology (NIST) defines cloud computing as “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.” P. Mell, T. Grance, The NIST Definition of Cloud Computing, National Institute of Standards and Technology, USA, 2011. The infrastructure of a cloud may be deployed in accordance with various deployment models, including private cloud, community cloud, public cloud, and hybrid cloud. In the private cloud deployment model, the cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units), may be owned, managed, and operated by the organization, a third party, or some combination of them, and may exist on or off premises. In the community cloud deployment model, the cloud infrastructure is provisioned for exclusive use by a specific community of consumers from organizations that have shared concerns (e.g., mission, security requirements, policy, and compliance considerations), may be owned, managed, and operated by one or more of the organizations in the community, a third party, or some combination of them, and may exist on or off premises. In the public cloud deployment model, the cloud infrastructure is provisioned for open use by the general public, may be owned, managed, and operated by a cloud provider (e.g., a business, academic, or government organization, or some combination of them), and exists on the premises of the cloud provider. The cloud service provider may offer a cloud-based platform, infrastructure, application, or storage services as-a-service, in accordance with a number of service models, including Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and/or Infrastructure-as-a-Service (IaaS). In the hybrid cloud deployment model, the cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community, or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability and mobility (e.g., cloud bursting for load balancing between clouds).

As used herein, a “cloud service provider” or a “cloud provider” generally refers to the owner, manager, and/or operator of a cloud or cloud platform. A cloud provider may be a business, academic, or government organization, or some combination of them. Non-limiting examples of clouds or cloud platforms and their respective cloud providers include Azure provided by Microsoft, Google Cloud Platform (GCP) provided by Google, Amazon Web Services (AWS) provided by Amazon, Oracle Cloud Infrastructure provided by Oracle, and IBM Cloud provided by IBM.

Example Signing Process

FIG.1Ais a block diagram conceptually illustrating a signing process120. The signing process120may be used to generate a signed digest111(or a signature) of the input data (e.g., original data110). In various examples described herein the input data comprises an original cloud image file built by a software publisher and representing a software product of the software publisher. In order to comply with the recommended mitigations of EO 14028, a software producer may create a signed digest111for each version of a software product that will be published to a cloud marketplace, thereby allowing users that obtain the published version of the software product from the cloud marketplace to verify that the published cloud image file represents an unaltered version of the original cloud image file.

In the context of the present example, the signing process120includes a hash function125(e.g., a message-digest (MD) algorithm or a cryptographic hash algorithm). The hash function125generally represents a one-way hashing procedure that maps input data (e.g., original data110) of an arbitrary length to an output (e.g., a digest, a hash value, or a checksum) of fixed length. The hash function125is designed to protect the integrity of the input data to detect changes or alterations to any part of the input data. Applying the hash function125to the same input data will always result in the same output. Similarly, if the input data is modified, the output of the hash function125is different. Non-limiting examples of the hash function125include the MD5 message-digest algorithm, the MD6 message-digest algorithm, secure hash algorithm 2 (SHA-2), SHA-3, BLAKE3 and SHA-256.

A private key (also known as a secret key of a public key pair) represents a variable in asymmetric (public key) cryptography that may be used with an algorithm (not shown) to encrypt data. In the context of the present example, the owner (e.g., a software publisher) of a public key pair uses their private key to generate the signed digest111by encrypting the digest with the private key. As described further below with reference toFIG.1B, anyone with access to the public key of the public key pair can decrypt the signed digest111.

As described further below, in order to accommodate the alteration of a predetermined portion (e.g., leading or trailing metadata) of the original data (e.g., an original cloud image file) by the cloud provider as the cloud image file is staged and/or published to a marketplace of the cloud provider, the input to the signing process may be modified to exclude the predetermined portion.

Example Verification Process

FIG.1Bis a block diagram conceptually illustrating a verification process130corresponding to the signing process120ofFIG.1A. The verification process130operates on two pieces of data (i.e., received data (e.g., received data140) and the signed digest111associated with the original data) and outputs a verification result indicative of whether the received data represents an unaltered version of the original data (e.g., original data110). In the context of a software distribution chain in which a cloud provider distributes a software product of a software publisher via a marketplace of the cloud provider, the verification process130may be used to verify a published version of the software product in the form of a published cloud image file represents an unaltered version of an original cloud image file representing the software product and built by the software publisher. That is, the verification process130may be used to verify no alterations were made to the cloud image file after the time it was delivered to the cloud provider.

The verification process130makes use of the same hash function (e.g., hash function125) as employed by the signing process (e.g., signing process120). A first digest may be extracted by decrypting the signed digest111with the public key corresponding to the private key used to generate the signed digest111. As described further below, the public key may be included within a public key certificate and may be obtained from the software publisher. A second digest may be generated by applying the hash function125to the received data. The verification process130may then compare the first digest to the second digest to produce the verification result. When the first and second digests match, this indicates the content of the received data and the original data are the same and the verification result is true. When the first and second digests do not match, this indicates the content of the received data and the original data are different and the verification result is false.

The verification process130may be performed by the user or on behalf of the user. As described further below, in one embodiment, the verification process130may be performed in the background by automated means in accordance with a schedule by a management platform that facilitates setting up and deploying the software product on one or more compute instances provided by the cloud provider.

As described further below, in order to accommodate the post-signing alteration of a predetermined portion (e.g., leading or trailing metadata) of the original data (e.g., an original cloud image file) by the cloud provider, resulting in a published cloud image file differing from the original cloud image file), the input to the verification process may be modified to exclude the predetermined portion.

Example Cloud Image Files

FIG.2is a block diagram illustrating an example of an original cloud image210and a published cloud image240in accordance with an embodiment of the present disclosure. A cloud provider may have a desire to modify a defined non-executable portion (e.g., metadata contained in a header, footer, leading portion, or trailing portion) of the published cloud image240, for example, for accounting and/or self-protection purposes. As those skilled in the art will appreciate, when such an alteration is performed after a software publisher has created a signed digest (e.g., signed digest111) for the original cloud image210(which may be analogous to original data110), it precludes effective usage of the traditional approach (e.g., verification process130) for verifying the published cloud image240(which may be analogous to received data140) represents an unaltered version of the original cloud image210.

In the context of the present example, the original cloud image210includes a predetermined portion (e.g., a non-executable portion211, which may represent metadata) of X megabytes (MB) and an executable portion212of Y gigabytes (GB). The original cloud image210may represent a cloud image file built by a software publisher and representing a software product of the software publisher that is to be distributed to users via a marketplace of a cloud provider. Similarly, the published cloud image240includes a predetermined portion (e.g., a non-executable portion241, which may represent metadata) of X megabytes (MB) and an executable portion242of Y gigabytes (GB). The published cloud image210may represent a copy of the cloud image210in which the non-executable portion241has been altered by the cloud provider during staging or publication to the marketplace of the cloud provider. Depending on the cloud marketplace through which the software product is to be distributed to users, the original cloud image210and the published cloud image240may represent Virtual Hard Disk (VHD) files, Amazon Machine image (AMI) files, raw disk images (e.g., files having a .raw extension, which may be referred to herein as “RAW files”), or other current or future formats that may be used for virtual hard disks.

In order to accommodate alteration of the non-executable portion241of the published cloud image240, according to one embodiment, the input to the signing process (e.g., signing process120) and the input to the verification process may exclude the respective non-executable portions211and241of the original cloud image210and the published cloud image240. For example, the original cloud image210may be truncated to remove the non-executable portion211from the original cloud image210or the non-executable portion211may otherwise be stripped from the original cloud image210by the software publisher before invoking the signing process (e.g., signing process120). In this manner, the original data110input to the signing process excludes the non-executable portion211, thereby causing the predefined portion of the original cloud image210(which will differ from the predefined portion of the published cloud image240as a result of one or more alteration(s) made by the cloud provider) to be ignored for purposes of generating the signed digest111. Similarly, the published cloud image240may be truncated to remove the non-executable portion241from the published cloud image240or the non-executable portion241may otherwise be stripped from the published cloud image240by the software publisher before invoking the verification process. In this manner, the received data140input to the verification process excludes the non-executable portion241, thereby causing the predefined portion of the published cloud image240that is altered by the cloud provider to be ignored for purposes of generating the second digest, which is compared to the first digest to determine the verification result.

While in the present example the predefined portion of the published cloud image240that is altered by the cloud provider during staging and/or publication to the marketplace of the cloud provider is assumed to be the leading X MB, it is to be appreciated the approach described herein is applicable regardless of the location of the non-executable portions211and241within the respective cloud images210and240. For example, the non-executable portions211and241may be located at the end of the respective cloud images210and240or may be located at a predetermined byte offset from the beginning or the end of the respective cloud images210and240. Similarly, while in the context of the present example, it is assumed there is only one predefined portion of the published cloud image240that is altered, it is contemplated that more than one predefined portion of the published cloud image240may be altered.

Example Operating Environment

FIG.3is a block diagram illustrating an operating environment300in which various embodiments of the present disclosure may be employed. In various examples described herein, a software product of a software publisher is assumed to be distributed to users via a marketplace316of a cloud provider310in the form of a published cloud image (e.g., published cloud image240), which represents a copy of an original cloud image (e.g., cloud image210) provided by the software publisher but including one or more alterations made by the cloud provider to a predefined portion (e.g., non-executable portion241) of the published cloud image.

In the context of the present example, the operating environment300includes a software publisher environment320, a cloud provider310, and a user environment330. The cloud environment of the cloud provider310may include a software publisher account322, a management platform312, compute instance(s)314, a marketplace316, and a user account332. The marketplace316generally represents an online storefront that is operated by the cloud provider310, through which users (customers) may find, buy, and use, among other things, Software as a Service (SaaS) applications, research datasets, and software and services that may be deployed and run in the cloud environment, for example, on virtual machines (VMs) or containers hosted by one or more of the compute instance(s)314. For example, the marketplace316may provide users with access to a software-defined storage offering (e.g., NetApp Cloud Volumes ONTAP (CVO)) developed by a third party (e.g., NetApp, Inc. of San Jose, CA) that delivers advanced data management for file and block workloads.

The management platform316may represent a cloud-based platform (provided by the same or a different software publisher as the software product) through which a user has the ability to set up and deploy the software product on the one or more compute instance(s)314provided by the cloud provider310. In the background and in accordance with a predetermined or configurable schedule, the management platform316may periodically download all versions of the software product supported by the management platform316and for each version perform the verification process to verify whether the executable portion of the published cloud image represents an unaltered version of the executable portion of the original cloud image. The result of the verification process may be presented within a user interface of the management platform316, for example, as shown and described in connection withFIG.5. According to one embodiment, the management platform312represents an enterprise-class, SaaS-based management platform (e.g., BlueXP available from NetApp, Inc. of San Jose, CA) that enables users (e.g., Information Technology (IT) experts and cloud architects) to centrally manage their hybrid multi-cloud infrastructure using the software product.

The software publisher account322generally represents an account maintained by the software publisher with the cloud provider310. For example, the software publisher account322may represent a commercial marketplace account of the software publisher that is enrolled in any relevant commercial marketplace program so as to enable the software publisher to publish the software product in the form of a cloud image via the marketplace316.

The user account332generally represents an account maintained by a user or organization with the cloud provider310. The user account332is typically associated with a subscription (e.g., an agreement between the user or organization and the cloud provider310to use resources, for which charges are either paid on a per-license basis or a cloud-based, resource-consumption basis) that links to the user account.

The software publisher environment320may represent a combination of on-premise resources and cloud-based resources and is shown including a build server324, a Hardware Security Module (HSM) System326, the software publisher account322, and a software publisher support site328. The HSM system326may represent a hardened, tamper-resistant hardware device that is responsible for generating public key pairs, securely storing private keys of the software publisher, and generating signed digests of cloud images on behalf of the build server324by performing a signing process (e.g., signing process120).

The build server324(e.g., a continuous integration server, such as a Jenkins automation server) may be responsible for creating cloud image files based on source code committed to a repository and associated with various versions of a software product that are to be publicly released. For example, prior to uploading a cloud image to the software publisher account322, the build server324may request a signed digest be generated by the HSM system326for a given cloud image by providing the HSM system326with the given cloud image and a reference to the private key to be used to create the signed digest. The build server324may then push the signed digest, a public key certificate (containing the public key corresponding to the private key used to create the signed digest) and a certificate chain to the software publisher support site328.

Given the differing cloud image file formats used by respective cloud providers, an original cloud image file for a given version of the software product may be created by the software publisher for each cloud provider marketplace. For example, a first version of software product (e.g., NetApp Cloud Volumes ONTAP by NetApp, Inc. of San Jose, CA) may be caused to be published via the Azure marketplace in the form of a virtual hard drive (VHD) file, uploaded to the Azure marketplace via a corresponding software publisher account (e.g., software publisher account322) on Azure, a second version of the software product may be caused to be published via the AWS marketplace via a corresponding software publisher account (e.g., software publisher account322) on AWS, and a third version of the software product may be caused to be published via the GCP marketplace via a corresponding software publisher account (e.g., software publisher account322) on GCP. Additionally, differing public key pairs may be used for each cloud provider or for each version of the software product.

In order to ensure software supply chain security (at least in terms detecting any changes potentially introduced to the executable portion (e.g., executable portion242) of the original cloud image built by the software publisher between delivery to the marketplace316and receipt of the published cloud image by a user), a verification process (e.g., verification process130) should be performed based on a signed digest (e.g., signed digest111) of the original cloud image (excluding the non-executable portion (e.g., non-executable portion211)) created by the software publisher and the published cloud image (excluding the non-executable portion (e.g., non-executable portion241)). The software publisher support site328may be responsible for maintaining a mapping of each version of the software product for each cloud provider to corresponding signed digests, public certificates, and certificate chains and allowing users to retrieve a signed digest, public certificate, and certificate chain for a given version of the software product targeted for a particular cloud provider, thereby facilitating performance of the verification process by or on behalf of the user. For example, the user may perform a manual image verification process (e.g., image verification336) or the management platform312may perform an automated image verification for all versions of the software product it supports in the background in accordance with a predefined or configurable schedule (e.g., every X hours or every Y days).

The user environment330may represent a combination of on-premise resources and cloud-based resources and is shown including the user account332, a user system334, and a manual image verification process336. Through interactions with the marketplace316via the user account332, a user may purchase a software product of a software publisher provided in a form of a published cloud image, which may be stored on the user system334(e.g., a workstation, a personal computer, or a laptop computer). The signed digest, public certificate, and certificate chain corresponding to the version of the software product of the published cloud image may be downloaded to the user system334from the software publisher support site328. Before setting up and deploying the software product, for example, to run on one or more of the compute instance(s)314via the management platform312, the user would typically manually perform the image verification336to verify the published cloud image represents an unaltered version of the original cloud image. This manual verification process has a number of disadvantages. For example, it is somewhat complex and involves a number of steps. In the context of the Azure marketplace, for instance, the user would need to:Create a new manage disk from the marketplace image;Export a VHD from the managed disk to Azure storage (e.g., user account332);Download the generated image to a user system (e.g., user system334);Cleanup the managed disk;Download the signed digest (e.g., signed digest111), the corresponding public key certificate file, and the corresponding chain certificate file from the software publisher support site (e.g., software support site328);Verify the chain of trust;Extract the public key from the public key certificate;Use the extracted public key to decrypt the signed digest to obtain the unencrypted digest (the first digest)Create a new unencrypted digest (the second digest) of a temporary file created from the image file with the predetermined portion (e.g., the leading X MB) removed.Compare the first digest to the second digest, for example, with the following general form of OpenSSL command:

The steps involved may differ based on the file format of the cloud images at issue and the cloud provider at issue, thereby also making the process error prone. Additionally, the multi-GB size of the public cloud image makes this process time consuming potentially with long periods of waiting between various steps. Furthermore, given a predefined portion (e.g., non-executable portion241) of the published cloud image has been altered by the cloud provider310and the software publisher has proactively generated a signed digest for the original cloud image that does not consider the predefined portion, the manual verification process will become more cumbersome.

In view of the foregoing, in one embodiment, a proposed solution involves automating the verification process as described further below with reference toFIG.4. For example, the management platform may periodically perform an automated and scheduled image verification process in the background and display the verification results via a graphical user interface.

Example Automated Verification Process

FIG.4is a flow diagram illustrating a set of operations for verifying a published image file of a software product in accordance with an embodiment of the present disclosure. In the context of the present example, it is assumed a cloud provider (e.g., cloud provider310) alters a predefined portion (e.g., non-executable portion241) of a published image file (e.g., published cloud image240) during staging and/or publication to a marketplace (e.g., marketplace316) of the cloud provider. As a result of the alteration, a predefined portion (e.g., non-executable portion211) of an original image file (e.g., original cloud image210) will differ from the predefined portion of the published image file and a traditional signing process involving the entirety of the original image file followed by a traditional verification process involving the entirety of the published image file will fail despite the content of respective executable portions (e.g., executable portions212and242) matching. It is further assumed, in order to accommodate such alteration of the predefined portion of the published image file by the cloud provider, a software publisher has proactively altered the input to the signing process to exclude the predefined portion.

As such, the verification process described below may be used to specifically verify whether the executable portion (e.g., executable portion242) of the published image file represents an unaltered version of the corresponding executable portion (e.g., executable portion212) of the original image file. In one embodiment, the verification process described with reference toFIG.4may be periodically performed in the background by a management platform (e.g., management platform312)) through which a user has the ability to set up and deploy the software product on one or more compute instances (e.g., compute instance(s)314) of a cloud provider (e.g., cloud provider310).

At block410, a signed digest (e.g., signed digest111) associated with the original image file of a software product of a software publisher is obtained. There are a variety of ways the management platform might obtain the signed digest. For example, the signed digest may be proactively pushed to the management platform from a software publisher environment (e.g., software publisher environment320) as it is provided to a software publisher support site (e.g., software publisher support site328) or the management platform may pull the signed digest from the software publisher support site.

At block420, a published version of the software product in a form of the published image file is downloaded from the cloud provider marketplace. In one embodiment, the management platform may periodically download each version of the software product supported by the management platform in accordance with a predefined or configurable schedule (e.g., every X hours).

At block430, a first digest is extracted from the signed digest using a public key (i.e., the public key corresponding to the private key used to create the signed digest) of the software publisher. For example, the public key may be used to decrypt the signed digest as shown inFIG.1B.

At block440, a second digest of the published image file is created. As noted above, the predefined portion (modified by the cloud provider) of the published image file should be excluded from the process of creating the second digest. Assuming, the predefined portion represents a leading X MB of the published image file, in one embodiment, a temporary file may be created by removing the leading X MB of the published image file. Then, the second digest may be generated by inputting the temporary file to the same hash function (e.g., hash function125) that was used during the signing process to create the digest of the original image file as shown inFIG.1B.

At block450, the first digest is compared to the second digest.

At decision block460, it is determined whether the first digest matches the second digest. If so, processing continues with block470; otherwise, processing branches to block480.

At block470, the verification has been successful (i.e., the executable portion of the published image file has been confirmed to represent an unaltered version of the executable portion of the original image file). In one embodiment, the management platform may store a current timestamp and the verification result for presentation to a user via a graphical user interface of the management platform, thereby allowing the user to avoid performance of a manual process to verify the published image file. A non-limiting example of a screen shot illustrating the presentation of verification results via a user interface of a management platform is described further below with reference toFIG.5.

At block480, the verification has been unsuccessful (i.e., the executable portion of the published image file has been determined to represent an altered version of the executable portion of the original image file). As above, in one embodiment, the management platform may store a current timestamp and the verification result for presentation to a user via a graphical user interface of the management platform, thereby alerting the user of the potential security issue.

While in various examples described herein, it is assumed a cloud provider (e.g., cloud provider310) alters or may alter a predefined portion (e.g., non-executable portion241) of a published image file (e.g., published cloud image240) during staging and/or publication to a marketplace (e.g., marketplace316) of the cloud provider, the methodologies described herein are equally applicable to scenarios in which multiple predefined portions of the published image are altered or alterable by the cloud provider by modifying the signing process and verification process accordingly to exclude consideration of such alterable portions.

While in the context of the present example, a number of enumerated blocks are included, it is to be understood that examples may include additional blocks before, after, and/or in between the enumerated blocks. Similarly, in some examples, one or more of the enumerated blocks may be omitted and/or performed in a different order.

Example Presentation of Verification Results

FIG.5is a screen shot500illustrating presentation of automated and scheduled image verification results via a user interface of a management platform in accordance with an embodiment of the present disclosure. In the context of the present example, a non-limiting example of a user interface of a management platform (e.g., BlueXP available from NetApp, Inc. of San Jose, CA) is shown in which a verification result510of a given software version of a software product (e.g., NetApp Cloud Volumes ONTAP by NetApp, Inc. of San Jose, CA) is presented alongside the given software version, for example, as part of an end user selecting among a number of available software versions of the software product for deployment.

In this example, an automated and scheduled image verification process (e.g., verification process130) is assumed to be performed on a daily basis. As such, the verification result510indicates the date on which the software version at issue was verified. To the extent the automated and scheduled image verification process is performed more frequently, the verification result510may additionally include information indicative of a time at which the verification was completed.

While in this example, only a single verification result is shown, it is to be appreciated a verification result may be presented for each of multiple software versions of the software product.

Example Computer System

Embodiments of the present disclosure include various steps, which have been described above. The steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a processing resource (e.g., a general-purpose or special-purpose processor) programmed with the instructions to perform the steps. Alternatively, depending upon the particular implementation, various steps may be performed by a combination of hardware, software, firmware and/or by human operators.

Various methods described herein may be practiced by combining one or more non-transitory machine-readable storage media containing the code according to embodiments of the present disclosure with appropriate special purpose or standard computer hardware to execute the code contained therein. An apparatus for practicing various embodiments of the present disclosure may involve one or more computers (e.g., physical and/or virtual servers) (or one or more processors within a single computer) and storage systems containing or having network access to computer program(s) coded in accordance with various methods described herein, and the method steps associated with embodiments of the present disclosure may be accomplished by modules, routines, subroutines, or subparts of a computer program product.

FIG.6is a block diagram that illustrates a computer system600in which or with which an embodiment of the present disclosure may be implemented. Computer system600may be representative of all or a portion of the computing resources associated with a cloud environment of a cloud provider (e.g., cloud provider310) and/or a computer system associated with a software publisher environment (e.g., software publisher environment320) or a user environment (e.g., user environment330). Notably, components of computer system600described herein are meant only to exemplify various possibilities. In no way should example computer system600limit the scope of the present disclosure. In the context of the present example, computer system600includes a bus602or other communication mechanism for communicating information, and a processing resource (e.g., a hardware processor604) coupled with bus602for processing information. Hardware processor604may be, for example, a general purpose microprocessor.

Computer system600further includes a read only memory (ROM)608or other static storage device coupled to bus602for storing static information and instructions for processor604. A storage device610, e.g., a magnetic disk, optical disk or flash disk (made of flash memory chips), is provided and coupled to bus602for storing information and instructions.

Computer system600may be coupled via bus602to a display612, e.g., a cathode ray tube (CRT), Liquid Crystal Display (LCD), Organic Light-Emitting Diode Display (OLED), Digital Light Processing Display (DLP) or the like, for displaying information to a computer user. An input device614, including alphanumeric and other keys, is coupled to bus602for communicating information and command selections to processor604. Another type of user input device is cursor control616, such as a mouse, a trackball, a trackpad, or cursor direction keys for communicating direction information and command selections to processor604and for controlling cursor movement on display612. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

Removable storage media640can be any kind of external storage media, including, but not limited to, hard-drives, floppy drives, IOMEGA® Zip Drives, Compact Disc-Read Only Memory (CD-ROM), Compact Disc-Re-Writable (CD-RW), Digital Video Disk-Read Only Memory (DVD-ROM), USB flash drives and the like.

The term “storage media” as used herein refers to any non-transitory media that store data or instructions that cause a machine to operation in a specific fashion. Such storage media may comprise non-volatile media or volatile media. Non-volatile media includes, for example, optical, magnetic or flash disks, such as storage device610. Volatile media includes dynamic memory, such as main memory606. Common forms of storage media include, for example, a flexible disk, a hard disk, a solid state drive, a magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge.

Computer system600can send messages and receive data, including program code, through the network(s), network link620and communication interface618. In the Internet example, a server630might transmit a requested code for an application program through Internet628, ISP626, local network622and communication interface618. The received code may be executed by processor604as it is received, or stored in storage device610, or other non-volatile storage for later execution.

All examples and illustrative references are non-limiting and should not be used to limit the applicability of the proposed approach to specific implementations and examples described herein and their equivalents. For simplicity, reference numbers may be repeated between various examples. This repetition is for clarity only and does not dictate a relationship between the respective examples. Finally, in view of this disclosure, particular features described in relation to one aspect or example may be applied to other disclosed aspects or examples of the disclosure, even though not specifically shown in the drawings or described in the text.

The foregoing outlines features of several examples so that those skilled in the art may better understand the aspects of the present disclosure. Those skilled in the art should appreciate that they may readily use the present disclosure as a basis for designing or modifying other processes and structures for carrying out the same purposes and/or achieving the same advantages of the examples introduced herein. Those skilled in the art should also realize that such equivalent constructions do not depart from the spirit and scope of the present disclosure, and that they may make various changes, substitutions, and alterations herein without departing from the spirit and scope of the present disclosure.