Q: Does `composer audit` check development dependencies?

By default, yes — composer audit includes packages in require-dev. If you want to skip dev dependencies (since they're not usually in production), run composer audit --no-dev. That said, we'd recommend scanning require-dev packages too, especially phpunit, test helpers, and debugging tools that sometimes get accidentally deployed to production.

Q: Can I use GeekWala for WordPress projects that don't use Composer?

GeekWala scans dependency files, so a WordPress project needs a composer.lock to scan via the Packagist ecosystem. If you're using Bedrock (which uses Composer), you're set. For traditional WordPress installs without Composer, we don't currently support direct wp-content/plugins/ directory scanning. For those setups, WPScan is the specialized tool to use for plugin vulnerability scanning.

Q: What should I do if a vulnerability has no fix available?

Three options: (1) Check if the vulnerable code path is actually reachable in your application — if it requires code patterns you don't use, document that and monitor for when a fix lands. (2) Apply a virtual patch at the WAF or application layer if the vulnerability is exploitable through specific HTTP patterns. (3) Find an alternative package that provides the same functionality without the vulnerability, if the package is unmaintained. Never close the advisory without one of these three outcomes documented.

Question 1

Is `composer audit` enough for production PHP applications?

Accepted Answer

For local development and basic CI gates, yes — it's fast, zero-configuration, and catches known advisories reliably. For production PHP applications where security matters, no. composer audit gives you a vulnerability list but no signal about which vulnerabilities attackers are actually using. You need EPSS and CISA KEV data to prioritize effectively. Running composer audit and patching everything equally is how teams burn out on alert fatigue; running it with EPSS filtering is how teams patch what matters.

Question 2

What's the difference between scanning `composer.json` and `composer.lock`?

Accepted Answer

composer.json contains version constraints (e.g., "laravel/framework": "^10.0"). composer.lock contains the exact resolved versions installed in your environment. Always scan composer.lock. Scanning composer.json constraints forces the scanner to guess at the installed version, which produces false positives and false negatives. If your lock file is absent — for example, in library packages that don't commit lock files — scan with composer install first, then upload the generated lock file.

Question 3

How long does it take for a new PHP vulnerability to appear in `composer audit`?

Accepted Answer

FriendsOfPHP/security-advisories is actively maintained and picks up most disclosures within 24-72 hours. GitHub Security Advisories often faster. For vulnerabilities disclosed directly to package maintainers (coordinated disclosure), they may appear in the advisory database the same day as the patched release. For vulnerabilities discovered by third-party researchers, there can be a lag of days. GeekWala cross-references against OSV and NVD, which occasionally surfaces PHP vulnerabilities before they hit the FriendsOfPHP database.

Question 4

My team has 30 open Composer advisories. Where do we start?

Accepted Answer

Apply the three-signal filter: First, check for any advisories that appear in CISA KEV — patch those within 72 hours regardless of CVSS. Second, sort remaining advisories by EPSS descending and focus on anything above 0.5. Third, from the remaining EPSS < 0.5 advisories, look at the package type: web-facing packages (HTTP, auth, sessions) get elevated priority over internal libraries. For the full framework, see the 3-Signal Triage Method. You'll typically find that out of 30 advisories, 3-5 need urgent action, 10-12 need patches in the next release cycle, and the rest can wait.

Question 5

Does `composer audit` check development dependencies?

Accepted Answer

By default, yes — composer audit includes packages in require-dev. If you want to skip dev dependencies (since they're not usually in production), run composer audit --no-dev. That said, we'd recommend scanning require-dev packages too, especially phpunit, test helpers, and debugging tools that sometimes get accidentally deployed to production.

Question 6

Can I use GeekWala for WordPress projects that don't use Composer?

Accepted Answer

GeekWala scans dependency files, so a WordPress project needs a composer.lock to scan via the Packagist ecosystem. If you're using Bedrock (which uses Composer), you're set. For traditional WordPress installs without Composer, we don't currently support direct wp-content/plugins/ directory scanning. For those setups, WPScan is the specialized tool to use for plugin vulnerability scanning.

Question 7

What should I do if a vulnerability has no fix available?

Accepted Answer

Three options: (1) Check if the vulnerable code path is actually reachable in your application — if it requires code patterns you don't use, document that and monitor for when a fix lands. (2) Apply a virtual patch at the WAF or application layer if the vulnerability is exploitable through specific HTTP patterns. (3) Find an alternative package that provides the same functionality without the vulnerability, if the package is unmaintained. Never close the advisory without one of these three outcomes documented.