Security Testing Policy

Security Testing Policy

Project / Organization: ALAI Holding AS — Drop Payment App Policy Number: POL-SEC-TEST-001 Version: 1.0 Date: 2026-02-23 Author: ALAI Security TeamArchitect 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)	PolicyInitial documentdraft — Drop security testing methodology

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.app. DropSecurity processes regulated financial data andtesting is subject to PSD2, GDPR, and DORA requirementsmandatory — all mandating security testing. Nono system goes to production without completing applicable security tests.

Regulatory basis:

• IKT-forskriften (FOR-2003-05-21-630) §§ 5-6 — ICT security verification
• DORA (EU) 2022/2554 Art. 24-25 — Digital operational resilience testing
• Finanstilsynet licensing requirements — penetration test before production launch
• GDPR Art. 32(1)(d) — regular testing of technical measures

Scope:

• All Drop production applicationsAPIs and APIsendpoints (getdrop.no,no, api.getdrop.no)no)
• All AWS infrastructure (AWSApp cloud,Runner, PhaseS3, 2+)KMS, Secrets Manager)
• All CI/CD pipelines and build systems
• All third-party integrations where(BankID, ALAISumsub, controlsOpen theBanking integration code (Sumsub webhooks, BankID OIDC, Neonomics PSD2, Swan)partners)
• AllDeveloper mobileworkstations apphandling buildsConfidential (future)or Restricted data

Policy Owner: Alem Bašić, CISO (alem@alai.security@getdrop.no) Operational Owner: Security team + Engineering

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

---

2. Security Testing Methodology

Approach: Shift-left security — integratetesting testingintegrated throughout development, not asbolted a gateon 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):layers:

Development Phase
    ├──+-- SASTUnit security tests — Manual reviewVitest (current)current: →20+ CodeQLsecurity-specific /tests)
    Semgrep automated (Phase 3)
    └──+-- SCA — Manual npm audit (current)every →commit, Snykautomated)
    /+-- DependabotSecret automatedscanning — detect leaked credentials (Phaseevery 3)commit)

Build / CI Phase
    (Phase 3 — planned)
    ├──+-- SAST — Fullstatic scancode onanalysis (every PR ├──— planned Phase 2)
    +-- SCA — Dependencydependency vulnerability + license check ├──(every ContainerPR)
    scanning — Image vulnerability analysis
    └──+-- Secret scanning — Detectfull leakedscan credentials(every PR)

Deployment Phase
    (Phase 3 — planned)
    ├──+-- DAST — DynamicOWASP scanZAP against staging └──(planned — Phase 3)
    +-- API security scan — Endpointendpoint validationfuzzing (planned — Phase 3)

Operational Phase
    ├──+-- Vulnerability assessment — Externalexternal attack surface (quarterlyquarterly)
    manual)
    ├──+-- Penetration test — Manualmanual expert testing (annualbefore Phase 3 launch)
    +-- Post-incident review — REQUIREDregression pre-launch)tests └──after Complianceany testingsecurity — PSD2/GDPR/DORA specific controlsincident

---

3. Current Security Test Coverage

3.1 Vitest Unit Security Tests

Status: Implemented — 20+ security-specific tests Source: src/drop-app/src/__tests__/

Test Category	Test	Source
Authentication	JWT secret required in production	auth.test.ts
Authentication	Cookie: httpOnly=true, secure=true, sameSite=strict	auth.test.ts
Authentication	JWT contains setIssuedAt()	auth.test.ts
Authentication	Session revocation: revoked token rejected	auth.test.ts
Authentication	Logout revokes all user sessions	auth.test.ts
Password	bcrypt used — not SHA-256	utils-server.test.ts
Password	bcrypt cost factor >= 12	utils-server.test.ts
Password	SHA-256 hash rejected as invalid (fix C4)	utils-server.test.ts
Input Validation	IBAN checksum validation	validation.test.ts
Input Validation	Currency whitelist enforced	validation.test.ts
Input Validation	Language whitelist enforced	validation.test.ts
Input Validation	Amount: NaN/Infinity rejected	validation.test.ts
Input Validation	HTML tags stripped by sanitizeText()	validation.test.ts
SQL Injection	Parameterized queries for all user inputs	db.test.ts
Rate Limiting	Auth rate limit: 10/60s enforced	middleware.test.ts
Rate Limiting	Transaction rate limit: 10/60s enforced	middleware.test.ts
CSRF	Origin header validated	middleware.test.ts
CSRF	Invalid origin rejected	middleware.test.ts
IDOR	Transaction query scoped to user_id	transactions.test.ts
IDOR	Recipient query scoped to user_id	recipients.test.ts
Feature Flags	Cards endpoint returns 404 when flag disabled	feature-flags.test.ts

