# Skulitech ERP Audit Remediation and Validation Report

**Release date:** 13 July 2026  
**Source package remediated:** `Skulitech_application_form_back_to_apply_removed.zip`  
**Audit implemented:** `Skulitech_system_audit_report_2026-07-13.md`  
**Release classification:** Hardened release candidate requiring live MySQL/browser acceptance testing

## 1. Executive result

The critical, high-severity, medium-severity and low-severity findings in the audit were implemented at source-code and database-definition level. The work also corrected additional destructive GET actions, a student-progression academic-year default, nested form risks found during remediation, and offline asset dependencies.

The application is now structurally safer and more consistent, but it is **not represented as production-certified** because this build environment did not contain MySQL/MariaDB, the PDO MySQL driver, a browser automation stack or `mysqldump`/`mariadb-dump`. A staging deployment must still complete role-by-role and database-backed acceptance tests.

## 2. Audit finding implementation matrix

| Finding | Status | Implementation |
|---|---|---|
| C-01 Unsafe public uploads | Implemented | Central MIME/extension validation, size limits, random filenames, image/document allow-lists, permission controls and upload-folder script-execution restrictions. Direct upload operations now exist only in the central security helper. |
| C-02 Public SQL, logs and backups | Implemented | Added root/private-folder access rules; moved schema, migrations, diagnostics and legacy reports into protected directories; removed public sample exports; placed snapshots and full backups under private storage; added permission-checked snapshot download. |
| C-03 Weak public application tracking | Implemented | Cryptographically random application numbers, secondary phone/email/ID-suffix verification, masked contact details, per-IP and per-identifier throttling, honeypot fields and secure non-expiring signed admission-letter links that remain valid while the application is approved. |
| H-01 Session/report filter collision | Fixed | Independent session and semester/module variables now flow through SQL, display, print and export URLs. |
| H-02 Timetable deletion CSRF failure | Fixed | Timetable, rule, venue and slot deletion use POST, CSRF, permission checks, dependency checks and audit logging. |
| H-03 Schema drift | Implemented | Added numbered migration, migration runner, 104-table current clean-install schema and all runtime-required tables/columns. Production request-time DDL is disabled by default. |
| H-04 Academic seed inconsistency | Fixed | Canonical 2025/2026 academic year, Session 3 and module seed values; invalid `2026/2027 Academic Year` values removed; ID backfill/cleanup added. |
| H-05 Missing foreign keys | Implemented | Added 55 named foreign keys across core academic, audit, finance, library and clearance relationships, with explicit delete/update policies. |
| H-06 Unsafe user deletion | Fixed | Operational users are deactivated/reactivated rather than deleted; current user and last active System Administrator are protected. |
| M-01 Hard-coded grading threshold | Fixed | Added central configurable competency pass mark and applied it to marks, marksheets, analytics, reports and progression. |
| M-02 Inconsistent password rules | Fixed | One 10-character upper/lower/number policy is used by setup, profile and administrative password workflows. |
| M-03 Predictable temporary passwords | Fixed | Random temporary passwords are generated, shown through short-lived administrator-only slips and require first-login replacement. |
| M-04 Non-functional remember-me option | Fixed | Removed rather than implementing an unsafe pseudo-persistent session. |
| M-05 Request-time schema mutations | Implemented | Numbered migrations and clean schema added; schema mutations are blocked in production web requests unless explicitly enabled for a controlled migration context. |
| M-06 API token in URL | Fixed | API token authentication accepts the `X-API-Token` header only. |
| M-07 Misleading partial backups | Fixed | Diagnostic output is named and stored as a private snapshot; full compressed backup, optional encryption, checksum, retention and verification CLI tools were added. |
| M-08 Missing headers/cookie hardening | Implemented | Central CSP, clickjacking, MIME-sniffing, referrer, permissions and HTTPS/HSTS controls plus Secure/HttpOnly/SameSite session-cookie defaults. |
| M-09 Public-form abuse controls | Implemented | Application, tracking and forgotten-password flows use identifier/IP quotas, generic failures and invisible accessible honeypot controls. |
| M-10 External CDN dependency | Fixed | Bootstrap, Bootstrap Icons and jQuery are bundled locally. |
| L-01 Branding inconsistency | Fixed | Standardised the product as **Skulitech ERP** and retained institution branding through Institution Settings. |
| L-02 Deployment clutter | Fixed | Historical reports moved under protected legacy documentation; public logs, SQL copies, sample exports and temporary audit artifacts removed. |

## 3. Additional improvements made during remediation

- Converted further destructive actions in academic class/unit assignment, examination routines, lecturer allocation and student activation/deactivation to CSRF-protected POST operations.
- Corrected the student-progression page to default to the active academic year rather than the active session text.
- Corrected nested form structures introduced by action-button hardening.
- Added persistent application-secret support through `APP_KEY`, with a private generated key fallback when writable storage is available.
- Added CLI tools for migration, first-administrator creation, integrity checking, full database backup and backup verification.
- Added Apache protection rules and an equivalent Nginx configuration example.
- Preserved the redesigned two-column public application form, Skulitech background and the user-requested removal of the large banner, brand header and Back to Apply button.


