Posted by mpp on February 1, 2020 at 1:04pm
With static code analysis tools like SonarPHP it's possible to automatically detect some security vulnerabilities.
Github also provides a tool (dependabot) to check for vulnerabilities in dependencies. Not sure if Gitlab has a similar solution?
This probably a question/task for the infrastructure team but before we start implementing solutions I'd like to discuss and document some best practices.
What type of tools are there (static code analysis for Php/javascript etc, dependency checks,...)
What tools are out there?
How well do they play with Drupal?
Can/should we set this up for contrib (like we can do now for some linters)?
Can we create a documentation page to describe how to set up these tools for Drupal projects?
Comments
Checking the full supply chain
Super interested in this. We harden server instances and scan for vulnerabilities, but I'm very concerned about libraries (php, npm, js, ...)
We're starting to look at tools like trivy, grafeas and in-toto, but do not yet have anything put together. Would love to hear of others' experience and will gladly document what we learn.
+1
We also keep getting security reviews and questionnaires from enterprise companies about regular security checks, protections again supply chain attacks, etc.
We already have our in-house tooling for monitoring PHP/JS components for security releases.
For some reason, I thought that at least we are on the safe side with Drupal core and its dependencies because they are monitored and core developers are usually in close contact with main dependency maintainers. (I saw in D.o issues all those "background checks" that are being done before a dependency is added to the core, which is great.)
But @moshe highlighted that downstream devs are reliable for monitoring 3rd party dependencies, including dependencies of Drupal core: https://www.drupal.org/node/1189632
After https://www.drupal.org/sa-core-2021-003 I started to wonder if/how Drupal core ("bundled") 3rd party dependencies are being monitored for security releases.
It is also interesting that our current security scanners did not spot the Ckeditor vulnerability, so either our tooling needs enhancements or something else is going on...
Ckeditor is delivered as part of the core, (I am mainly a backend dev, but) I haven't found any references to that package in any
package.jsonoryarn.lock, so it is actually bundled with the core. (FIXME). Therefore, my assumption is that even if you also useyarn auditor similar tool for identifying vulnerable JS dependencies then they won't tell you if there is a security update for Ckeditor because it is an unknown dependency to those. (What about other JS libs in core/assets/vendor?). But even if we could know that the installed Ckeditor version is vulnerable, how we could fix that the right way :tm:? Should we install an updated version of Ckeditor somewhere else and withhook_library_info_alter()replace the installed path of the bundled library? Would that work in every case? So there are several questions in this regard...Supply chain attacks are also one of the most effective attack vectors nowadays, if someone could leverage that and sneak malicious code to any "bundled" component of Drupal core (or tar.gz/zip versions of Drupal) that would be very serious.
https://www.bleepingcomputer.com/news/security/malicious-npm-packages-ta...
https://blog.packagist.com/preventing-dependency-hijacking/ (although
https://thehackernews.com/2021/04/a-new-php-composer-bug-could-enable.html)