Phpcs Security Audit Laravel Package

Technical Evaluation

Architecture Fit

• Static Analysis Tooling: The package integrates seamlessly with PHP_CodeSniffer (PHPCS), a mature static analysis tool already used in Laravel ecosystems (e.g., via squizlabs/php_codesniffer or dealerdirect/phpcodesniffer-composer-installer). It extends PHPCS’s rule engine without requiring architectural changes to Laravel’s core or CI/CD pipelines.
• Security-Focused: Aligns with Laravel’s security-first philosophy (e.g., Blade templating, input validation, dependency checks). Complements existing tools like PHPStan, Psalm, or Laravel’s built-in security middleware.
• Framework Agnostic: While Drupal-specific rules exist, the core rules (e.g., XSS, SQLi, RCE) are universally applicable to Laravel. Customization via CmsFramework parameter allows framework-specific tuning.

Integration Feasibility

• Low Coupling: Runs as a pre-commit hook, CI step (GitHub Actions, GitLab CI), or local dev tool without modifying Laravel’s runtime. Example:

  # GitHub Actions example
  - name: Run PHPCS Security Audit
    run: vendor/bin/phpcs --standard=vendor/pheromone/phpcs-security-audit/example_base_ruleset.xml --runtime-set=ParanoiaMode 1 app/
  

• Dependency Overhead: Minimal—only requires pheromone/phpcs-security-audit and squizlabs/php_codesniffer (already common in PHP projects). No Laravel-specific dependencies.
• Output Integration: PHPCS generates machine-readable XML/JSON and human-readable CLI output, enabling:
  • Slack/Email alerts for critical findings (e.g., ERROR level).
  • GitHub PR annotations (via tools like phpcs-to-github).
  • Custom dashboards (e.g., Grafana + Prometheus for trend analysis).

Technical Risk

Key Questions

1. Prioritization:

   • Which security rules are most critical for your Laravel app? (e.g., XSS in Blade templates vs. SQLi in queries).
   • Should this replace or complement existing tools (e.g., laravel-shift/blueprint, roave/security-advisories)?

2. Customization:

   • Do you need Laravel-specific rules? If so, how will you extend Utils.php to handle Laravel’s input methods (e.g., request()->input())?
   • How will you tune false positives? (e.g., suppress warnings for known-safe patterns like htmlspecialchars() in Blade).

3. CI/CD Integration:

   • Where in the pipeline should this run? (e.g., pre-commit vs. post-merge).
   • How will you fail builds on critical findings? (e.g., ERROR level only).

4. Maintenance:

   • Who will update rules as PHP/Laravel evolves? (e.g., PHP 8.2’s new features).
   • How will you handle rule drift (e.g., new CVEs not covered by the 2019 release)?

5. Scalability:

   • How will performance impact large teams or monorepos?
   • Can results be cached to avoid redundant scans?

Integration Approach

Stack Fit

• PHP_CodeSniffer Ecosystem:
  • PHPCS: Already a standard in PHP projects (e.g., WordPress, Drupal, Laravel via dealerdirect/phpcodesniffer-composer-installer).
  • Composer: Install via composer require --dev pheromone/phpcs-security-audit (note: current Composer install may fail; use Git clone as fallback).
  • CI Tools: Native support in GitHub Actions, GitLab CI, Jenkins, etc.
• Laravel-Specific:
  • Blade Templates: Rules for XSS in Blade (e.g., unescaped {!! $input !!}).
  • Eloquent/Query Builder: Detects SQLi risks (e.g., dynamic queries with user input).
  • Request Handling: Flags unsafe input methods (e.g., $_GET/$_POST without validation).
• Complementary Tools:
  • PHPStan/Psalm: For type-level security (e.g., @noRce).
  • Laravel Pint: For code style (non-security).
  • SensioLabs Security Checker: For dependency vulnerabilities.

Migration Path

1. Assessment Phase:

   • Run a one-time audit on a sample of Laravel code to identify:
     • False positives/negatives.
     • Rule coverage gaps (e.g., missing Laravel-specific checks).
   • Example command:

     vendor/bin/phpcs --standard=vendor/pheromone/phpcs-security-audit/example_base_ruleset.xml \
       --runtime-set=ParanoiaMode 0 \
       --report=json > phpcs-audit.json
     

2. Customization:

   • Extend Utils.php for Laravel-specific input detection:

     // app/Sniffs/Laravel/Utils.php
     namespace App\Sniffs\Laravel;
     use Pheromone\SecurityAudit\Utils;
     
     class Utils extends \Pheromone\SecurityAudit\Utils {
         public static function is_direct_user_input($var) {
             if (parent::is_direct_user_input($var)) {
                 return true;
             }
             // Laravel-specific checks
             return in_array($var, ['request()->input', 'Route::input', 'app(\'request\')->input']);
         }
     }
     

   • Update XML ruleset to include the new framework:

     <config name="CmsFramework" value="Laravel" />
     

3. CI/CD Integration:

   • GitHub Actions Example:

     name: Security Audit
     on: [push, pull_request]
     jobs:
       phpcs:
         runs-on: ubuntu-latest
         steps:
           - uses: actions/checkout@v4
           - uses: shivammathur/setup-php@v2
             with:
               php-version: '8.2'
           - run: composer install
           - run: |
               vendor/bin/phpcs --standard=vendor/pheromone/phpcs-security-audit/example_base_ruleset.xml \
                 --runtime-set=ParanoiaMode 1 \
                 --report=checkstyle > phpcs-results.xml
           - uses: actions/upload-artifact@v3
             with:
               name: phpcs-results
               path: phpcs-results.xml
     

   • Fail on Errors:

     vendor/bin/phpcs --standard=Security --severity=5 app/ || exit 1
     

     (Severity 5 = ERROR level only.)

4. Local Development:

   • Add to composer.json scripts:

     "scripts": {
       "audit": "phpcs --standard=vendor/pheromone/phpcs-security-audit/example_base_ruleset.xml --runtime-set=ParanoiaMode 0 app/"
     }
     

   • Run with:

     composer audit
     

Compatibility