https://pact.io logo
Join Slack
Powered by
Hi, Could you please have a look at this please: <...
# pact-js
d
Hi, Could you please have a look at this please: https://github.com/pact-foundation/pact-js/issues/880 It’s actually blocking all our pipelines 😕
m
I'll merge later tonight and release a new version. .
🙏 1
P.s. having a pipeline blocked on this is a bit crazy. The vulnerability is still there, blocking a pipeline just means you can't do anything else in the meantime
But I assume it's something security have put in place to annoy you 🤣
d
Yes it's exactly that 😂 I mean this dependency will never reach the production but anyway everything is blocked 😖
m
New release on the way out, assuming the upgrade doesn’t break things
Wow, so a disputed security issue in a dev dependency blocked your build 👀 https://github.com/ramda/ramda/pull/3192#issuecomment-975677276
batman slap
Go find your security people and give them a little tickle
💪 1
d
😂
They don’t care if it’s a devdep or dep. Basically the vulnerability analysis is red whenever it finds in the node_modules a vulnerable dependency with a CVSS score greater than 9.
😞
m
😬
y
They don’t care if it’s a devdep or dep.
That is bad sec practise, as it gets people worried about the wrong thing imo. Hope you are sorted now, but the sec team will have to understand that open source projects do not have necessarily have SLA's for user's issues, and blocking your entire pipeline for code outside your control is a serious risk.
💯 1
Are your teams vetting all open source code and it's dependencies before pulling it in? do you review chances applied by security vulnerability patches to ensure they don't cause more issues, than they try to fix?
Thanks Matt for pushing the change out, and Dany for raising via GH 👍
👍 2
t
I thought I removed Ramda a while back, but maybe I only did that in the beta (or maybe I remember wrong)
👍 1
I wanted to remove ramda and lodash, as pact doesn't really need them and they both had this kind of churn
d
No, the vulnerability scan only occurs in the pipeline and not when developers pull the dependencies. But anyway they are not really exploitable locally or am I wrong? And no we don't review the changes, we basically use a tool that blocks the pipeline if you have in your node modules a known vulnerability with a CVSS score greater than 9.
m
We definitely don’t need both. When I made those changes to bring in the request filter the other day I noticed one branch had ramda and the other didn’t
I prefer ramda over lodash/underscore for a number of reasons.
In this case - not that it matters - but ramda made the case that it’s not actually a prototype poisoning vulnerability, but because somebody raised a PR/issue and used those words, Veracode (who submitted the CVSS) scored it as a 9, using the very same issue as the justification. The CVSS now states “disputed” (and rightly so).
But practically it doesns’t matter, it got submitted to the scoring system and the effect is the same, even if there is no actual exploitable vulnerability
doubly so, because it’s a dev dep
b
Also, blocking the build doesn't mean the dep can't make it to prod, it might already be in prod if it was identified late.
💯 1
t
I've never been brave enough to tell security this, for fear that they might say "good point, we'll rig up a script that undeploys everything that has a vulnerable dependency"
😅 2
Open in Slack
PreviousNext
Powered by