Looking back at all (now) published vulnerabilities in #curl that were present in code from 2020 until now, at no point in those years was the share of "C mistakes" higher than 15% of all vulns.
-
Looking back at all (now) published vulnerabilities in #curl that were present in code from 2020 until now, at no point in those years was the share of "C mistakes" higher than 15% of all vulns.
Through all years, the C mistake share of all vulnerabilities in #curl was never above 45% at any single point in history.
-
Looking back at all (now) published vulnerabilities in #curl that were present in code from 2020 until now, at no point in those years was the share of "C mistakes" higher than 15% of all vulns.
Through all years, the C mistake share of all vulnerabilities in #curl was never above 45% at any single point in history.
@bagder What changed ~2018? That's a pretty steep decline in C-related vulnerabilities.
-
@bagder What changed ~2018? That's a pretty steep decline in C-related vulnerabilities.
@jake I can't say or spot any specific change or process we did that could explain that...
-
Looking back at all (now) published vulnerabilities in #curl that were present in code from 2020 until now, at no point in those years was the share of "C mistakes" higher than 15% of all vulns.
Through all years, the C mistake share of all vulnerabilities in #curl was never above 45% at any single point in history.
we have three more CVEs pending that soon will expand this graph a little, but none of those is a C mistake...
-
@jake I can't say or spot any specific change or process we did that could explain that...
@bagder @jake pure guess, maybe vulns in curl take years to discover (especially as software engineering techniques improve and make them harder to write in the first place) so we’re not yet seeing the « latest » vulns, only the old ones ?
It should be fairly easy to disprove though, @bagder do you have data on how long vuln stay in curl on average/median ?
-
@bagder What changed ~2018? That's a pretty steep decline in C-related vulnerabilities.
@jake @bagder
There is also a jump after 2012 till 2018 for 'c mistakes'. That is definitely related to better tooling. E.g. sanitizers (which came out in 2012).
Also as you find the 'C mistakes' ones; there are less of them. And with folks running now with sanitizers on a daily bases, you will find them earlier. Not just about curl project doing it but folks in general. -
Looking back at all (now) published vulnerabilities in #curl that were present in code from 2020 until now, at no point in those years was the share of "C mistakes" higher than 15% of all vulns.
Through all years, the C mistake share of all vulnerabilities in #curl was never above 45% at any single point in history.
@bagder do you have in mind some interesting or unexpected C ones? only for my curiosity/learning, nothing serious
-
@bagder @jake pure guess, maybe vulns in curl take years to discover (especially as software engineering techniques improve and make them harder to write in the first place) so we’re not yet seeing the « latest » vulns, only the old ones ?
It should be fairly easy to disprove though, @bagder do you have data on how long vuln stay in curl on average/median ?
@poliorcetics @jake that's entirely true. Vulns in curl are 8 years old on average when reported! But also: there's no particular age difference between found vulns if they are C mistakes or not, so there's nothing that says they will change a lot. But we don't know...
-
@jake @bagder
There is also a jump after 2012 till 2018 for 'c mistakes'. That is definitely related to better tooling. E.g. sanitizers (which came out in 2012).
Also as you find the 'C mistakes' ones; there are less of them. And with folks running now with sanitizers on a daily bases, you will find them earlier. Not just about curl project doing it but folks in general. -
@bagder do you have in mind some interesting or unexpected C ones? only for my curiosity/learning, nothing serious
@spinnyspinlock we've only had two severity HIGH CVEs in #curl within the last five years, both of them were C mistakes: https://curl.se/docs/CVE-2023-38545.html and https://curl.se/docs/CVE-2021-22901.html
-
Looking back at all (now) published vulnerabilities in #curl that were present in code from 2020 until now, at no point in those years was the share of "C mistakes" higher than 15% of all vulns.
Through all years, the C mistake share of all vulnerabilities in #curl was never above 45% at any single point in history.
@bagder why the shape of vulnerabilities and "C" mistakes align so good?
-
@spinnyspinlock we've only had two severity HIGH CVEs in #curl within the last five years, both of them were C mistakes: https://curl.se/docs/CVE-2023-38545.html and https://curl.se/docs/CVE-2021-22901.html
@bagder CVE-2021-22901 was exactly the kind of interesting vulnerability I wanted to see, thank you! well done on the good security track record too
-
R relay@relay.infosec.exchange shared this topic
-
Looking back at all (now) published vulnerabilities in #curl that were present in code from 2020 until now, at no point in those years was the share of "C mistakes" higher than 15% of all vulns.
Through all years, the C mistake share of all vulnerabilities in #curl was never above 45% at any single point in history.
@bagder Stupid question:
What are non-c mistakes? Examples? -
@bagder Stupid question:
What are non-c mistakes? Examples? -
@bagder CVE-2021-22901 was exactly the kind of interesting vulnerability I wanted to see, thank you! well done on the good security track record too
@spinnyspinlock @bagder Sanitizers are only as good as code coverage. If code is not exercised when the sanitizer runs, the bug will not be detected.
-
R relay@relay.an.exchange shared this topic
