Determining a minimum number of changes to make to an older version based on subsequent fix commit(s)
In some implementations, a computing device determines that project code in a development system references an older version of a component in a third-party library, determines that the older version of the component has a vulnerability, determines that a newer version of the component in the third-party library addresses the vulnerability, determines code changes associated with the fix commit, determines a subset of the code changes associated with the fix commit that addresses the vulnerability, creates a patch based on the subset of the code changes associated with the fix commit, and applies the patch to the older version of the component to create a patched component. The subset of the code changes is determined by identifying a minimum amount of code that addresses the vulnerability and provides support for the fix commit.
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 the older version of the component has a vulnerability;
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 the vulnerability;
determining, by the one or more processors, code changes associated with the fix commit;
determining, by the one or more processors, a subset of the code changes associated with the fix commit that addresses the vulnerability in the older version of the component, by:
determining a fix commit history associated with the component in the third-party library;
determining, based on the fix commit history, a set of fix commits that address the vulnerability;
ordering the set of fix commits, based on a commit date associated with individual fix commits in the set of fix commits, to create an ordered set of fix commits;
determining file specific changes associated with individual fix commits in the ordered set of fix commits; and
based on determining that the file specific changes can be successfully applied to the project code, including the file specific changes in the subset of the code changes;
creating, by the one or more processors, a patch based on the subset of the code changes associated with the fix commit;
applying, by the one or more processors, the patch to the older version of the component to create a patched component;
validating the patch by the one or more processors; and
based on successfully validating the patch, 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.
2 . 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 .
3 . The computer-implemented method of claim 1 , wherein the file specific changes comprise: a context; one or more deleted lines; one or more added lines; or any combination thereof.
4 . The computer-implemented method of claim 1 , further comprising: based on determining that the file specific changes cannot be successfully applied to the project code, determining additional commits in the fix commit history that touch a particular file associated with the file specific changes; ordering the additional fix commits, based on the commit date, to create an ordered set of additional fix commits; determining additional file specific changes associated with individual fix commits in the ordered set of additional fix commits; and based on determining that the file specific changes can be successfully applied to the project code, including the file specific changes in the subset of the code changes.
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 , further comprising: submitting a pull request to create a branch in a developer platform.
7 . The computer-implemented method of claim 6 , wherein: creating the patch based on the subset of the code changes associated with the fix commit is performed in the branch; applying the patch to the older version of the component to create the patched component is performed in the branch; and validating the patch is performed in the branch.
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 the older version of the component has a vulnerability;
determining that a newer version of the component in the third-party library has a fix commit that addresses the vulnerability;
determining code changes associated with the fix commit;
determining a subset of the code changes associated with the fix commit that addresses the vulnerability in the older version of the component by:
determining a fix commit history associated with the component in the third-party library;
determining, based on the fix commit history, a set of fix commits that address the vulnerability;
ordering the set of fix commits, based on a commit date associated with individual fix commits in the set of fix commits, to create an ordered set of fix commits;
determining file specific changes associated with individual fix commits in the ordered set of fix commits; and
based on determining that the file specific changes can be successfully applied to the project code, including the file specific changes in the subset of the code changes;
creating a patch based on the subset of the code changes associated with the fix commit;
applying the patch to the older version of the component to create a patched component;
validating the patch; and
based on successfully validating the patch, building and 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.
9 . The server of claim 8 , the operations further comprising:
submitting a pull request to create a branch in a developer platform:
creating, in the branch, the 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 the patched component; and
validating, in the branch, the patch .
10 . The server of claim 8 , wherein the file specific changes comprise: a context; one or more deleted lines; one or more added lines; or any combination thereof.
11 . The server of claim 8 , the operations further comprising: based on determining that the file specific changes cannot be successfully applied to the project code, determining additional commits in the fix commit history that touch a particular file associated with the file specific changes; ordering the additional fix commits, based on the commit date, to create an ordered set of additional fix commits; determining additional file specific changes associated with individual fix commits in the ordered set of additional fix commits and based on determining that the file specific changes can be successfully applied to the project code, including the file specific changes in the subset of the code changes.
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 one or more files that are 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 the older version of the component has a vulnerability;
determining that a newer version of the component in the third-party library has a fix commit that addresses the vulnerability;
determining code changes associated with the fix commit;
determining a subset of the code changes associated with the fix commit that addresses the vulnerability in the older version of the component by:
determining a fix commit history associated with the component in the third-party library;
determining, based on the fix commit history, a set of fix commits that address the vulnerability;
ordering the set of fix commits, based on a commit date associated with individual fix commits in the set of fix commits, to create an ordered set of fix commits;
determining file specific changes associated with individual fix commits in the ordered set of fix commits; and
based on determining that the file specific changes can be successfully applied to the project code, including the file specific changes in the subset of the code changes;
creating a patch based on the subset of the code changes associated with the fix commit;
applying the patch to the older version of the component to create a patched component;
validating the patch; and
based on successfully validating the patch, building and 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.
16 . The one or more non-transitory computer readable media of claim 15 , 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 .
17 . The one or more non-transitory computer readable media of claim 15 , wherein the file specific changes comprise: a context; one or more deleted lines; one or more added lines; or any combination thereof.
18 . The one or more non-transitory computer readable media of claim 15 , the operations further comprising: based on determining that the file specific changes cannot be successfully applied to the project code, determining additional commits in the fix commit history that touch a particular file associated with the file specific changes; ordering the additional fix commits, based on the commit date, to create an ordered set of additional fix commits; determining additional file specific changes associated with individual fix commits in the ordered set of additional fix commits; and based on determining that the file specific changes can be successfully applied to the project code, including the file specific changes in the subset of the code changes.
19 . The one or more non-transitory computer readable media of claim 15 , 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.
20 . The one or more non-transitory computer readable media of claim 15 , the operations further comprising: submitting a pull request to create a branch in a developer platform; creating, in the branch, the 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 the patched component; and validating, in the branch, the patch.