Electronically Signed By:
Isa Hasenko
Secure SDLC Policy & Secure Coding Standards
Organization: Fintable, Inc.
Owner: Security & Compliance + Engineering
Review cadence: Annual or upon material change
Approved by: Isa Hasenko
Approval Date: 2025 August 15
1) Purpose & Scope
This document defines Fintable's secure software development lifecycle (SSDLC)
and our secure coding standards for Laravel/PHP applications backed by
PostgreSQL. It applies to all code, pipelines, and infrastructure involved in
building, testing, and operating our services.
2) SDLC Methodology (Security-by-Design)
We use an iterative lifecycle with required security activities at each phase.
2.1) Plan & Requirements
• Define business, privacy, and security requirements; document data
classification and retention per policy.
• Identify abuse cases and regulatory constraints (e.g., GDPR/CCPA where
applicable).
• Security sign-off: requirements reviewed by Security & Compliance for scope,
data flows, and risk.
2.2) Design
• Produce architecture diagrams (trust boundaries, data flows, auth paths).
• Threat modeling for new features/major changes (STRIDE-lite): mitigations
tracked as work items.
• Decide authN/authZ patterns (Laravel Policies/Gates/Sanctum/Passport) and
least-privilege DB roles.
• Define error handling, logging, and data minimization (only store what we
need).
2.3) Implementation
• Coding must follow §4 (Secure Coding Standards).
• Static analysis & style in CI: Pint + PHPStan/Larastan
• Composer dependency management: pin versions, avoid abandoned packages, run
`composer audit`
• Secrets never in source control; use environment variables; .env files not
committed.
• Unit/integration tests for security controls (authZ paths, validation, rate
limits).
2.4) Verification & Security Testing
• Automated: PHPUnit, PHPStan/Larastan, Pint; Composer audit; container/server
baseline checks
• Dynamic: OWASP ZAP (or equivalent) against staging; verify headers, TLS, CSRF,
injection defenses
• Manual: Code review with security checklist (§7).
• Database: Migration review for least-privilege and safe DDL, rollbacks, and
locking behavior.
2.5) Release & Deployment
• CI/CD requires all checks green; signed artifacts; reproducible builds
• Run `php artisan config:cache`, `route:cache`, `view:cache`; verify
`APP_DEBUG=false`
• Zero-downtime or maintenance window with rollback plan; migrations `--force`
and transactional where supported by Postgres.
2.6) Operate & Monitor
• Centralized logging with PII redaction; WAF + iptables in place.
• Security headers enforced (HSTS, CSP, X-Frame-Options, X-Content-Type-Options,
Referrer-Policy).
• Backups tested; vulnerability scanning and patch SLAs tracked. Incident
response per IR plan.
2.7) Retire/Decommission
• Remove routes/credentials; revoke tokens; archive docs; securely delete data
per retention schedules.
3) Roles & Responsibilities
• Engineering: implement standards, tests, reviews, and remediation.
• Security & Compliance: define controls, review designs, threat models, and
exceptions.
• Dev Leads/Reviewers: enforce code review gates and sign off releases.
• All contributors: follow this policy; complete secure coding training
annually.
4) Secure Coding Standards (Laravel/PHP)
4.1) Input Validation & Output Encoding
• Validate all inputs with Form Requests/Validators; use explicit rules (e.g.,
`email:rfc,dns`, `url`, `numeric`, `regex`).
• Encode/escape output via Blade’s `{{ }}`; only use `{!! !!}` for vetted,
sanitized HTML.
• Normalize and limit file uploads (MIME/size/extension), store outside web
root, randomize names; virus-scan if applicable.
4.2) Authentication & Authorization
• Use Laravel's auth features with hashed passwords (`Hash::make`, Argon2id
preferred).
• Implement Gates/Policies for authorization; deny by default.
• Enforce MFA where supported in admin/operator surfaces.
4.3) Session & CSRF
• `APP_KEY` set and protected; secure cookies (`Secure`, `HttpOnly`,
`SameSite=Lax/Strict`).
• `APP_DEBUG=false` in non-local environments.
• CSRF middleware active for state-changing requests.
4.4) Mass Assignment & Model Safety
• Use `$fillable` (prefer) or `$guarded=[]` only with extreme caution; never
trust `request()->all()`.
• Hidden/guarded attributes for sensitive fields; cast types explicitly; soft
deletes where appropriate.
4.5) Database & Query Safety
• Always use Eloquent/Query Builder parameterization—no string-built SQL.
• Transactions around multi-step writes; handle deadlocks/retries.
• Pagination/limits to prevent data scraping; avoid N+1 queries (eager load).
• Migrations: forward-only, reversible where feasible; avoid destructive changes
without data migration steps.
4.6) Cryptography & Secrets
• Use Laravel's Crypt facade for app-level encryption when needed; do not roll
your own crypto.
• Secrets only in environment variables or OS-level secret stores; rotate on
role change or suspicion.
4.7) Error Handling & Logging
• Centralize in `app/Exceptions/Handler.php`; never expose stack traces or SQL
in responses.
• Scrub sensitive fields from logs (passwords, tokens, secrets, PII).
• Do not log full request bodies for auth or payment flows.
4.8) Rate Limiting & Abuse Prevention
• Use `ThrottleRequests` and custom limiters for login, password reset, and
sensitive endpoints.
• Add CAPTCHA/secondary controls on suspicious patterns.
4.9) Security Headers & CORS
• Set strict headers (HSTS, CSP, X-Frame-Options:DENY,
X-Content-Type-Options:nosniff, Referrer-Policy).
• CORS allowlist minimal origins; no wildcard credentials.
4.10) Dangerous Functions & Supply Chain
• Prohibit use of `eval`, `exec`, `shell_exec`, `system`, and backticks.
• Composer: pin versions; avoid unmaintained packages; `composer audit` in CI;
Dependabot (or equivalent).
• Static analysis with Larastan (PHPStan) at level ≥ 6; Laravel Pint for style;
optional Psalm.
4.11) Framework & Tooling
• Disable Telescope/Debugbar in production.
• Use queues for long tasks; validate and sanitize queued job payloads.
• Cache busting and asset integrity (Subresource Integrity if applicable).
5) PostgreSQL Standards
• Connections: TLS to DB; credentials per-service, least privilege; no superuser
in apps.
• Roles/Privileges: separate owner, migration, and runtime roles; `search_path`
locked to expected schemas.
• Schema & Data Integrity: use constraints (PK/FK/unique/check), appropriate
collations/encodings (UTF-8).
• Prepared Statements: always parameterized (Laravel handles automatically).
• Row-Level Security (RLS): consider for multi-tenant or per-account isolation.
• Maintenance: regular VACUUM/ANALYZE; index management and query plans
reviewed.
• Backups: encrypted, tested restores; PITR where needed.
• Logging: enable statement/slow query logging with retention; monitor auth
failures.
6) CI/CD & Quality Gates
• Pipelines must run: PHPUnit (with coverage target), PHPStan/Larastan, Pint,
Composer audit, and security linters.
• Block merges on failing checks or critical/high vulnerabilities without
approved exceptions.
• Artifact signing and provenance; deployment runs DB migrations and health
checks; automatic rollback on failed health.
7) Code Review — Security Checklist (snippet)
• [ ] Validates all input (Form Requests); no `{!! !!}` unsafe output
• [ ] No mass assignment risks; `$fillable` set
• [ ] AuthZ enforced via Policies/Gates; denies by default
• [ ] Queries parameterized; transactions around multi-write flows
• [ ] Secrets not in code; `.env` not committed; `APP_DEBUG=false`
• [ ] Logs scrub sensitive fields; no stack traces exposed
• [ ] Rate limiting present on sensitive endpoints
• [ ] Security headers/CORS correct; file uploads validated
• [ ] Dependency changes audited; new packages vetted
• [ ] Migrations safe, reversible, and least-privilege
8) Vulnerability & Patch Management
• Critical vulns: fix ≤72h (≤24h if exploited); High: ≤7 days; others next
window.
• Monthly dependency review; immediate patch on security advisories affecting
internet-facing components.
9) Training & Awareness
Annual secure coding training and OWASP Top 10 refresher; onboarding within 30
days.
10) Exceptions
Temporary exceptions require Security approval, compensating controls, and an
expiry date; track in the risk register.
11) Document Maintenance
Reviewed at least annually or upon significant changes to frameworks, libraries,
or architecture.
Approved By:
Isa Hasenko
Chief Executive Officer
Electronically Signed By:
Isa Hasenko