3.2 Running the Security Test Suite

# Run all security tests
cd src/drop-app && npx vitest run --reporter verbose

# Run specific security test file
npx vitest run src/__tests__/auth.test.ts

# Run with coverage
npx vitest run --coverage

Blocking criteria: All security tests MUST pass before merge to main branch.

---

4. Testing Types, Tools & Schedule

4.1 SCA — Software Composition Analysis

Status: Implemented (npm audit)

Property	Value
Tool	npm audit (built-in) + GitHub Dependabot (planned)
Frequency	Every commit (pre-commit hook) + every PR
Blocking	YES — Critical CVE blocks merge

Current dependency security status (2026-02-13 audit):

Package	Version	Risk	Status
jose	^6.1.3	Low	No known CVEs
bcryptjs	^3.10.3	Low	No known CVEs
better-sqlite3	^12.6.2	Low	No known CVEs
next	16.1.6	Low	Recent version
react	19.2.3	Low	Latest major
radix-ui	^1.4.3	Low	UI only — no known CVEs

Source: ~/ALAI/products/Drop/security/drop-security-rapport.md

Dependency update policy:

• Security patches (Critical/High): Merge within SLA (see §5)
• Minor security updates: Merge within 14 days
• Major updates: Planned migration within 90 days

Approved licenses: MIT, Apache 2.0, BSD (2-clause, 3-clause), ISC

---

4.2 SAST — Static Application Security Testing

Purpose:Status: DetectPlanned security(Phase vulnerabilities in source code.2)

Property	MVP (Current)	Phase 3 TargetValue
Tool	Manual code review + npm audit	Semgrep or CodeQL (via GitHub Advanced Security)
Frequency	Per security audit cycle	Every commit (incremental) + every PR (full)full scan)
Languages	TypeScript (Next.js)	TypeScript, SQLJavaScript
Blocking	Manual decision	YES — PRCritical cannotor High findings block merge with Critical/High

SAST rules in scope:scope (when implemented):

• OWASP Top 10
• SQL injection detection (parameterized queryqueries enforcement)validation)
• XSSJWT algorithm confusion (innerHTMLalg: withnone user data, unsafe-inline in CSP)detection)
• Hardcoded credentialssecrets / secretscredentials
• Insecure cryptography (SHA-256 for passwords, MD5, etc.)
SHA-1,
• AuthenticationDES, and session management flaws
• Insecure direct object references (missing AND user_id = ?)RC4)
• Path traversal / LFI
• PrototypeIDOR pollutionpatterns (JavaScript-specific)database queries without user_id scoping)
• Missing authentication middleware

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.24.3 DAST — Dynamic Application Security Testing

Purpose:Status: DetectPlanned runtime(Phase vulnerabilities3 by— sendingbefore attackproduction traffic to a running instance.launch)

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

DAST scan scope:

• All 24 API endpoints (authenticated + unauthenticated)
• Authentication flows:flows (login, registration, logout, session managementhandling)
• FinancialRate endpoints:limiting remittance,(verify qr-payment,10/60s balancelimits enforced)
• KYCCSRF endpoints:protection Sumsub(Origin webhookheader verificationvalidation)
• Input validation (IBAN, currency, language, amount)
• Security headers presence and(HSTS, correctnessCSP, X-Frame-Options, etc.)
• SSL/TLS configuration (TLS 1.3, HSTS,no correctTLS cipher suites)1.0/1.1)
• RateJWT limitinghandling effectiveness(expiry, algorithm, revocation)
• Feature flag enforcement (cards endpoints return 404 when disabled)

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.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:Status: ExpertRequired manualbefore securityPhase assessment3 simulatingproduction alaunch real(Finanstilsynet attacker.licensing requirement)

Property	Value
Frequency	AnnualBefore minimum;production REQUIREDlaunch before+ firstannual live transaction; after major architectural changesthereafter
Scope	Full application + API + AWS infrastructure + BankID/Open Banking integration points
Provider	External firm — TBD (retainer required before launch)
Methodology	OWASP Testing Guide v4.2 + PTES
Rules of engagementProvider	WrittenExternal agreementsecurity requiredfirm before(not eachyet engagement
Output	Full findings report + executive summary + remediation guidanceselected)
Blocking	Critical findings: system taken offline until remediated

Penetration test scope:

In-scope:
- Staging pre-launch: https://staging.getdrop.no
- Production URLs:(after launch): https://getdrop.no, https://api.getdrop.no
- All authenticationAuthentication flows (login, registration, BankID OIDC callback — Phase 2)
- All 24 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,handling, revocation)
- AuthorizationRate controlslimiting (IDORand testingCSRF — ALL user-scoped endpoints)protection
- OpenAWS BankingApp integrationRunner (PSD2configuration
consent- flowCloudflare —WAF Phase 2)configuration

Out-of-scope:
- Denial of service attacks
- Social engineering of staff (unlesswithout separatelyprior scoped)approval
- Third-partyAWS servicesinfrastructure themselvesitself (AWS,AWS global responsibility)
- BankID Norge AS,AS systems
- Sumsub infrastructure)
- Production database direct access (test on staging copy only)systems

Rules of engagement:
- Testing window: To be agreed in writing with provider
- Notify before engagementtesting: [email protected]
- Halt immediately on critical finding: contactImmediately alem@alai.notify security@getdrop.no /+ +47 40 47 42 51
- Non-destructive: no deletion of data, no financial transactions initiatedCTO

RequiredKey beforetest productionareas launch:for Drop:

1. CompletedJWT penetrationmanipulation test(algorithm withconfusion, noexpiry unresolvedbypass, Criticalforged or High findingstokens)
2. Source:Session legal/drop-gap-analysis-v2.mdrevocation §5bypass (sessions table manipulation)
3. IDOR attacks (user_id scoping validation across all 24 endpoints)
4. Rate limiting bypass (IP spoofing via X-Forwarded-For)
5. CSRF (Origin header bypass)
6. SQLi in all 24 endpoints (parameterized query verification)
7. BankID OIDC callback manipulation (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 threshold2)
• BuildFeature TLPTflag readinessbypass into(cards securityendpoints programwhen from launchdisabled)
• EngageFoedselsnummer FinansCERTexposure for(ensure threatnever intelligencein toplaintext informlogs TLPTor scenariosAPI responses)

---

4.5. Vulnerability Classification & Remediation SLAs

4.5.1 Severity Classification (CVSS v3.1)

Severity	CVSS Score	Drop-Specific Definition
Critical	9.0 – 0-10.0	Remote code execution, fullRCE, auth bypass,bypass without credentials, mass dataPII exfiltrationexfiltration, withoutJWT authenticationforgery, foedselsnummer exposure
High	7.0 – 0-8.9	Privilege escalation, IDOR (cross-user data access), auth bypass (authenticated), significantSQL data exposureinjection
Medium	4.0 – 0-6.9	Limited data exposure, CSRF, storedreflected XSS, insecurerate configurationlimit bypass, information disclosure
Low	0.1 – 1-3.9	Minor informationVersion disclosure, theoreticalweak riskerror messages, minor misconfigurations
Informational	N/A	Best practice recommendation, no direct exploitabilityrecommendations

4.5.2 Remediation SLAs

Severity	SLA	Action on Breach of SLA
Critical	Immediate containmentContainment in 4h; full remediation in 24 hours	Emergency — CISO + CEOCTO notified.+ ServiceCEO. System taken offline if unmitigable.risk cannot be mitigated.
High	7 calendar days	CISOEscalate tracks.to ExtensionCISO. requiresEngineering writtenLead justification.must approve extension.
Medium	30 calendar days	Engineering leadLead tracks. QuarterlyException review.requires Security team sign-off.
Low	90 calendar days	Backlog.Tracked in 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.mdlabel.

---

5.6. Security Code Review Checklist

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

Authentication & Authorization:

• No hardcoded credentialscredentials, JWT secrets, or secretsAPI in codekeys
• Password hashing uses bcrypt (cost ≥>= 12) — neverSHA-256 SHA-256,explicitly MD5,rejected or(fix plaintextC4)
• JWT validation: signature (jose library),signature, expiry, algorithm (HS256iat explicit)claim verified via jose
• AuthorizationSession checkedrevocation: on EVERYall protected endpointendpoints —check sessions table for AND user_idrevoked = ?0 in all data queries
• No role escalationflags viafrom user-supplied input
• SessionAll tokensprotected invalidatedendpoints server-sidehave onauthentication logoutmiddleware (revoked = 1)applied
• RateLogout limitingrevokes appliedsessions to auth endpointsserver-side (10not req/60sjust enforced)
clears
•  CSRF: Origin header validated + sameSite:strict cookiecookie)

Input Validation:

• All user inputs validated using Drop validators (type,validateAmount, length,validateIBAN, format,validateCurrency, allowedvalidateLanguage, values)sanitizeText)
• Parameterized queries for ALLAll database operations (use parameterized ? placeholdersqueries — no string SQL concat)concatenation
• TextUser fieldsdata sanitizedqueries viainclude sanitizeText()AND user_id = ? (HTML tags stripped)
•  Amounts validated: positive, finitescoping (Number.isFinite()),IDOR 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 + checksumprevention)
• No eval(), exec(), or shell command interpolation with user input

Cryptography:

• No MD5, SHA-1, DES, RC4,RC4 or(per ECBdata-encryption-policy.md mode§2.2)
• Random values generated withuse crypto.randomBytes() (OS— CSPRNG)not Math.random()
• JWTIVs/nonces usesare joserandom library(96-bit withminimum) explicitand setProtectedHeader({never alg: 'HS256' })reused
• PrivateNo cryptographic keys / JWT_SECRET not in source code, logs, or APIerror responses
•  Cookies: httpOnly:true, secure:true, sameSite:strictmessages

Error Handling:

• No stack traces or internal detailspaths in API error responses
•  Generic messages for authentication failures (HTTPno 500user returns generic message)enumeration)
• Errors logged to Sentry internally but not exposed toin client
API
•  No user enumeration (same response for "user not found" and "wrong password")
•  Financial errors: generic message to user, detailed log server-sideresponses

Data Handling:

• FødselsnummerFoedselsnummer nevernot logged orin returnedplaintext (never in APISentry, responsesBetterStack, console.log)
• CardSensitive numbers masked in responses (**** **** **** XXXX)
•  Bank account numbers masked in responses (last 4 only)
•  PIIdata 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 servingany gatedcards-related featuresendpoint
•  AML retention: user data deletion respects 5-year retention (Hvitvaskingsloven § 30)

Dependencies:

• New dependencydependencies reviewed forwith known CVEs (npm audit) before adding
• No end-of-life dependenciespackages introduced
• License compatible with(MIT, MITApache (approved2.0, list)BSD, ISC)

---

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

Current pipeline (Phase 3 Target)MVP):

Developer Commit
    →+-- Pre-commit hook: SASTnpm incremental scanaudit (Semgrep)SCA)
        →|
        v
    Git Push Pull-> RequestPR
        →|
        SAST:v
    FullVitest scansecurity tests (CodeQL20+ ortests)
        Semgrep)|
        → SCA: npm audit + Snyk dependency check
  → Secret scanning: GitGuardian or GitHub secret scanning
  → IaC scanning: Checkov/tfsecv (whenall AWSpass)
    TerraformMerge introduced)to →main
        All|
        pass → Build container

Container Build
  → Trivy scan for CVEs in base image + packages
  → Pass →v
    Deploy to stagingAWS StagingApp →Runner
DAST:

Target pipeline (Phase 2+):

flowchart LR
    COMMIT[Developer\nCommit] -->|Pre-commit| SCA_INC[npm audit\nSCA check]
    SCA_INC -->|Pass| PUSH[Git Push]
    PUSH --> PR[Pull Request]

    PR --> VITEST[Vitest\nSecurity Tests]
    PR --> SAST[SAST\nSemgrep/CodeQL]
    PR --> SCA_FULL[npm audit\nFull scan]
    PR --> SECRET[Secret\nScanning]

    VITEST & SAST & SCA_FULL & SECRET -->|All pass| BUILD[Build\nDrop App]
    BUILD --> STAGING[Deploy to\nStaging]
    STAGING --> DAST[OWASP ZAPZAP\nDAST scanScan]
    (automated)DAST →-->|Pass| APIGATE{Security\nGate}

    endpointGATE validation-->|Pass| → Security headers check
  → Pass → Security Gate

Security Gate
  → No Critical/High unresolved → PROD[Deploy toto\nProduction]
    productionGATE →-->|Fail| Critical/High found → BLOCK[Block deploy,Deploy\nAlert alert CISO[email protected]]

Pipeline security gate criteria:

Gate	Tool	Blocking Criteria
Pre-commit	SASTnpm (incremental)audit	Critical findings in changed filesCVE
PR gate 1	SASTVitest (full)security tests	Any Criticaltest or High (unresolved)failure
PR gate 2	SCASAST (Phase 2)	Critical CVEor inHigh dependenciesfinding
PR gate 3	npm audit full	Critical CVE
PR gate 4	Secret scanscanning	Any detected secret
Post-build	Container scan	Critical CVE in base image
Post-staging	DAST (Phase 3)	Critical or High dynamic finding

---

8. Security Audit History

Date	Type	Provider	Findings	Status
2026-02-12	Full security audit	Internal (Security Architect)	4C / 5H / 6M / 4L	Complete
2026-02-13	Hardening verification	Internal	0C / 0H / 2M / 4L	Complete
TBD (Phase 3)	External penetration test	TBD	—	Planned — required before launch
TBD (Phase 3+)	Annual pentest	TBD	—	Annual thereafter

ImplementationSource: target:~/ALAI/products/Drop/security/drop-security-rapport.md

Security Hardening Summary (2026-02-13)

Finding	ID	Status
Card data: only last_four + token_ref stored (no PAN/CVV)	C1	Resolved
Demo credentials gated behind NODE_ENV !== 'production'	C2	Resolved
SHA-256 password support removed — bcrypt only	C4	Resolved
Session revocation implemented and active	C6/H1	Resolved
Input sanitization applied to all text fields	H4	Resolved
Notification IDs validated (max 100, format check)	M5	Resolved
Settings: currency/language validated against whitelists	M6	Resolved

Remaining items:

—concurrentwithsetup.

Finding	ID	Type	Plan
CSP: unsafe-inline/unsafe-eval required by Next.js	M1	Medium	Nonce-based CSP in Phase 3
Proxy productionHOSTNAME infrastructureconfig	M2	Medium	Resolve in Phase 2 AWS config

---

8.9. Reporting Format

8.9.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:Endpoint / File:
- {SYSTEM}ENDPOINT_OR_FILE}: {URL_OR_CODE_LOCATION}URL_OR_LINE_NUMBER}

Proof of Concept:
{STEPS_TO_REPRODUCE}

Impact:
{WHAT_AN_ATTACKER_CAN_DO}

GDPR/AML Implications:
{IF_PERSONAL_DATA_OR_FINANCIAL_DATA_AFFECTED}

Remediation:
{SPECIFIC_STEPS}

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

Owner: {ASSIGNED_ENGINEER}
SLA Due:Due Date: {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.10. Metrics & KPIs

Metric	Target	Reporting Frequency
Critical findings resolved within 24h SLA	100%	Per findingMonthly
High findings resolved within 7-day SLA	≥ 95%100%	Monthly
MeanVitest timesecurity totest detectpass (MTTD)rate	<100% 24 hours(blocking)	QuarterlyEvery PR
MTTR — Critical	< 24 hours	MonthlyPer incident
MTTR — High	< 7 days	Monthly
DeploymentsOpen withHigh+ passing security gate (Phase 3)findings	100%0 at launch	Monthly
OpenAnnual High+penetration findingstest in backlogcompleted	0Yes (before Phase 3)	MonthlyAnnual
Penetrationnpm testaudit —Critical critical findings closedCVEs	100%0 withinin 30 daysproduction	Per test
Security code review completion (PRs touching auth/payment)	100%	MonthlyContinuous

---

11. Bug Bounty Program

Security metrics reporting:Status: QuarterlyPlanned report(Phase 3 — post-launch) Platform: Intigriti or HackerOne

Responsible disclosure (interim — before bug bounty): Report security vulnerabilities to management (Alem Bašić) until dedicated security team hired.[email protected].

---

10.

Acknowledgment: Compliancewithin Mapping

businessbusinessdaysresearchers faithareprotected

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)	§day Triage: within 5
Incident Safe responseharbor: testing	DORA Art. 25, IKT-forskriften §9	Part of drill scheduleacting in data-breach-response-plan.mdgood §10

from legal action

---

Approval

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