Creating a patched artifact by back-propagating a fix using an automated process
In some implementations, a server determines that project code in a development system references an older version of a component in a third-party library and that a newer version of the component has a fix commit that addresses a vulnerability in the older version. The system determines a subset of code changes associated with the fix commit that addresses the vulnerability. The system submits, via a network, a pull request to create a branch in a developer platform. In the branch: a patch is created based on the subset of the code changes associated with the fix commit, the patch is applied to the older version of the component to create a patched component, and after the patch is successfully validated in the branch, the patched component and information associated with the patch is uploaded to a registry to enable a software developer to download and use the patched component.
1 . A computer-implemented method comprising:
determining, by one or more processors, that project code in a development system references an older version of a component in a third-party library;
determining, by the one or more processors, that a newer version of the component in the third-party library has a fix commit that addresses a vulnerability in the older version of the component;
determining, by the one or more processors, a subset of code changes associated with the fix commit that addresses the vulnerability in the older version of the component;
submitting, by the one or more processors and via a communication network, a pull request to create a branch in a developer platform;
creating, in the branch and by the one or more processors, a patch based on the subset of the code changes associated with the fix commit;
applying, in the branch and by the one or more processors, the patch to the older version of the component to create a patched component;
validating, in the branch and by the one or more processors, the patch;
after successfully validating the patch in the branch, uploading, by the one or more processors, the patched component and information associated with the patch to a registry to enable a software developer to download and use the patched component; and providing sufficient details in the information associated with the patch to enable the software developer to reproducibly build the patch.
2 . The computer-implemented method of claim 1 , wherein validating the patch by the one or more processors comprises: executing a set of test cases on a first build that includes the older version of the component to create first test results; determining that the first test results indicate that the set of test cases exploited the vulnerability in the older version of the component; executing the set of test cases on a second build that includes the patched component to create second test results; and determining that the second test results indicate that the set of test cases did not exploit the vulnerability in the patched component.
3 . The computer-implemented method of claim 2 , further comprising: initiating a process to create the first build using a build file comprising build rules and build options; based on the process to create the first build failing, modifying the build file to create a modified build file; and re-initiating the process to create the first build using the modified build file.
4 . The computer-implemented method of claim 1 , wherein validating the patch comprises: executing a set of test cases on a first build that includes the older version of the component to create first test results; determining that the first test results indicate that the set of test cases exploited the vulnerability in the older version of the component; executing the set of test cases on a second build that includes the patched component to create second test results; determining that the second test results indicate that the set of test cases exploited the vulnerability in the patched component; modifying the patch to create a modified patch; executing the set of test cases on a third build that includes the modified patch to create third test results; and determining that the third test results indicate that the set of test cases did not exploit the vulnerability in the modified patch.
5 . The computer-implemented method of claim 1 , further comprising: performing change impact analysis on the patched component; and determining, based on the change impact analysis, that the patched component does not introduce a breaking change.
6 . The computer-implemented method of claim 1 , wherein the information associated with the patch comprises: information identifying the older version of the component in the third-party library; information identifying the vulnerability; information identifying files used; information related to a build file; information related to build options; one or more configuration details; or any combination thereof.
7 . The computer-implemented method of claim 1 , further comprising: performing change impact analysis on the patched component; determining, based on the change impact analysis, that the patch introduces a breaking change; modifying the patch to create a modified patch; and performing the change impact analysis using the modified patch.
8 . A server comprising:
one or more processors; and
one or more non-transitory computer readable media storing instructions executable by the one or more processors to perform operations comprising:
determining that project code in a development system references an older version of a component in a third-party library;
determining that a newer version of the component in the third-party library has a fix commit that addresses a vulnerability in the older version of the component;
determining a subset of code changes associated with the fix commit that addresses the vulnerability in the older version of the component;
submitting, via a communication network, a pull request to create a branch in a developer platform;
creating, in the branch, a patch based on the subset of the code changes associated with the fix commit;
applying, in the branch, the patch to the older version of the component to create a patched component;
validating, in the branch, the patch;
after successfully validating the patch in the branch, uploading the patched component and information associated with the patch to a registry to enable a software developer to download and use the patched component; and
providing sufficient details in the information associated with the patch to enable the software developer to reproducibly build the patch.
9 . The server of claim 8 , wherein validating the patch comprises: executing a set of test cases on a first build that includes the older version of the component to create first test results; determining that the first test results indicate that the set of test cases exploited the vulnerability in the older version of the component; executing the set of test cases on a second build that includes the patched component to create second test results; and determining that the second test results indicate that the set of test cases did not exploit the vulnerability in the patched component.
10 . The server of claim 9 , the operations further comprising: initiating a process to create the first build using a build file comprising build rules and build options; based on the process to create the first build failing, modifying the build file to create a modified build file; and re-initiating the process to create the first build using the modified build file.
11 . The server of claim 8 , the operations further comprising:
performing change impact analysis on the patched component; and
determining, based on the change impact analysis, that the patched component does not introduce a breaking change.
12 . The server of claim 8 , wherein validating the patch comprises: executing a set of test cases on a first build that includes the older version of the component to create first test results; determining that the first test results indicate that the set of test cases exploited the vulnerability in the older version of the component; executing the set of test cases on a second build that includes the patched component to create second test results; determining that the second test results indicate that the set of test cases exploited the vulnerability in the patched component; modifying the patch to create a modified patch; executing the set of test cases on a third build that includes the modified patch to create third test results; and determining that the third test results indicate that the set of test cases did not exploit the vulnerability in the modified patch.
13 . The server of claim 8 , wherein the information associated with the patch comprises: information identifying the older version of the component in the third-party library; information identifying the vulnerability; information identifying files used; information related to a build file; information related to one or more build options; one or more configuration details; or any combination thereof.
14 . The server of claim 8 , the operations further comprising: performing change impact analysis on the patched component; determining, based on the change impact analysis, that the patch introduces a breaking change; modifying the patch to create a modified patch; and performing the change impact analysis using the modified patch.
15 . One or more non-transitory computer readable media capable of storing instructions executable by one or more processors to perform operations comprising:
determining that project code in a development system references an older version of a component in a third-party library;
determining that a newer version of the component in the third-party library has a fix commit that addresses a vulnerability in the older version of the component;
determining a subset of code changes associated with the fix commit that addresses the vulnerability in the older version of the component;
submitting, via a communication network, a pull request to create a branch in a developer platform;
creating, in the branch, a patch based on the subset of the code changes associated with the fix commit;
applying, in the branch, the patch to the older version of the component to create a patched component;
validating, in the branch, the patch;
after successfully validating the patch in the branch, uploading the patched component and information associated with the patch to a registry to enable a software developer to download and use the patched component; and
providing sufficient details in the information associated with the patch to enable the software developer to reproducibly build the patch.
16 . The one or more non-transitory computer readable media of claim 15 , wherein validating the patch comprises: executing a set of test cases on a first build that includes the older version of the component to create first test results; determining that the first test results indicate that the set of test cases exploited the vulnerability in the older version of the component; executing the set of test cases on a second build that includes the patched component to create second test results; and determining that the second test results indicate that the set of test cases did not exploit the vulnerability in the patched component.
17 . The one or more non-transitory computer readable media of claim 16 , the operations further comprising: initiating a process to create the first build using a build file comprising build rules and build options; based on the process to create the first build failing, modifying the build file to create a modified build file; and re-initiating the process to create the first build using the modified build file.
18 . The one or more non-transitory computer readable media of claim 15 , wherein validating the patch comprises: executing a set of test cases on a first build that includes the older version of the component to create first test results; determining that the first test results indicate that the set of test cases exploited the vulnerability in the older version of the component; executing the set of test cases on a second build that includes the patched component to create second test results; determining that the second test results indicate that the set of test cases exploited the vulnerability in the patched component; modifying the patch to create a modified patch; executing the set of test cases on a third build that includes the modified patch to create third test results; and determining that the third test results indicate that the set of test cases did not exploit the vulnerability in the modified patch.
19 . The one or more non-transitory computer readable media of claim 15 , the operations further comprising:
performing a change impact analysis on the patched component;
determining, based on the change impact analysis, whether the patch introduces a breaking change; and
in response to determining that the patch introduces a breaking change, modifying the patch to create a modified patch and performing the change impact analysis using the modified patch.
20 . The one or more non-transitory computer readable media of claim 15 , wherein the information associated with the patch comprises: information identifying the older version of the component in the third-party library; information identifying the vulnerability; information identifying files used; information related to a build file; information related to build options; one or more configuration details; or any combination thereof.