## 3A. Sponsor funds and accrual-accounting extension

The finance module now supports HELB, County bursaries, NG-CDF bursaries, scholarships and other funding sources through a controlled one-receipt-to-many-students model.

Implemented controls include:

- Optional accrued sponsor award and sponsor receivable recognition.
- One official bank/cheque receipt with globally unique transaction-reference protection.
- Manual, CSV and XLSX batch allocation to registered students.
- Parent-receipt balance reservation and over-allocation blocking.
- Balanced ledger posting for award accrual, cash receipt and student allocation.
- Non-cash sponsor credits in student statements, excluded from cashier/bank receipt totals.
- Batch and receipt reversal workflows with preserved audit trails.
- Sponsor control reporting with opening balance, current-period receipts, current-period allocations and closing unallocated balance.
- Sponsor-integrity checks covering orphan lines, source mismatches, missing journals, batch totals and receipt over-allocation.

Targeted static checks passed **11/11 sponsor controls**, and both sponsor allocation templates were parsed successfully by the application’s own CSV/XLSX reader.

## 4. Final static validation results

| Validation | Result |
|---|---:|
| PHP syntax | **181/181 passed** on PHP 8.4.16 |
| Main JavaScript syntax | **Passed** |
| CSS brace integrity | **Passed** for application, Bootstrap and Bootstrap Icons stylesheets |
| Literal POST forms | **190 checked; 0 without explicit CSRF field/helper** |
| Literal nested forms | **0 detected** |
| Current clean-install schema tables | **109** |
| Runtime-created table names found in PHP | **83 unique; 0 missing from current schema** |
| Runtime column requirements found in PHP | **230 unique; 0 missing from current schema** |
| Foreign-key constraints | **65; 0 duplicate constraint names** |
| Definite missing internal static files/routes | **0 detected** |
| XLSX templates/assets | **21/21 valid ZIP containers** |
| CSV files/templates | **21 checked; 0 empty/bad headers** |
| Runtime CDN dependencies | **0 detected** |
| Direct upload calls outside central helper | **0 detected** |
| Direct literal DDL outside migration runner | **0 detected** |
| Generated private secrets/backups included in release | **0** |
| Sensitive SQL/log/archive files at public root | **0** |
| Migration checksum consistency | **Passed**, including sponsor migration `d7cd8344961a84004b23a5fb7d0bf4b36cf957112f2426023bd9ee67f3478609` |

Pure security-function checks passed for strong/weak password handling, signed-link verification and tamper rejection, phone/email masking, empty/filled honeypot detection, failure-only throttling and all-attempt throttling.

## 5. Required staging acceptance tests

Before using real institutional data:

1. Create a clean staging MySQL/MariaDB database and import `database/schema/college_erp_current.sql`.
2. On an upgrade copy, run `php bin/migrate.php`, then `php bin/check_integrity.php`.
3. Create or reactivate the first administrator with `php bin/create_admin.php`.
4. Test applicant submission, tracking verification and approved admission-letter print access and withdrawal after approval is revoked.
5. Test registrar approval, admission, registration and generated user account.
6. Test teacher class/unit restrictions, marks entry, editing, unlocking, grading, ranking and exports.
7. Test finance billing, receipt, reversal, carry-forward, ledger and report totals.
8. Test HELB/County/NG-CDF/scholarship source setup, accrued award, one bank receipt, CSV/XLSX allocation import, batch posting, student statements, unallocated balance, duplicate-reference blocking and reversals.
9. Test HR, procurement, library and clearance approvals.
10. Verify each role sees and can execute only authorised menus/actions, including direct-URL attempts.
11. Test malicious upload rejection, CSRF rejection, login/request throttling and session-cookie/header behaviour over HTTPS.
12. Run `php bin/backup_database.php`, verify the produced file, restore it into another blank database, and compare record counts and financial totals.
13. Review PDF/print output and mobile layouts in current Chrome, Edge and Firefox.

## 6. Deployment notes

- Configure `APP_ENV=production` and a strong random `APP_KEY` in the hosting environment.
- Keep `SKULITECH_RUNTIME_SCHEMA_SYNC` disabled in production.
- Force HTTPS and confirm Apache `.htaccess` is enabled, or apply `docs/nginx-skulitech.conf.example` on Nginx.
- Grant schema-altering database privileges only during controlled installation/migration; use reduced routine privileges afterward.
- Keep backup encryption keys outside the web root and outside the release ZIP.

## 7. Validation limitation

The static checks prove that files parse, expected schema definitions are present and several important security/business-rule functions behave as designed in isolation. They do not prove live SQL compatibility, transaction correctness, browser workflow completion, concurrency safety, email/SMS/payment integrations, production web-server behaviour or restoration fidelity. Those require the staging tests above.
