Skip to main content

Security Testing Policy

Security Testing Policy

Organization: ALAI Holding AS — Drop Payment App Policy Number: POL-SEC-TEST-001 Version: 1.0 Date: 2026-02-23 Author: ALAI Security Team Status: Draft Reviewers: CISO, Engineering Lead, CTO Next Review: 2027-02-23 (annual) or after Phase 3 CI/CD implementation Classification: Confidential

Document History

Version Date Author Changes
0.1 2026-02-12 Security Agent (ALAI) Initial security audit + gap analysis
1.0 2026-02-23 Security Architect (ALAI) Policy document

Sources: security/drop-security-rapport.md, security/security-hardening-implementation.md, legal/ikt-sikkerhetspolicy.md §10-11, security/hardening-checklist.md

1. Purpose & Scope

Purpose: This policy defines the security testing methodology, tools, frequency, and remediation requirements for all systems operated by ALAI Holding AS for the Drop payment application. Drop processes regulated financial data and is subject to PSD2, GDPR, and DORA requirements — all mandating security testing. No system goes to production without completing applicable security tests.

Scope:

  • All Drop production applications and APIs (getdrop.no, api.getdrop.no)
  • All infrastructure (AWS cloud, Phase 2+)
  • All CI/CD pipelines and build systems
  • All third-party integrations where ALAI controls the integration code (Sumsub webhooks, BankID OIDC, Neonomics PSD2, Swan)
  • All mobile app builds (future)

Policy Owner: Alem Bašić, CISO ([email protected]) Operational Owner: Security team + Engineering

Regulatory basis: DORA Art. 24-27, IKT-forskriften §12, PSD2 Art. 95(2)(e)

2. Security Testing Methodology

Approach: Shift-left security — integrate testing throughout development, not as a gate at the end.

Current MVP state: Security testing performed manually (one audit completed 2026-02-12). Automated pipeline testing is a Phase 3 priority.

Testing layers (current vs target):

Development Phase
    ├── SAST — Manual review (current) → CodeQL / Semgrep automated (Phase 3)
    └── SCA — Manual npm audit (current) → Snyk / Dependabot automated (Phase 3)

Build / CI Phase (Phase 3 — planned)
    ├── SAST — Full scan on every PR
    ├── SCA — Dependency vulnerability + license check
    ├── Container scanning — Image vulnerability analysis
    └── Secret scanning — Detect leaked credentials

Deployment Phase (Phase 3 — planned)
    ├── DAST — Dynamic scan against staging
    └── API security scan — Endpoint validation

Operational Phase
    ├── Vulnerability assessment — External attack surface (quarterly manual)
    ├── Penetration test — Manual expert testing (annual — REQUIRED pre-launch)
    └── Compliance testing — PSD2/GDPR/DORA specific controls

3. Testing Types, Tools & Schedule

3.1 SAST — Static Application Security Testing

Purpose: Detect security vulnerabilities in source code.

Property MVP (Current) Phase 3 Target
Tool Manual code review + npm audit Semgrep or CodeQL
Frequency Per security audit cycle Every commit (incremental) + every PR (full)
Languages TypeScript (Next.js) TypeScript, SQL
Blocking Manual decision YES — PR cannot merge with Critical/High

SAST rules in scope:

  • OWASP Top 10
  • SQL injection (parameterized query enforcement)
  • XSS (innerHTML with user data, unsafe-inline in CSP)
  • Hardcoded credentials / secrets
  • Insecure cryptography (SHA-256 for passwords, MD5, etc.)
  • Authentication and session management flaws
  • Insecure direct object references (missing AND user_id = ?)
  • Path traversal
  • Prototype pollution (JavaScript-specific)

Last manual SAST result (2026-02-12):

  • 4 Critical, 5 High, 6 Medium, 4 Low — before hardening
  • 0 Critical, 0 High, 2 Medium remaining — after hardening (2026-02-13)
  • Source: security/drop-security-rapport.md

