Mixing
The best way to resolve vulnerabilities in package-lock.json?
I am warned about vulnerabilities in the packages listed in the package-lock.json file of my Node.Js project.
I can follow the advice here and reinstall all the packages with npm install <package-name>, however, I also use other npm projects that use the older versions of those packages, which will not get reinstalled with a simple npm install.
Does it mean I have to go to package-lock.json and manually change all the dependencies to the latest version?
What if they break?
Isn't there a proper way of doing the updates that ensures you won't break the other packages dependent on the old versions?
javascript node.js security package-lock.json
asked Jan 1 at 12:48
Dmitry ParanyushkinDmitry Paranyushkin
2,43333679
add a comment |
I am warned about vulnerabilities in the packages listed in the package-lock.json file of my Node.Js project.
I can follow the advice here and reinstall all the packages with npm install <package-name>, however, I also use other npm projects that use the older versions of those packages, which will not get reinstalled with a simple npm install.
Does it mean I have to go to package-lock.json and manually change all the dependencies to the latest version?
What if they break?
Isn't there a proper way of doing the updates that ensures you won't break the other packages dependent on the old versions?
javascript node.js security package-lock.json
asked Jan 1 at 12:48
Dmitry ParanyushkinDmitry Paranyushkin
2,43333679
add package-lock.json in .gitignore
– SAURABH RATHOD
Jan 1 at 12:56
oh non, don't do what saurabh rathod says!!! Super bad idea, and it will not solve your issue anyway...
– frsechet
Jan 1 at 12:58
add a comment |
I am warned about vulnerabilities in the packages listed in the package-lock.json file of my Node.Js project.
I can follow the advice here and reinstall all the packages with npm install <package-name>, however, I also use other npm projects that use the older versions of those packages, which will not get reinstalled with a simple npm install.
Does it mean I have to go to package-lock.json and manually change all the dependencies to the latest version?
What if they break?
Isn't there a proper way of doing the updates that ensures you won't break the other packages dependent on the old versions?
javascript node.js security package-lock.json
asked Jan 1 at 12:48
Dmitry ParanyushkinDmitry Paranyushkin
2,43333679
I am warned about vulnerabilities in the packages listed in the package-lock.json file of my Node.Js project.
I can follow the advice here and reinstall all the packages with npm install <package-name>, however, I also use other npm projects that use the older versions of those packages, which will not get reinstalled with a simple npm install.
Does it mean I have to go to package-lock.json and manually change all the dependencies to the latest version?
What if they break?
Isn't there a proper way of doing the updates that ensures you won't break the other packages dependent on the old versions?
javascript node.js security package-lock.json
javascript node.js security package-lock.json
asked Jan 1 at 12:48
Dmitry ParanyushkinDmitry Paranyushkin
2,43333679
asked Jan 1 at 12:48
Dmitry ParanyushkinDmitry Paranyushkin
2,43333679
asked Jan 1 at 12:48
Dmitry ParanyushkinDmitry Paranyushkin
2,43333679
asked Jan 1 at 12:48
Dmitry ParanyushkinDmitry Paranyushkin
2,43333679
asked Jan 1 at 12:48
Dmitry ParanyushkinDmitry Paranyushkin
2,43333679
2,43333679
add package-lock.json in .gitignore
– SAURABH RATHOD
Jan 1 at 12:56
oh non, don't do what saurabh rathod says!!! Super bad idea, and it will not solve your issue anyway...
– frsechet
Jan 1 at 12:58
add a comment |
add package-lock.json in .gitignore
– SAURABH RATHOD
Jan 1 at 12:56
oh non, don't do what saurabh rathod says!!! Super bad idea, and it will not solve your issue anyway...
– frsechet
Jan 1 at 12:58
add package-lock.json in .gitignore
– SAURABH RATHOD
Jan 1 at 12:56
add package-lock.json in .gitignore
– SAURABH RATHOD
Jan 1 at 12:56
oh non, don't do what saurabh rathod says!!! Super bad idea, and it will not solve your issue anyway...
– frsechet
Jan 1 at 12:58
oh non, don't do what saurabh rathod says!!! Super bad idea, and it will not solve your issue anyway...
– frsechet
Jan 1 at 12:58
add a comment |
1 Answer
1
active
oldest
votes
If the issue is on a package you directly depend upon, you should update it directly and save it to the package.json + lock its version in package-lock.json in the process by doing something like npm install your-dependency@latest --save[-dev]. But beware: there might be breaking changes that will break your code (for example in case the dependency had a major version update inbetween with some deprecations and breaking changes).
But if the issue is from a dependency of one of your dependencies, the very very best way to solve it is to raise an issue (potentially with a PR to help them) with the maintainer of the parent package, then when they provide an update, update the dependency itself in your project.
You can use npm audit to resolve some issues as well (probably not all, and if a sub-dependency version is specifically required by a dependency, it will not update it because it could break things), but the single best way to solve the issue for you and for everybody else is to get the maintainer of the module you want to update its dependencies, when/if they can.
Reinstalling everything will not solve the issue if the dependency is still vulnerable. Installing does not magically fix stuff, people do :-) However, what you may want to do is use npm outdated to list all the packages that have newer versions available and try to update them, one by one, and see if your vulnerabilities are resolved after that (npm audit).
One more thing: it's usually a bad practice to go and change stuff around manually in package-lock.json. This file should be only auto-generated by one of your npm install (or similar) scripts. This file is what is used by npm to resolve the list of exact dependency/subdependency versions on a fresh install, and it is really the single best way to ensure all the people who use or work on this project have the exact same version of all their dependencies, so it better be correct. Always commit your package-lock.json!
answered Jan 1 at 13:03
frsechetfrsechet
312312
1
Good answer, and I'll add that you should make sure your org understands fixing an audited vulnerability is not always something you can do immediately. Ticket and track all vulnerabilities, absolutely, but it can take days, weeks, or even months sometimes to track down the correct package maintainer, have them fix the vulnerability, update to the appropriate version, etc.
– Elliot Nelson
Jan 1 at 15:07
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53995567%2fthe-best-way-to-resolve-vulnerabilities-in-package-lock-json%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
If the issue is on a package you directly depend upon, you should update it directly and save it to the package.json + lock its version in package-lock.json in the process by doing something like npm install your-dependency@latest --save[-dev]. But beware: there might be breaking changes that will break your code (for example in case the dependency had a major version update inbetween with some deprecations and breaking changes).
But if the issue is from a dependency of one of your dependencies, the very very best way to solve it is to raise an issue (potentially with a PR to help them) with the maintainer of the parent package, then when they provide an update, update the dependency itself in your project.
You can use npm audit to resolve some issues as well (probably not all, and if a sub-dependency version is specifically required by a dependency, it will not update it because it could break things), but the single best way to solve the issue for you and for everybody else is to get the maintainer of the module you want to update its dependencies, when/if they can.
Reinstalling everything will not solve the issue if the dependency is still vulnerable. Installing does not magically fix stuff, people do :-) However, what you may want to do is use npm outdated to list all the packages that have newer versions available and try to update them, one by one, and see if your vulnerabilities are resolved after that (npm audit).
One more thing: it's usually a bad practice to go and change stuff around manually in package-lock.json. This file should be only auto-generated by one of your npm install (or similar) scripts. This file is what is used by npm to resolve the list of exact dependency/subdependency versions on a fresh install, and it is really the single best way to ensure all the people who use or work on this project have the exact same version of all their dependencies, so it better be correct. Always commit your package-lock.json!
answered Jan 1 at 13:03
frsechetfrsechet
312312
1
Good answer, and I'll add that you should make sure your org understands fixing an audited vulnerability is not always something you can do immediately. Ticket and track all vulnerabilities, absolutely, but it can take days, weeks, or even months sometimes to track down the correct package maintainer, have them fix the vulnerability, update to the appropriate version, etc.
– Elliot Nelson
Jan 1 at 15:07
add a comment |
If the issue is on a package you directly depend upon, you should update it directly and save it to the package.json + lock its version in package-lock.json in the process by doing something like npm install your-dependency@latest --save[-dev]. But beware: there might be breaking changes that will break your code (for example in case the dependency had a major version update inbetween with some deprecations and breaking changes).
But if the issue is from a dependency of one of your dependencies, the very very best way to solve it is to raise an issue (potentially with a PR to help them) with the maintainer of the parent package, then when they provide an update, update the dependency itself in your project.
You can use npm audit to resolve some issues as well (probably not all, and if a sub-dependency version is specifically required by a dependency, it will not update it because it could break things), but the single best way to solve the issue for you and for everybody else is to get the maintainer of the module you want to update its dependencies, when/if they can.
Reinstalling everything will not solve the issue if the dependency is still vulnerable. Installing does not magically fix stuff, people do :-) However, what you may want to do is use npm outdated to list all the packages that have newer versions available and try to update them, one by one, and see if your vulnerabilities are resolved after that (npm audit).
One more thing: it's usually a bad practice to go and change stuff around manually in package-lock.json. This file should be only auto-generated by one of your npm install (or similar) scripts. This file is what is used by npm to resolve the list of exact dependency/subdependency versions on a fresh install, and it is really the single best way to ensure all the people who use or work on this project have the exact same version of all their dependencies, so it better be correct. Always commit your package-lock.json!
answered Jan 1 at 13:03
frsechetfrsechet
312312
1
Good answer, and I'll add that you should make sure your org understands fixing an audited vulnerability is not always something you can do immediately. Ticket and track all vulnerabilities, absolutely, but it can take days, weeks, or even months sometimes to track down the correct package maintainer, have them fix the vulnerability, update to the appropriate version, etc.
– Elliot Nelson
Jan 1 at 15:07
add a comment |
If the issue is on a package you directly depend upon, you should update it directly and save it to the package.json + lock its version in package-lock.json in the process by doing something like npm install your-dependency@latest --save[-dev]. But beware: there might be breaking changes that will break your code (for example in case the dependency had a major version update inbetween with some deprecations and breaking changes).
But if the issue is from a dependency of one of your dependencies, the very very best way to solve it is to raise an issue (potentially with a PR to help them) with the maintainer of the parent package, then when they provide an update, update the dependency itself in your project.
You can use npm audit to resolve some issues as well (probably not all, and if a sub-dependency version is specifically required by a dependency, it will not update it because it could break things), but the single best way to solve the issue for you and for everybody else is to get the maintainer of the module you want to update its dependencies, when/if they can.
Reinstalling everything will not solve the issue if the dependency is still vulnerable. Installing does not magically fix stuff, people do :-) However, what you may want to do is use npm outdated to list all the packages that have newer versions available and try to update them, one by one, and see if your vulnerabilities are resolved after that (npm audit).
One more thing: it's usually a bad practice to go and change stuff around manually in package-lock.json. This file should be only auto-generated by one of your npm install (or similar) scripts. This file is what is used by npm to resolve the list of exact dependency/subdependency versions on a fresh install, and it is really the single best way to ensure all the people who use or work on this project have the exact same version of all their dependencies, so it better be correct. Always commit your package-lock.json!
answered Jan 1 at 13:03
frsechetfrsechet
312312
If the issue is on a package you directly depend upon, you should update it directly and save it to the package.json + lock its version in package-lock.json in the process by doing something like npm install your-dependency@latest --save[-dev]. But beware: there might be breaking changes that will break your code (for example in case the dependency had a major version update inbetween with some deprecations and breaking changes).
But if the issue is from a dependency of one of your dependencies, the very very best way to solve it is to raise an issue (potentially with a PR to help them) with the maintainer of the parent package, then when they provide an update, update the dependency itself in your project.
You can use npm audit to resolve some issues as well (probably not all, and if a sub-dependency version is specifically required by a dependency, it will not update it because it could break things), but the single best way to solve the issue for you and for everybody else is to get the maintainer of the module you want to update its dependencies, when/if they can.
Reinstalling everything will not solve the issue if the dependency is still vulnerable. Installing does not magically fix stuff, people do :-) However, what you may want to do is use npm outdated to list all the packages that have newer versions available and try to update them, one by one, and see if your vulnerabilities are resolved after that (npm audit).
One more thing: it's usually a bad practice to go and change stuff around manually in package-lock.json. This file should be only auto-generated by one of your npm install (or similar) scripts. This file is what is used by npm to resolve the list of exact dependency/subdependency versions on a fresh install, and it is really the single best way to ensure all the people who use or work on this project have the exact same version of all their dependencies, so it better be correct. Always commit your package-lock.json!
answered Jan 1 at 13:03
frsechetfrsechet
312312
edited Jan 1 at 13:08
answered Jan 1 at 13:03
frsechetfrsechet
312312
answered Jan 1 at 13:03
frsechetfrsechet
312312
answered Jan 1 at 13:03
frsechetfrsechet
312312
312312
1
Good answer, and I'll add that you should make sure your org understands fixing an audited vulnerability is not always something you can do immediately. Ticket and track all vulnerabilities, absolutely, but it can take days, weeks, or even months sometimes to track down the correct package maintainer, have them fix the vulnerability, update to the appropriate version, etc.
– Elliot Nelson
Jan 1 at 15:07
add a comment |
1
Good answer, and I'll add that you should make sure your org understands fixing an audited vulnerability is not always something you can do immediately. Ticket and track all vulnerabilities, absolutely, but it can take days, weeks, or even months sometimes to track down the correct package maintainer, have them fix the vulnerability, update to the appropriate version, etc.
– Elliot Nelson
Jan 1 at 15:07
1
1
Good answer, and I'll add that you should make sure your org understands fixing an audited vulnerability is not always something you can do immediately. Ticket and track all vulnerabilities, absolutely, but it can take days, weeks, or even months sometimes to track down the correct package maintainer, have them fix the vulnerability, update to the appropriate version, etc.
– Elliot Nelson
Jan 1 at 15:07
Good answer, and I'll add that you should make sure your org understands fixing an audited vulnerability is not always something you can do immediately. Ticket and track all vulnerabilities, absolutely, but it can take days, weeks, or even months sometimes to track down the correct package maintainer, have them fix the vulnerability, update to the appropriate version, etc.
– Elliot Nelson
Jan 1 at 15:07
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53995567%2fthe-best-way-to-resolve-vulnerabilities-in-package-lock-json%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
add package-lock.json in .gitignore
– SAURABH RATHOD
Jan 1 at 12:56
oh non, don't do what saurabh rathod says!!! Super bad idea, and it will not solve your issue anyway...
– frsechet
Jan 1 at 12:58