It would be nice to be able to at least run phan-taint-check as a stand-alone SAST within gitlab ci. I'm not sure how feasible this will be at this point, since I believe it's fairly tightly-coupled with phan/mediawiki-phan-config these days. So if the path of least resistance is just getting the phan-docker jobs running under gitlab ci, this task can likely be declined.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | sbassett | T289290 Design and Build Application Security Pipeline Components for Gitlab | |||
| Resolved | brennen | T289292 Create Security Team group within gitlab.wikimedia.org | |||
| Resolved | sbassett | T289293 Create initial proof of concept application security pipeline repository | |||
| Resolved | sbassett | T301832 Create phan/phan-taint-check plugin port as ci template |
Event Timeline
Comment Actions
fairly tightly-coupled with phan/mediawiki-phan-config
It's obviously coupled with phan itself, but not with the MW phan config; in fact, I've been working on making taint-check as easy as possible to use in non-MW projects. That said, it does need to read the .phan/config.php file for the repo you run it on. I think it should be relatively simple to copy what the phan-docker job does, which is essentially:
- Install PHP, composer, and php-ast
- composer install
- composer phan if it exists, or vendor/bin/phan --long-progress-bar --color otherwise
Comment Actions
Ok, thanks, @Daimona. Yes, we'd definitely like to keep this as trivial a port as possible. So if that just means using the phan-docker images and running phan with phan-taint-check, that sounds good to me.
Comment Actions
Sure, it should be possible to keep it quite trivial, and build it from scratch if necessary. We could pair on that if you want, I should be able to help with the taint-check part (but not much with gitlab CI unfortunately).
Comment Actions
@Daimona - That would be nice - let me know schedule-wise what works for you, and I can put maybe 30-40 mins on our calendars. I'm US CST. Also, just to give you an idea of the current architecture, the Security-Team has been building out (what we hope) are fairly lightweight yaml templates which should be easily-configurable and includable within proper gitlab-ci.yml files for repos migrating to gitlab.wikimedia.org. We're trying to limit this to simple security tools, to get us a little bit of security automation in ci, while not stepping on the toes of other, non-security-related wikimedia ci, which we assume will be migrated over separately at some point.
Comment Actions
Feel free to book any free slot on my calendar, anything in the range 9AM - 7PM UTC should be fine.
Also, just to give you an idea of the current architecture, the Security-Team has been building out (what we hope) are fairly lightweight yaml templates which should be easily-configurable and includable within proper gitlab-ci.yml files for repos migrating to gitlab.wikimedia.org. We're trying to limit this to simple security tools, to get us a little bit of security automation in ci, while not stepping on the toes of other, non-security-related wikimedia ci, which we assume will be migrated over separately at some point.
Thanks for the context! As I said, I have almost no idea how gitlab CI works, but I'm sure it won't be hard to get taint-check running there.
Comment Actions
I added my work account to the event since I don't use the calendar with my volunteer account. Also... I have a meeting at that time, would it be possible to meet 1 hour later or reschedule?
Comment Actions
Had a good meeting with @Daimona (thanks!) to discuss some of the specifics around porting this functionality over to a Gitlab CI template. Primary considerations are going to be:
- Accounting for php version differences, which should be addressed by the flexibility of requiring template users to specify the specific docker-reigstry.w.o docker image they would like to use within various templates. We'll want to provide guidance for this within our AppSec CI templates doc.
- Finding the least ugly way to build out a testable MediaWiki installation for various extensions and skins which might be evaluated by phan-taint-check. Gitlab CI's default behavior is to build out a workspace, of sorts, of a given repository's code and then run various CI-related tests, etc. against the set of relevant changes for a given merge request, etc. Gitlab also supports concepts like multi-project pipelines, though that solves a slightly different problem than what we are talking about here. I'm also not certain we'd want to handle this within a build stage, as I had wanted to keep security-related tests as decoupled from that stage as possible for simplicity's sake.
Comment Actions
Well, I now have something that works, for the most part. Sample job output showing phan-taint-check running under phan and finding an obvious XSS. One note: I had success with the releng/composer-php80 image here, largely because mediawiki/mediawiki-phan-config 0.11.1 seems to want phan/phan 5.2.0 which wants symfony/deprecation-contracts v3.0.0 which demands php >=8.0.2, according to sundry job outputs.
Comment Actions
I'm going to call a first version of this done, for now. The template currently has support for MediaWiki extensions and skins as well as "general php applications". There are a couple of to-dos and we need to eventually support MediaWiki core, by itself, but that's not an immediate worry IMO, so I'll file another bug for those issues.