8 · Deep codebase audit

TL;DR

Objective — run a deeper codebase audit while the selected non-production target is live and the stakes are low: project structure, composer security audit, a deployed-vendor/ backdoor-signature re-scan, Git hygiene, FVDUT storage persistence, secret + debug-code scans (with the word-boundary fix for dd()), storage-tracked-file triage, CodeCanyon frontend anti-patterns, and an optional schema audit — so every finding caught here is one that doesn’t surface in production.

Steps at a glance:

1. Verify project structure — Confirm the standard Laravel layout, the artisan version, and the vault .gitignore.
2. Composer security audit — Surface known vulnerabilities in dependencies, fix the urgent ones, and re-verify.
3. Git hygiene — Confirm secrets and heavy trees never entered history.
4. Storage persistence (FVDUT) — FVDUT = Files, Vendors, Directories, Uploads, Temp — folders that must survive a release swap via shared_dirs.
5. Secret + debug-code scans — Scan app code for hardcoded credentials and leftover debug calls.
6. Triage files tracked in storage/ — Files committed under storage/ are ambiguous: Deployer replaces storage/ with a symlink to shared/storage/, so tracked files never reach the running app — but vendor packages often write runtime config to storage_path(''), and deleting those breaks the package silently.
7. CodeCanyon frontend anti-patterns — None block a deploy; all are worth logging as VENDOR/Frontend backlog items.
8. Schema audit — Inspect the selected non-production schema with Atlas or a free tool and categorize tables so you know what’s safe to touch.
9. Database performance baseline — Capture a DB performance baseline and surface obvious slow queries / N+1 patterns before any real traffic arrives — every slow path caught here is one you don’t debug live.
10. Deploy any fixes — Commit any real fixes found above and redeploy.

User part + done-when

👤 User part — none: this audit is entirely terminal-runnable (grep/composer/git/ssh). A person only decides which backlog findings become actual fixes.

Done when structure is verified, composer audit is clean of Critical/High, Git history is free of vendor//node_modules//.env, storage persistence is confirmed, secret + debug scans are clear, storage/-tracked files are triaged, frontend anti-patterns are logged, and any fixes are redeployed.  ·  ⏱ ~1–2 hr  ·  🤖 agent-runnable.

Background

The first live non-production target is the right moment for a thorough codebase audit: the app is deployed and verifiable, but no real users depend on it. Work top to bottom; most findings become backlog items, a few are real fixes you redeploy.

Read Zaj-PROJECT.md first and load the selected non-production row before any redeploy command:

SOURCE_BRANCH="develop" # example; use the selected source branch from Zaj-PROJECT.md
DEPLOY_TARGET="<selected-nonproduction-deploy-target>" # selected Deploy target from Zaj-PROJECT.md
# Expected: values match the environment row being audited

Authority vs this page (don’t triplicate audits)

This is the non-production deep pass (word-boundary dd() scan, git history, FVDUT). Phase 10 · Static audit is the pre-launch authority — run it again before sign-off to confirm production matches the audited commit. Don’t restate a weaker copy in Phase 10; cross-reference this page for debug/history checks Phase 10 omits.

Where this page sits in the phase:

🟡 SHOULD — recommended, not a phase gate

The Phase 5 gate (page 6) already passed. This is a deeper pass best done while the selected non-production target is live and the stakes are low — every finding caught here is one that doesn’t surface in production.

flowchart LR
  NonProd[Non-production deploy live] --> Deep[Deep pass on this page]
  Deep --> Backlog[Most findings → backlog]
  Deep --> Fix[Few fixes → redeploy]
  Deep --> P10[Phase 10 static audit re-verify]

Steps

1. Verify project structure

Confirm the standard Laravel layout, the artisan version, and the vault .gitignore.