3.2 DAST — Dynamic Application Security Testing

Purpose: Detect runtime vulnerabilities by sending attack traffic to a running instance.

Property MVP (Current) Phase 3 Target
Tool Manual pen test OWASP ZAP / Nuclei
Frequency Per security audit cycle Every deployment to staging + weekly
Target Dev environment https://staging.getdrop.no (NEVER production without approval)
Blocking Manual decision YES — deployment halted if Critical

DAST scan scope:

  • All 24 API endpoints (authenticated + unauthenticated)
  • Authentication flows: login, registration, logout, session management
  • Financial endpoints: remittance, qr-payment, balance
  • KYC endpoints: Sumsub webhook verification
  • Security headers presence and correctness
  • SSL/TLS configuration (TLS 1.3, HSTS, correct cipher suites)
  • Rate limiting effectiveness

DAST test credentials: Dedicated test accounts with approved KYC status, seeded with test data only. Never use production user data.

3.3 SCA — Software Composition Analysis

Purpose: Identify known CVEs in open source dependencies.

Property MVP (Current) Phase 3 Target
Tool npm audit (manual) Snyk / GitHub Dependabot
Frequency Ad-hoc Every commit + weekly full scan
Blocking Manual review YES — Critical CVE blocks PR merge

Dependency security posture (audit 2026-02-12): No known vulnerable dependencies identified. All major packages at recent versions.

Package Version Risk
jose ^6.1.3 Low — well-maintained JWT library
bcryptjs ^3.0.3 Low — pure JS bcrypt
better-sqlite3 ^12.6.2 Low — parameterized queries
next 16.1.6 Low — recent version
react 19.2.3 Low — latest major

Approved license list: MIT, Apache 2.0, BSD (2-clause, 3-clause), ISC Requires legal review: GPL, LGPL, AGPL, EUPL

3.4 Container / Infrastructure Scanning (Phase 3)

When Docker/containerization is introduced (Phase 3):

Property Value
Tool Trivy / Grype
Scope All container images + Kubernetes manifests (if used) + Terraform/CDK
Frequency Every image build + daily registry scan
Blocking YES — Critical CVEs in base image block deployment

Container hardening requirements (Phase 3):

  • Non-root user in Dockerfile
  • Read-only root filesystem
  • No secrets in image layers
  • Base image: distroless or Alpine minimal
  • No unnecessary packages

IaC scanning (Phase 3): Checkov or tfsec on all Terraform/CDK code defining AWS infrastructure.

3.5 Penetration Testing

Purpose: Expert manual security assessment simulating a real attacker.

Property Value
Frequency Annual minimum; REQUIRED before first live transaction; after major architectural changes
Scope Full application + API + infrastructure + BankID/Open Banking integration points
Provider External firm — TBD (retainer required before launch)
Methodology OWASP Testing Guide v4.2 + PTES
Rules of engagement Written agreement required before each engagement
Output Full findings report + executive summary + remediation guidance
Blocking Critical findings: system taken offline until remediated

Penetration test scope:

In-scope:
- Production URLs: https://getdrop.no, https://api.getdrop.no
- All authentication flows (login, registration, BankID OIDC — Phase 2)
- All authenticated API endpoints (24 current, more with Phase 2)
- Payment flows: remittance, QR payment initiation
- KYC webhook endpoints (Sumsub)
- Rate limiting bypass attempts
- Session management (JWT, cookie security, revocation)
- Authorization controls (IDOR testing — ALL user-scoped endpoints)
- Open Banking integration (PSD2 consent flow — Phase 2)

Out-of-scope:
- Denial of service attacks
- Social engineering of staff (unless separately scoped)
- Third-party services themselves (AWS, BankID Norge AS, Sumsub infrastructure)
- Production database direct access (test on staging copy only)

