This is a very frequent question asked by our customers, who are in the process of fixing vulnerabilities that Meterian discovers in their dependency graph.
As you all know we have two scores at the moment, security and stability (you can read more about them at this previous post) and those scores are calculated with a different mechanism. In general, each score is initially 100 (all good) and then points are deducted based on different circumstances.
First, let’s clarify the types of advice that we maintain in our database, we have three of them:
this type of advice is usually related to a very well known security flaw in a library, such as the infamous CVE-2017-5638 that caused the recent Equifax disaster
this type of advice is used to report a serious defect of a library that can potentially affect the stability of your system, like the memory leak that affects certain versions of Hibernate, a very well known ORM library
this type of advice provides a suggestion from our team to swap a library with another or to progress to the next version
These are the deductions applied to the stability score:
- minus 20 for each DEFECT advice with HIGH severity
- minus 10 for each DEFECT advice with MEDIUM severity
- minus 4 for each DEFECT advice with LOW severity
- minus 1 for any direct depending library where a patch version is available
These are the deductions applied to the security score:
- minus points for each SECURITY advice, based on its CVSS score multiplied by 5
(i.e. CVSS score is 6, minus 30 points)
You may think, sometimes, that we are very harsh in our judgement: as you can see a high scored SECURITY advice, like the CVE-2017-5638, will bring your score down of 45 points, but we feel it’s better to receive a strong alert rather than a mild one, that can go undetected.
So please do not be scared of a zero, but please fix the problems reported as soon as possible: waiting is not an option.
In the previous post we introduced our badges that give an immediate feedback on the status of your code. Badges are handy, but we are really trying to give developers the best feedback possible to allow them to fix possible defects and vulnerabilities quickly.
For those reasons we have created the Report
The Report gives you a detailed analysis of your dependencies, listing all the libraries with known security vulnerabilities as well as the ones who have received bug fixes and should be updated. It’s really simple at this point to decide what to fix, and see the Stability and Security indicators increase in the next Meterian scan (see also our FAQ: How frequently does Meterian scan my project?)
In the top part of the page you can notice a selector to visualise the report for each of your project branches; just remember that creating a report takes a few minutes, so the first time you switch to a new branch allow for up to 5 minutes for the report to appear.
Interested in learning more about Meterian? We are looking for companies willing to trial it and work with us to build the next-generation Continuous Security platform. Contact us at firstname.lastname@example.org for more details.
As we are trying to bring Continuous Security into every software project, we came up with two simple indicators to quantify the health status of a codebase: we called them Security and Stability.
Security measures how likely is a codebase to be affected by security vulnerabilities. A value of 0 stands for “very likely to be insecure”, while a value of 100 is, of course, very secure according to our analysis. Several factors can decrease the security score: depending on a library with known security issues is one of the major, as well as displaying one of the common “mistake patterns” in the code. We’ll certainly talk more about that in future posts.
The Stability indicator shows how likely is code to be subject to critical defects. While not directly related to software security, critical defects can cause the application to misbehave, crash, or perform poorly. Similarly to the Security indicator, the Stability indicator is calculated using a mix of static code analysis and assessment of the libraries in use.
When you integrate the Meterian Continuous Security platform in your application, it is a good idea to display the two badges in your project page (or in the README file if you use one of the popular platforms like Github), to immediately have a clear indicator of the health status of your codebase. Of course it is also possible to display a full report of all the issues detected by the latest security scan – that will be the topic of the next blog post.
The other significant point is that technology, like the evolution of the life-forms that spawned it, is inherently an accelerating process.
Ray Kurzweil, “The age of spiritual machines”
Anybody involved in writing code, from the lone hobbyist developer to Fortune 500 companies, cannot miss the acceleration we are going through in software technologies.
While twenty years ago web developers were facing just a few choices in determining their favourite software stack, nowadays we have to decide among thousands of possible combinations of development languages, frameworks and databases – just to mention a few areas. And this acceleration doesn’t just stop at tools; we face new challenges in making our code run in multiple environments (and in the cloud), challenges like coping with traffic generated by 3+ billions of internet users, and challenges in keeping our data safe from malicious attacks.
When looking at the landscape from this angle, it is surprising companies are still able to cope with this accelerating complexity and still produce software that works, and serve hundred of millions of users. However that’s no small task, especially for small and medium companies: keeping always up to date with the latest security advisories, with the latest bug fixes and new software updates takes a lot of effort.
At this point the perfect first blog post should pull the proverbial rabbit out of a hat, and announce we have a solution. More humbly, at Meterian we can say we are embarking on a path to make all that easier; to make a platform that works together with developers in analysing the code and finding ways to improve it, to prevent bugs and, most importantly, security issues. We call it continuous security.