1. List the standard directories and the vault ignore.

   ls -la app/ config/ database/ public/ resources/ routes/ storage/
   ls -la artisan composer.json package.json .env.example
   php artisan --version
   cat Admin-Local/1-Project/2-Vault/.gitignore   # expect `*` and `!.gitignore`
   # Expected: all standard dirs/files exist; Laravel version prints; vault ignores all but itself

   • ✅ All standard directories/files exist, Laravel version prints, and the vault .gitignore ignores everything but itself.

2. Composer security audit

Surface known vulnerabilities in dependencies, fix the urgent ones, and re-verify.

1. Run the audit.

   composer audit
   # Expected: a list of advisories (or "No security vulnerability advisories found")

   • ✅ The audit output is reviewed against the severity table.

2. Fix and re-verify the urgent advisories.

   composer update vendor/package && composer audit   # fix + re-verify
   git add composer.json composer.lock && git commit -m "Security: update packages for vulnerability fixes"
   # Expected: re-audit shows the fixed advisory gone; the lockfile change is committed

   • ✅ Critical/High advisories are resolved and the lockfile change is committed.

Triage by severity:

Severity	Action
Critical	Update immediately
High	Update before launch
Medium	Update soon
Low	Track for next release

composer audit finds known CVEs — not author-injected backdoors

composer audit only matches packages against a published-advisory database. It will never flag a CodeCanyon author’s license-injection backdoor or phone-home beacon — those live as edits inside vendor/ with no CVE. The seam audit in Extract & snapshot §5 is what catches those; the next section re-confirms the deployed tree is still clean.

2.5. Re-scan the deployed vendor/ for backdoor signatures

The seam audit in Phase 2 proved a clean tree boots locally. Staging is the first time composer install ran on a real server, and composer install does not replace a package already present at the locked version — so if composer.lock happens to pin a tampered release (or a stale server composer cache served a bad copy), the backdoor rides onto staging silently. Re-run the same signature scan against the deployed tree now, while no real user depends on it.