Rules of engagement:
- Testing window: agreed in writing before engagement
- Halt immediately on critical finding: contact [email protected] / +47 40 47 42 51
- Non-destructive: no deletion of data, no financial transactions initiated

Required before production launch:

  • Completed penetration test with no unresolved Critical or High findings
  • Source: legal/drop-gap-analysis-v2.md §5 (Phase 3 milestone)

3.6 Red Team Exercises (Phase 3)

Purpose: Adversarial simulation to test detection AND response, not just prevention.

Property Value
Frequency Every 3 years (DORA TLPT requirement for significant entities — DORA Art. 26)
Scope Full kill-chain simulation: initial access → lateral movement → data exfiltration
Provider DORA Art. 26-qualified TLPT provider
Output Red team report + purple team exercise (joint analysis) + Finanstilsynet reporting

DORA TLPT (Threat-Led Penetration Testing):

  • Finanstilsynet may require TLPT once Drop is licensed and reaches significant entity threshold
  • Build TLPT readiness into security program from launch
  • Engage FinansCERT for threat intelligence to inform TLPT scenarios

4. Vulnerability Classification & Remediation SLAs

4.1 Severity Classification (CVSS v3.1)

Severity CVSS Score Definition
Critical 9.0 – 10.0 Remote code execution, full auth bypass, mass data exfiltration without authentication
High 7.0 – 8.9 Privilege escalation, auth bypass (authenticated), significant data exposure
Medium 4.0 – 6.9 Limited data exposure, CSRF, stored XSS, insecure configuration
Low 0.1 – 3.9 Minor information disclosure, theoretical risk
Informational N/A Best practice recommendation, no direct exploitability

4.2 Remediation SLAs

Severity SLA Action on Breach of SLA
Critical Immediate containment in 4h; full remediation in 24 hours CISO + CEO notified. Service taken offline if unmitigable.
High 7 calendar days CISO tracks. Extension requires written justification.
Medium 30 calendar days Engineering lead tracks. Quarterly review.
Low 90 calendar days Backlog. Reviewed in quarterly security review.
Informational Next sprint (best effort) Not SLA-bound.

Source: legal/ikt-sikkerhetspolicy.md §10.2

Exception process: Written request to CISO → approval required → compensating control required → max extension = 1× original SLA

Remediation tracking: GitHub Issues with label security-finding + severity label (Phase 3) / Linear tasks (current).

4.3 Remediation History (2026-02-12 to 2026-02-13)

Finding Severity Remediation Status
C1: Plaintext card data Critical Cards store only last_four + token_ref Resolved
C2: Demo credentials in production seed Critical Seeded behind NODE_ENV !== 'production' Resolved
C3: Demo card data in seed Critical Removed from production path Resolved
C4: SHA-256 password support Critical SHA-256 completely removed, bcrypt only Resolved
C5: Wallet model / top-up endpoint Critical Endpoint removed, pass-through model enforced Resolved
C6: No session revocation Critical Sessions table activated, revocation on every request Resolved
H1/H2: Dual middleware High Consolidated to single implementation Resolved
H4: Input sanitization High Sanitization applied to all text fields Resolved
M5: Notification ID validation Medium Max 100 IDs, format check added Resolved
M6: Currency/language validation Medium Whitelist validation applied Resolved
M1: CSP unsafe-inline Medium Remains (Next.js requirement) — nonce planned Phase 2 Open
M3: X-Forwarded-For trust Medium Requires load balancer — planned Phase 2 Open

Source: security/security-hardening-implementation.md

5. Security Code Review Checklist

Every PR touching authentication, authorization, payment processing, PII handling, or cryptography requires a security review:

