Folder structure isn't easy to notice at first. Generally, each folder is a "module" (where framework is core SilverStripe, cms is the CMS part of core SilverStripe, and mysite is the custom code). There's also a /vendor directory that might be used if they're using composer.
If they're using Composer you'll be able to use the composer.json file in the root of the project to determine where some folders are coming from and if they're using official modules, etc. Extra points if you checking their live webserver and find access to it. Information disclosure and all that.
Most of the interesting code will be in mysite/ probably (though worth noting, there's no explicit rule that you have to put your code in a folder called that -- another common option is to put in a folder named after the project). CMS and Framework are the only two modules you probably won't need to audit or worry about, however, it's fairly common for developers (especially ones not familiar with SilverStripe) to edit/modify core code, so it may be in your best interest to figure out what version(s) they're running and do a diff from the official sources. If they're using composer, you can simplify that check by verifying the source it's coming from is the SilverStripe Github repo. Any other modules, regardless of whether they're from SilverStripe or anywhere else, are a good place to find bugs.
As actually auditing the interesting code, normally just head into a folder, /code, and start looking around. Same with most/all frameworks, if you see people writing raw SQL, there's a good chance they're doing things wrong and are going to make lots of mistakes. Missing protection on admin stuff is reasonably common too.
ORM usage looks like ModelName::get()->filter... or DataObject::get('ModelName')->... or sometimes a ->get_by_id or similar function. Any of those are likely to be escaped properly.
There are lots more ways of doing raw SQL (including using the ORM then a ->leftJoin('RAW SQL HERE') or ->where('unescaped sql') calls), so it's just going to take looking at the code to find out what is important or not.
XSS is hardly ever an issue. Main thing to note is that any data users can enter is being stored as varchar/text, not htmltext. SilverStripe's types are used by the templating system to decide whether to escape or not. HTML types aren't escaped, all others are. There are some issues with arrays before 3.1, but since 3.1 (which most new sites should use), it's more strict about always escaping.
Last main issue found in the PHP code is related to allowed_actions. The basic idea is that if a method is in the controller classes allowed_actions property, anyone can call that method from the web with any arguments they want (not always the case, but a good guide). As such, make sure that they're not going to break if anyone does access them (I've seen a decent amount of admin only functionality implemented through there which is going to have major issues if anyone else saw it).
CSRF tokens can be a big issue for certain styles of applications in SilverStripe, as while all POST's are protected, people often use GET calls with side effects, without a CSRF token. In general, a GET request without an explicitly added CSRF token is going to be an issue.
Last place to look for anything interesting might be in the templates, which are found in themes/theme-name/templates/. It's not likely, but if they're using .RAW in there, it won't be escaped. You might notice other weird things in there too, so it's worth looking.
If you're more inclined to just look at the user input areas and wing it, the input can be accessed as both $_REQUEST/$_GET/$_POST, and $request->getVar/postVar/param. It's another good way to find places people are messing with user input.
You can often use the JavaScript/AJAX calls a site has to find potential injection points, since those actions will all be allowed (and generally take user input).