1. Grep the deployed vendor/ for the known injection fingerprints.

   REL=~/domains/nonprod.example.com/deploy/current
   ssh <non-prod-alias> "set +e
     MATCHES=\$(grep -rIlE 'getCourant|HeaderCodec|envato\.|verify\.js|\\\$\\.getScript|gzinflate|str_rot13' $REL/vendor/ 2>/dev/null)
     STATUS=\$?
     if [ \$STATUS -eq 0 ] && [ -n \"\$MATCHES\" ]; then
       printf '%s\n' \"\$MATCHES\" | sed -n '1,20p'
       echo '  ⚠️ review every hit above against §5 of the Phase-2 seam audit'
       exit 2
     elif [ \$STATUS -eq 1 ]; then
       echo '  ✅ no backdoor signature in the deployed vendor/'
       exit 0
     else
       echo \"STOP — grep failed with status \$STATUS\"
       exit \$STATUS
     fi"
   # Expected: "✅ no backdoor signature..." — any hit exits 2 and must be read + classified before trusting staging

   • ✅ The deployed vendor/ returns no backdoor signature (or every hit is read, classified, and resolved per the Phase-2 seam audit).

   Do not pipe the signature grep directly into head

   grep ... | head reports the pipeline status from head, not from the grep you care about. Capture matches first, test grep’s status, then print a bounded first page only after you know hits exist.

2. If a signature appears, the locked release is tampered — clean it, don’t just composer install.

   # composer install is a NO-OP on an already-installed package — force a reinstall of the flagged package(s):
   ssh <non-prod-alias> "cd $REL && composer reinstall <vendor>/<package> 2>&1 | tail -3"
   # then re-grep to prove the signature is gone:
   ssh <non-prod-alias> "grep -rIlE 'getCourant|HeaderCodec|envato\.|verify\.js' $REL/vendor/ 2>/dev/null \
     && echo '  ❌ still present' || echo '  ✅ signature gone'"
   # Also pin a clean release in composer.lock locally and redeploy, so the next env is clean from the start.

   • ✅ Any flagged package is reinstalled from clean upstream (signature gone), and the clean release is pinned in composer.lock for the next environment.

composer install will NOT clean a tampered locked package

A package already installed at the version in composer.lock is skipped by composer install (“Nothing to install or update”) — the tampered files persist. Use composer reinstall <vendor>/<package> (or rm -rf vendor && composer install) to actually replace the files, then grep-verify. This was runtime-proven: on a real WorkDo project, composer install was a no-op and the beacon survived; composer reinstall of the two tampered packages took the signature from present → gone with the route count unchanged.

3. Git hygiene

Confirm secrets and heavy trees never entered history.

1. Scan history for vendor/, node_modules/, and .env.

   git log --all --full-history -- vendor/ | head -5         # expect empty
   git log --all --full-history -- node_modules/ | head -5   # expect empty
   git log --all --full-history -- .env | head -5            # expect empty
   git log --all --full-history -- ".env.*" | head -5        # expect empty (except .env.example)
   # Expected: all four scans return empty (apart from .env.example)

   • ✅ vendor/, node_modules/, and .env are absent from Git history.

.env in Git history = rotate everything, then scrub

If .env ever appears in history, every credential it held is compromised. Rotate all of them first — DB, mail, API keys, APP_KEY — because scrubbing history does not un-leak anything already pushed.

After rotating, remove the file from history:

pip install git-filter-repo
git filter-repo --path .env --invert-paths
# Then force-push every branch — coordinate with the team first; this rewrites shared history.

Rotation is the real fix; the scrub is hygiene. Never force-push a shared branch without telling collaborators — they must re-clone or hard-reset afterward.

4. Storage persistence (FVDUT)

FVDUT = Files, Vendors, Directories, Uploads, Temp — folders that must survive a release swap via shared_dirs.

1. Confirm shared_dirs covers storage + uploads, and symlinks are present.

   grep -A10 "shared_dirs" deploy.php                  # expect `storage` + any custom upload dirs
   ls -la public/ | grep "^l"                          # local symlinks present
   ssh <non-prod-alias> "ls -la ~/domains/nonprod.example.com/deploy/current/public/ | grep '^l'"
   # Expected: shared_dirs lists storage + uploads; symlinks present locally and on the server

   • ✅ shared_dirs persists storage + uploads and symlinks are present on both ends.

5. Secret + debug-code scans

Scan app code for hardcoded credentials and leftover debug calls.

1. Scan for secrets, debug code, and confirm APP_DEBUG=false.

   grep -rn "password\s*=" --include="*.php" app/ config/ | grep -v ".env\|example\|fake\|test" | head
   grep -rn "api_key\|apikey\|secret_key" --include="*.php" app/ config/ | grep -v ".env\|example" | head
   grep -rn "://.*:.*@" --include="*.php" app/ config/ | head        # credentials in URLs
   
   # Debug code — word-boundary regex so `->add(` does NOT false-positive on `dd(`
   grep -rnE "(^|[^a-zA-Z_>])(dd|dump|var_dump|print_r)\(" --include="*.php" app/ | head
   grep -rn "console.log" resources/js/ | head
   
   ssh <non-prod-alias> "grep APP_DEBUG ~/domains/nonprod.example.com/deploy/shared/.env"   # expect false
   # Expected: no hardcoded secrets, no real debug calls in shipped paths, APP_DEBUG=false

   • ✅ No hardcoded secrets, no debug code in staging paths, and APP_DEBUG=false.

Why the debug grep uses word boundaries

A naive grep "dd(\|dump(" matches the substring dd( anywhere — flagging legitimate $validator->errors()->add(...) and Carbon::now()->add(...) as “debug code.” The ERE above requires dd/dump/etc. to be preceded by start-of-line or a non-identifier character, ruling out ->add(. No ERE support? Use rg '\bdd\(|\bdump\(|\bvar_dump\('.

A related noise source is the server log itself when you scan it for real errors:

Filter your own noise from the log scan

When scanning staging’s laravel.log for real errors, window it to the last ~15 minutes so you don’t panic over exceptions you caused with tinker/SSH during the deploy session:

CUTOFF=$(date -u -v-15M +"%Y-%m-%d %H:%M:%S" 2>/dev/null || date -u -d "15 minutes ago" +"%Y-%m-%d %H:%M:%S")
ssh <non-prod-alias> "awk -v c='$CUTOFF' '/^\[[0-9]{4}-/{ts=substr(\$0,2,19);keep=(ts>c)} keep' \
  ~/domains/nonprod.example.com/deploy/current/storage/logs/laravel.log" | grep -iE 'error|exception|fatal' | tail

6. Triage files tracked in storage/

Files committed under storage/ are ambiguous: Deployer replaces storage/ with a symlink to shared/storage/, so tracked files never reach the running app — but vendor packages often write runtime config to storage_path('<file>'), and deleting those breaks the package silently. This scan is investigation only; the default action for every file is KEEP.

1. List tracked storage/ files and search for their references.

   git ls-files storage/ | grep -vE '\.gitkeep$|\.gitignore$'
   # For each suspect, search reads AND writes across vendor/packages/app:
   #   B=$(basename <FILE>)
   #   grep -rnE "$B|storage_path.*$B|file_put_contents.*$B|->put\(.*$B" vendor/ packages/ app/ config/ routes/
   # Expected: a list of suspect files; default action for each is KEEP

   • ✅ Each tracked storage/ file is triaged (default KEEP) using the reference table.

Classify each suspect:

Reference found in	Action
vendor/ or packages/	KEEP + add to shared_files
app/ / config/ / project code	KEEP + shared_files (or move out of storage/)
Nowhere	Default KEEP; remove only if certain it has no vendor origin — and log it
Uncertain	KEEP + shared_files

Empty content is not proof, and never both lists

An empty []/{}/"" file may still be written by a vendor on first use — a matching file_put_contents/->put() means KEEP. And a file may be in shared_files or inside a shared_dirs directory, never both — listing a storage/ file in shared_files triggers Too many levels of symbolic links at deploy:shared.

7. CodeCanyon frontend anti-patterns

None block a deploy; all are worth logging as VENDOR/Frontend backlog items.

1. Scan for global SDKs, unguarded charts, duplicate includes, and double-registered service workers.

   # Global third-party SDKs that should be route-scoped
   grep -rln "js.stripe.com\|paypal.com/sdk\|checkout.razorpay.com" resources/views/layouts/ resources/views/components/ 2>/dev/null
   # Charts (check for empty-state guards)
   grep -rln "ApexCharts\|Chart.js\|echarts\|chartist" resources/views/ 2>/dev/null
   # Duplicate framework includes
   grep -rcn "@livewireScripts\|livewire.min.js" resources/views/ 2>/dev/null
   # Service worker double-registration
   grep -rn "serviceWorker.register" resources/views/ public/ 2>/dev/null
   # Expected: hits become VENDOR/Frontend backlog items (none block the deploy)

   • ✅ Any anti-pattern hits are logged as VENDOR/Frontend backlog items.

Fixes: scope payment SDKs to checkout via @stack('scripts'); guard charts with @if($data->count()) + a “no data” fallback; keep @livewireScripts in the root layout only; register the service worker once.

8. Schema audit

Inspect the selected non-production schema with Atlas or a free tool and categorize tables so you know what’s safe to touch.

1. Inspect and categorize the selected target tables.

   With Atlas or a free tool (mysqldump --no-data, TablePlus, DBeaver), inspect the selected non-production schema and categorize tables.

   • ✅ Tables are categorized so you know what’s safe to modify.

Category rules:

Category	Examples	Rule
Core vendor	users, settings, payments	NEVER modify
Plugin / feature	ai_*, chat_*, blog_*	Check vendor docs first
Laravel system	migrations, jobs, cache	NEVER modify
Custom (_zaj)	users_zaj, custom_*	Yours — safe to modify

Optional — connect the selected target to Bytebase for schema review

Beyond mysqldump --no-data plus free GUIs (TablePlus, DBeaver, phpMyAdmin), some teams register the selected non-production database in Bytebase for change review. First-time setup is dashboard work:

1. Enable Remote MySQL in the hosting panel.
2. Add the Bytebase Cloud IP to the Remote MySQL allowlist. Get the current Cloud IP from the Bytebase dashboard — do not hardcode it.
3. Copy host / port / database / username / password from the hosting panel.
4. In Bytebase Cloud: Settings → Instances → Add Instance, configure, and test the connection.

This is user/dashboard work, not agent-runnable. Skip entirely if you use a local GUI.

9. Database performance baseline

Capture a DB performance baseline and surface obvious slow queries / N+1 patterns before any real traffic arrives — every slow path caught here is one you don’t debug live.

Keep the password out of ps aux and history

Inline -p<pass> leaks the password to every other user on the box. Prefer a mode-600 ~/.my.cnf; the commands below show explicit flags for clarity only.

1. Check the slow query log and threshold.

   ssh <non-prod-alias> "mysql -e \"SHOW VARIABLES LIKE 'slow_query_log%'; SHOW VARIABLES LIKE 'long_query_time';\""
   ssh <non-prod-alias> "tail -100 /var/log/mysql/mysql-slow.log 2>/dev/null \
     || echo 'Slow query log not accessible on shared hosting — use EXPLAIN on hot queries instead'"
   # Expected: the log's on/off state + threshold, or a fallback note for shared hosting

   • ✅ You know whether the slow query log is available.

2. EXPLAIN a hot query and list the largest tables.

   ssh <non-prod-alias> "mysql DB_NAME -e \"EXPLAIN SELECT * FROM HOT_TABLE WHERE HOT_COL = 1 LIMIT 10;\""
   ssh <non-prod-alias> "mysql -e \"SELECT table_name, table_rows FROM information_schema.tables \
     WHERE table_schema=DATABASE() ORDER BY table_rows DESC LIMIT 10;\""
   # Expected: hot table uses an index (`key` is not NULL); top tables are recorded

   • ✅ Hot tables use indexes and the heaviest tables are recorded.

If Debugbar or Telescope is installed on staging, hit the dashboard and two or three list pages as an authenticated user and record: no single query > 1s, no N+1 pattern, hot tables show key used in EXPLAIN, and average page query count is reasonable.

Record in the current 90-DevLog/Sessions/ note (DATABASE/Performance): homepage query count ___, dashboard query count ___, slowest observed query ___ ms. If any tuning work remains, add it to Zaj-BACKLOG.md with owner, trigger, and acceptance criterion.

10. Deploy any fixes

Commit any real fixes found above and redeploy.

1. Commit and redeploy the audit fixes.

   git add . && git commit -m "Audit: investigation fixes — <describe>"
   git push origin "$SOURCE_BRANCH" && dep deploy "$DEPLOY_TARGET"
   # Expected: fixes committed, pushed, and redeployed to the selected non-production target

   • ✅ Any audit fixes are committed and redeployed.

Checklist

Do not mark this step done until every box below is checked.

• 🤖 Structure + audit — structure verified; composer audit clean of Critical/High.
• 🤖 Deployed vendor/ clean — backdoor-signature grep over the server’s installed vendor/ returns nothing (or any hit was reinstalled from clean upstream and re-verified).
• 🤖 Git history clean — vendor/, node_modules/, .env absent from Git history.
• 🤖 Storage persists — shared_dirs persists storage + uploads; symlinks present on server.
• 🤖 No secrets / debug — no hardcoded secrets; no debug code in staging paths; APP_DEBUG=false.
• 🤖 Triage + anti-patterns — storage/-tracked files triaged (default KEEP); frontend anti-patterns logged.
• 🤖 Fixes redeployed — any fixes committed and redeployed.

→Next step

Atlas Cloud