Authentication & Authorization:

  • No hardcoded credentials or secrets in code
  • Password hashing uses bcrypt (cost ≥ 12) — never SHA-256, MD5, or plaintext
  • JWT validation: signature (jose library), expiry, algorithm (HS256 explicit)
  • Authorization checked on EVERY protected endpoint — AND user_id = ? in all data queries
  • No role escalation via user-supplied input
  • Session tokens invalidated server-side on logout (revoked = 1)
  • Rate limiting applied to auth endpoints (10 req/60s enforced)
  • CSRF: Origin header validated + sameSite:strict cookie

Input Validation:

  • All user inputs validated (type, length, format, allowed values)
  • Parameterized queries for ALL database operations (? placeholders — no string SQL concat)
  • Text fields sanitized via sanitizeText() (HTML tags stripped)
  • Amounts validated: positive, finite (Number.isFinite()), max 2 decimal places, within limits
  • Currency values validated against whitelist (EUR, USD, GBP, BAM, CHF, PLN, NOK, RSD, TRY, PKR)
  • Language values validated against whitelist (nb, en, bs, sq)
  • IBAN validated: format + checksum
  • No eval(), exec(), or shell command interpolation with user input

Cryptography:

  • No MD5, SHA-1, DES, RC4, or ECB mode
  • Random values generated with crypto.randomBytes() (OS CSPRNG)
  • JWT uses jose library with explicit setProtectedHeader({ alg: 'HS256' })
  • Private keys / JWT_SECRET not in source code, logs, or API responses
  • Cookies: httpOnly:true, secure:true, sameSite:strict

Error Handling:

  • No stack traces or internal details in API error responses (HTTP 500 returns generic message)
  • Errors logged to Sentry internally but not exposed to client
  • No user enumeration (same response for "user not found" and "wrong password")
  • Financial errors: generic message to user, detailed log server-side

Data Handling:

  • Fødselsnummer never logged or returned in API responses
  • Card numbers masked in responses (**** **** **** XXXX)
  • Bank account numbers masked in responses (last 4 only)
  • PII not in query parameters (use POST body)
  • AML-relevant data: never delete without 5-year retention check

PSD2 / Financial:

  • Remittance: amount between 100 and 50,000 NOK enforced server-side
  • QR payment: amount between 1 and 100,000 NOK enforced server-side
  • Transaction uses SQLite IMMEDIATE transaction isolation (atomic balance deduction)
  • WHERE balance >= ? included in all balance-deduction queries (overdraw prevention)
  • Feature flags checked before serving gated features

Dependencies:

  • New dependency reviewed for known CVEs (npm audit) before adding
  • No end-of-life dependencies introduced
  • License compatible with MIT (approved list)

6. Bug Bounty Program

Status: PLANNED — not yet active. To be launched with Phase 2 (alongside live transactions).

Planned platform: TBD (HackerOne, Intigriti, or private program) Planned scope: getdrop.no, api.getdrop.no — all authenticated endpoints

Planned reward structure:

Severity Reward
Critical 10,000 – 50,000 NOK
High 2,500 – 10,000 NOK
Medium 500 – 2,500 NOK
Low Acknowledgment only

Safe harbor: Researchers acting in good faith under the disclosure policy will be protected from legal action.

Responsible disclosure (interim — before formal bug bounty): Security researchers may report vulnerabilities to: [email protected] ([email protected]) Response commitment: Acknowledgment within 1 business day, triage within 5 business days.

7. Security Testing in CI/CD Pipeline (Phase 3 Target)

Developer Commit
  → Pre-commit hook: SAST incremental scan (Semgrep)
  → Git Push

Pull Request
  → SAST: Full scan (CodeQL or Semgrep)
  → SCA: npm audit + Snyk dependency check
  → Secret scanning: GitGuardian or GitHub secret scanning
  → IaC scanning: Checkov/tfsec (when AWS Terraform introduced)
  → All pass → Build container

Container Build
  → Trivy scan for CVEs in base image + packages
  → Pass → Deploy to staging

Staging
  → DAST: OWASP ZAP scan (automated)
  → API endpoint validation
  → Security headers check
  → Pass → Security Gate

