GitLab scans its customers' source code, finds it's as fragile as you'd expect
(2020/10/06)
- Reference: 1602009648
- News link: https://www.theregister.co.uk/2020/10/06/gitlab_scans_customer_code_finds/
- Source link:
GitLab, a rival to Microsoft's hosted git service GitHub, has for the second time tested the security of customers' hosted software projects... and found them wanting.
The code storage and automation biz initially scanned hosted code for security issues [1]in April . Having just [2]just reprised its examination, the outfit has found there's still work that needs to be done to reduce software vulnerabilities.
The biz's second security trends report shows a surge in projects that integrate vulnerable code libraries.
"The percentage of projects finding issues with dependent libraries in use has significantly increased over the last year, from 26 per cent to 69 per cent," said Wayne Haber, engineering director, in the report. "This reinforces that updating dependent libraries should be prioritized based on the risks those libraries pose."
The habit of creating apps with libraries that depend on still smaller libraries has made managing modern software security difficult, to say the least, since a bug in a common dependency can become a widespread problem across multiple projects. The issue is particularly bad in the Node.js ecosystem.
As of August, the libraries with the most vulnerabilities (all distributed via npm) were:
Lodash: Object prototype pollution
Execa: OS command injection
Mixin-deep: Prototype pollution
Kind-of: Type checking
Sockjs: Cross-site scripting
Ajv: Improper input validation
Minimist: Improper input validation
Yargs-parser: Improper input validation
JQuery: 3rd party CORS request may execute
Dot-prop: Direct request forced browsing
Both Lodash and JQuery tend to feature prominently in [3]security [4]reports as a source of vulnerabilities. It doesn't help that they're both [5]widely used and have gone [6]long periods without updates.
Haber said the top three Common Weakness Enumerations (CWEs) – programming blunders that have the potential to lead to exploitable vulnerabilities – were:
CWE-20: Improper input validation, which enables injection attacks.
CWE-787: Out of bounds write of intended buffer, which enables remote code execution.
CWE-400: Uncontrolled resource consumption, which enables denial of service attacks.
There are a few bright spots, where "bright" means not getting worse or marginal improvement. The percentage of projects using containers with vulnerabilities, for example, has fallen from 52 per cent to 41 per cent. Also the percentage of projects with flaws found through static analysis has remained basically flat (from 49 per cent to 52 per cent).
At the same time, the sorts of flaws identified via static analysis seem like they should have been dealt with long ago, like passwords exposed in URLs, improper permissions for files, predictable pseudorandom number generation, and lack of cipher integrity checking.
If anything, GitLab's report shows that there's always going to be work for computer security professionals. ®
Get our [7]Tech Resources
[1] https://about.gitlab.com/blog/2020/04/02/security-trends-in-gitlab-hosted-projects/
[2] https://about.gitlab.com/blog/2020/10/06/gitlab-latest-security-trends/
[3] https://www.theregister.com/2020/05/12/open_source_bugs/
[4] https://www.theregister.com/2020/06/15/docker_hub_proves_so_secure/
[5] https://www.theregister.com/2020/02/20/linux_foundation_report/
[6] https://www.theregister.com/2020/07/03/lodash_library_npm_vulnerability/
[7] https://whitepapers.theregister.com/
The code storage and automation biz initially scanned hosted code for security issues [1]in April . Having just [2]just reprised its examination, the outfit has found there's still work that needs to be done to reduce software vulnerabilities.
The biz's second security trends report shows a surge in projects that integrate vulnerable code libraries.
"The percentage of projects finding issues with dependent libraries in use has significantly increased over the last year, from 26 per cent to 69 per cent," said Wayne Haber, engineering director, in the report. "This reinforces that updating dependent libraries should be prioritized based on the risks those libraries pose."
The habit of creating apps with libraries that depend on still smaller libraries has made managing modern software security difficult, to say the least, since a bug in a common dependency can become a widespread problem across multiple projects. The issue is particularly bad in the Node.js ecosystem.
As of August, the libraries with the most vulnerabilities (all distributed via npm) were:
Lodash: Object prototype pollution
Execa: OS command injection
Mixin-deep: Prototype pollution
Kind-of: Type checking
Sockjs: Cross-site scripting
Ajv: Improper input validation
Minimist: Improper input validation
Yargs-parser: Improper input validation
JQuery: 3rd party CORS request may execute
Dot-prop: Direct request forced browsing
Both Lodash and JQuery tend to feature prominently in [3]security [4]reports as a source of vulnerabilities. It doesn't help that they're both [5]widely used and have gone [6]long periods without updates.
Haber said the top three Common Weakness Enumerations (CWEs) – programming blunders that have the potential to lead to exploitable vulnerabilities – were:
CWE-20: Improper input validation, which enables injection attacks.
CWE-787: Out of bounds write of intended buffer, which enables remote code execution.
CWE-400: Uncontrolled resource consumption, which enables denial of service attacks.
There are a few bright spots, where "bright" means not getting worse or marginal improvement. The percentage of projects using containers with vulnerabilities, for example, has fallen from 52 per cent to 41 per cent. Also the percentage of projects with flaws found through static analysis has remained basically flat (from 49 per cent to 52 per cent).
At the same time, the sorts of flaws identified via static analysis seem like they should have been dealt with long ago, like passwords exposed in URLs, improper permissions for files, predictable pseudorandom number generation, and lack of cipher integrity checking.
If anything, GitLab's report shows that there's always going to be work for computer security professionals. ®
Get our [7]Tech Resources
[1] https://about.gitlab.com/blog/2020/04/02/security-trends-in-gitlab-hosted-projects/
[2] https://about.gitlab.com/blog/2020/10/06/gitlab-latest-security-trends/
[3] https://www.theregister.com/2020/05/12/open_source_bugs/
[4] https://www.theregister.com/2020/06/15/docker_hub_proves_so_secure/
[5] https://www.theregister.com/2020/02/20/linux_foundation_report/
[6] https://www.theregister.com/2020/07/03/lodash_library_npm_vulnerability/
[7] https://whitepapers.theregister.com/
Fragile source code
RM Myers
But is it "Agile"? Remember folks, the goals are to move fast and break things. The consistent accomplishment of one of these goals has been the crowning achievement of the 21st century IT.
Public?
petef
I do hope that they were only scanning public repos and not private.
Don't build on sand
Its either because my background as an embedded C developer or that I've got old*, but the thought of using layers of libraries which you aren't in control of, fills me with horror. It took until C++11 until I was happy using STL, and I still think Boost is often a step too far, no matter how useful. But then again, when I'm doing Python I'm happy to use anything that's in pip, as long as it has good documentation.
However, if I ever start using javascript, dragging in god knows what libraries from npm while cutting and pasting code I don't understand from stackoverflow, I hope someone will put me out of my misery.
* I think you've already decided which.