Semanticmediawiki: From VersionEye to Snyk

Created on 3 Jan 2018  路  8Comments  路  Source: SemanticMediaWiki/SemanticMediaWiki

Since VersionEye will be defunct, actually I should have been already by now so I removed our VersionEye badges from the READMEs. Now it seems that there is a replacement called Snyk which is supposed to do similar or even the same. I also appears to be free for open source software and it may be added to CI via GitHub. So the question is if SMW should go Snyk or not.

@mwjames @JeroenDeDauw @s7eph4n

infrastructure invalid question

All 8 comments

I suggest to add it to this repo and see how it goes. Then we can add it to others as well. Can do this on a found-use-for-it-in-this-repo-basis

Can do this on a found-use-for-it-in-this-repo-basis

Could we call this Snyk-Preview? :)

@JeroenDeDauw I'd say you may move on since no objections were raised.

@JeroenDeDauw Just a cheer up for you letting this snyk in. :)

Do I need to do something?

Do I need to do something?

I interpreted your https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/2931#issuecomment-355162741 in the way that you volunteered doing this, no? I a sure you had something in mind.

You can add your Node.js, Ruby, Python, Scala and Java GitHub repos and quickly test them, or decide which ones you鈥檇 like to continously watch with Snyk.

Ok, end of this story. This was down in the FAQs.

I used Snyk and it works quite well. It is even free for use for basic needs and very well integrated in GutHub. Its suggestions are accurate, and include security issues (fixes when available). The proposed fixes are correctly tested, including most dependencies. Then it pulls proposed changes that just need to to integrated (most often as is), they have been pretested in their own building environment and if there are building problems (or unit tests failing after the change, you get the reports, as maybe these unit tests have their own incorrect assumptions).

The paid subscription option offers a few additional services which may be important for large project management ion a team (notably the possibility to manage more branches and various life cycles or specific deployment options).
It monitors common security surveys (notably CVE reports, known attacks, points to documentation pages, things that should be deprecated and changed soon, and things that are still not fixed and will require complex workaround or disabling some features or find a way to isolate the problem so it cannot be harnessed: e.g. changing access rights, firewall settings, or separating some features in a distinct service in its sandboxing VM, or replacing a component by another one).
It also signals components that are no longer maintained and that should be forked and maintained by a new team, possibly and redesigned.

Was this page helpful?
0 / 5 - 0 ratings