Security Gate
  → No Critical/High unresolved → Deploy to production
  → Critical/High found → Block deploy, alert CISO

Pipeline security gate criteria:

Gate Tool Blocking Criteria
Pre-commit SAST (incremental) Critical findings in changed files
PR gate 1 SAST (full) Any Critical or High (unresolved)
PR gate 2 SCA Critical CVE in dependencies
PR gate 3 Secret scan Any detected secret
Post-build Container scan Critical CVE in base image
Post-staging DAST Critical or High dynamic finding

Implementation target: Phase 3 — concurrent with production infrastructure setup.

8. Reporting Format

8.1 Individual Finding Report

Finding ID: VULN-{YEAR}-{SEQUENCE}
Title: {SHORT_DESCRIPTION}
Severity: Critical / High / Medium / Low
CVSS Score: {SCORE} (v3.1)
CVSS Vector: {VECTOR_STRING}
Discovered: {DATE} by {INTERNAL / PENTEST_FIRM}

Description:
{DETAILED_DESCRIPTION}

Affected Systems:
- {SYSTEM}: {URL_OR_CODE_LOCATION}

Proof of Concept:
{STEPS_TO_REPRODUCE}

Impact:
{WHAT_AN_ATTACKER_CAN_DO}

Remediation:
{SPECIFIC_STEPS}

References:
- CWE-{N}: {DESCRIPTION}
- OWASP: {CATEGORY}

Owner: {ASSIGNED_ENGINEER}
SLA Due: {DATE}
Status: Open / In Progress / Resolved / Accepted Risk

8.2 Security Testing Summary Report

Produced after each penetration test and quarterly vulnerability assessment:

Report period: {START} to {END}
Report type: Penetration Test / DAST / Vulnerability Assessment
Conducted by: {INTERNAL / FIRM_NAME}

EXECUTIVE SUMMARY
Total findings: Critical: {N} | High: {N} | Medium: {N} | Low: {N}
Resolved within SLA: {N}/{TOTAL} ({PERCENT}%)
Risk trend vs previous: Improving / Stable / Worsening

TOP FINDINGS
{Table of Critical and High findings}

REMEDIATION STATUS
{Table of all findings with status, owner, SLA}

RECOMMENDATIONS
1. {STRATEGIC_RECOMMENDATION}

9. Metrics & KPIs

Metric Target Reporting
Critical findings resolved within 24h SLA 100% Per finding
High findings resolved within 7-day SLA ≥ 95% Monthly
Mean time to detect (MTTD) < 24 hours Quarterly
MTTR — Critical < 24 hours Monthly
MTTR — High < 7 days Monthly
Deployments with passing security gate (Phase 3) 100% Monthly
Open High+ findings in backlog 0 Monthly
Penetration test — critical findings closed 100% within 30 days Per test
Security code review completion (PRs touching auth/payment) 100% Monthly

Security metrics reporting: Quarterly report to management (Alem Bašić) until dedicated security team hired.

10. Compliance Mapping

Testing Requirement Standard This Policy Section
Annual penetration test IKT-forskriften §12, DORA Art. 24 §3.5
TLPT (Threat-Led Penetration Testing) DORA Art. 26 §3.6
Vulnerability assessment IKT-forskriften §12 §3.1-3.3
Security testing before production PSD2 Art. 95, Finanstilsynet license requirement §3.5
Vulnerability remediation SLAs DORA Art. 9(4)(e), IKT-forskriften §10 §4.2
Security code review IKT-sikkerhetspolicy §7.1 (SSDLC) §5
Incident response testing DORA Art. 25, IKT-forskriften §9 Part of drill schedule in data-breach-response-plan.md §10

Approval

Role Name Date Signature
Author ALAI Security Team 2026-02-23
CISO Alem Bašić
Engineering Lead TBD — hire required
CTO Alem Bašić
Management Alem Bašić
Back to top