PCI compliance issues

I'm building a new site using Revo 2.2.9 and these two issues have been uncovered by an automated McAfee PCI compliance audit.

I'd appreciate suggestions on how to fix them.

Source code disclosure
General solution: Restrict access or delete unwanted pages that disclose source code.
Can I delete these? Or how do I restrict access?
/core/model/modx/jsonrpc/jsonrpc.inc
/core/model/modx/jsonrpc/jsonrpcs.inc
/core/model/modx/xmlrpc/xmlrpc_wrappers.inc
/core/packages/core/modContext/a7ccc959c8eb6f1841aef706ca1297ee.resolve.core.resolver
/core/packages/core/modContext/ce42ccfd57af2a6d06239446ffa43da5.resolve.core.resolver
/core/packages/core/xPDOFileVehicle/c43a5fb905527546db1541d67a1bbcdd.resolve.core.resolver

Improper error handling
Improper handling of errors can introduce a variety of security problems for a web site. Sometimes misconfiguration or improper code can result in detailed internal error messages such as stack traces, database dumps, and error codes being displayed to the user (hacker).
Other errors can cause the system to crash or consume significant resources, effectively denying or reducing service to legitimate users.
These messages reveal implementation details and provide important clues on potential exploitable flaws to an attacker; not to mention such messages are disturbing to normal users. Also this could mar the confidence a user has in the site leading to loss of revenue as well.
General solution: In the implementation, ensure that the site is built to gracefully handle all possible errors. When errors occur, the site should respond with a specifically designed result that is helpful to the user without revealing unnecessary internal details. We suggest you manually check for its existence by confirming appropriate patches are installed or file redirections, etc. are proper.
/core/components/gallery/
/core/components/getpage/snippet.getpage.php
/core/components/getresources/snippet.getresources.php
/core/components/wayfinder/wayfinder.snippet.php
/core/model/modx/modaccess.class.php
/core/model/modx/modaccessaction.class.php
/core/model/modx/modaccessactiondom.class.php
/core/model/modx/modaccesscategory.class.php
/core/model/modx/modaccesscontext.class.php
/core/model/modx/modaccesselement.class.php

I've a few clients who use MODX without any PCI Compliance problems, so I do know it is possible to pass the scans.

That being said I would recommend upgrading to at least 2.2.11, which should have been the first major flag on your PCI Scan. I'm surprised they focused on other things.

In regards to safely removing/modifying the files in question, a developer will need to respond on that front.

Core files should never be accessible via HTTP requests. This is usually taken care of in .htaccess or other server configuration settings. The core can be moved outside of the web root altogether if desired.

http://rtfm.modx.com/revolution/2.x/administering-your-site/security/hardening-modx-revolution

I think much, if not all, of that would go away if you renamed the ht.access file in the core directory to .htaccess and turned off error reporting for the site.

http://perishablepress.com/advanced-php-error-handling-via-htaccess/

http://php.net/manual/en/function.error-reporting.php

Thanks for the tips everyone.

I've upgraded to 2.2.11, sorted the ht.access/.htaccess thing and turned off error reporting. The scan is running again now. Fingers crossed.