-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a check to see if a vunerability above a certain severity is being ignored #49
Comments
That's a great idea. Resolve file has a field with rules. We could implement a rule to define lowest severity that can't be ignored and fail check if it's found. I'll see if the branch I'm working on is in good shape and guide you in - most likely on Friday |
Great! Thanks @naugtur |
@lewisdaly I've created a branch with For your first implementation I think you should hardcode the rule for severity level as I forgot to expose the getRules function from audit-resolve-core ;) Let me know if this is helpful. We can jump into a live chat somewhere if you need more. Voice is also an option next week. I can barely speak today, hoping to get better. |
@lewisdaly Are you interested in coming back to this? |
@lewisdaly You interested in doing it? I'm finally going to set some time aside to finish v3 and release it as the main version, so you could still get that in. |
Hi @naugtur! Thanks for this tool you've built, we use it quite a bit at mojaloop.
We're currently looking for a way to limit the severity of vulnerabilities that can be ignored by developers. Say, for example, there are 2 vulnerabilities without fixes on a project, one is
low
and the otherhigh
. A developer may go and ignore both of those vulnerabilities to keep on working on their project, but we now have very little visibility into the severity of the vulnerabilities being ignored.We want a way for our CI/CD tool to check if a developer has ignored a vulnerability above a certain severity, say
high
orcritical
, and either fail a build, or allow us to capture that information elsewhere.Has this feature request come up before? I can think of a couple ways I'd implement it with wrappers around your tool, but I'm thinking it would be better to integrate into the
npm-audit-resolver
itself. I'm happy to spend some time contributing to this myself if you can help me get started.The text was updated successfully, but these errors were encountered: