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 ArchitectTeam 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)	InitialPolicy draft — Drop security testing methodologydocument

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 app.application. SecurityDrop testingprocesses regulated financial data and is mandatorysubject to PSD2, GDPR, and DORA requirements — noall mandating security testing. No 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 applications and APIs and(getdrop.no, endpoints (getdrop.no, api.getdrop.no)no)
• All AWS infrastructure (AppAWS Runner,cloud, S3,Phase KMS, Secrets Manager)2+)
• All CI/CD pipelines and build systems
• All third-party integrations where ALAI controls the integration code (BankID,Sumsub Sumsub,webhooks, OpenBankID BankingOIDC, partners)Neonomics PSD2, Swan)
• DeveloperAll workstationsmobile handlingapp Confidentialbuilds or Restricted data(future)

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

Lead

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

---

2. Security Testing Methodology

Approach: Shift-left security — integrate testing integrated throughout development, not boltedas ona 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:layers (current vs target):

Development Phase
    +--├── Unit security testsSAST — VitestManual review (current:current) 20+→ security-specificCodeQL tests)/ +--Semgrep automated (Phase 3)
    └── SCA — Manual npm audit (everycurrent) commit,→ automated)Snyk +--/ SecretDependabot scanning — detect leaked credentialsautomated (everyPhase commit)3)

Build / CI Phase +--(Phase 3 — planned)
    ├── SAST — staticFull codescan analysison (every PR
    — planned Phase 2)
    +--├── SCA — dependencyDependency vulnerability + license check
    (every├── PR)Container +--scanning — Image vulnerability analysis
    └── Secret scanning — fullDetect scanleaked (every PR)credentials

Deployment Phase +--(Phase 3 — planned)
    ├── DAST — OWASPDynamic ZAPscan against staging
    (planned — Phase 3)
    +--└── API security scan — endpointEndpoint fuzzing (planned — Phase 3)validation

Operational Phase
    +--├── Vulnerability assessment — externalExternal attack surface (quarterly)quarterly +--manual)
    ├── Penetration test — manualManual expert testing (before Phase 3 launch)
    +-- Post-incident reviewannual — regressionREQUIRED testspre-launch)
    after└── anyCompliance securitytesting incident— PSD2/GDPR/DORA specific controls

---

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.3.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.0.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

Status:Purpose: PlannedDetect (Phasesecurity 2)vulnerabilities in source code.

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

SAST rules in scope (when implemented):scope:

• OWASP Top 10
• SQL injection detection (parameterized queriesquery validation)enforcement)
• JWT algorithm confusionXSS (alg:innerHTML nonewith detection)user data, unsafe-inline in CSP)
• Hardcoded secretscredentials / credentialssecrets
• Insecure cryptography (SHA-256 for passwords, MD5, SHA-1,etc.)
DES,
• Authentication RC4)and session management flaws
• Insecure direct object references (missing AND user_id = ?)
• Path traversal / LFI
• IDORPrototype patternspollution (database queries without user_id scoping)
• Missing authentication middlewareJavaScript-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

4.33.2 DAST — Dynamic Application Security Testing

Status:Purpose: PlannedDetect (Phaseruntime 3vulnerabilities —by beforesending productionattack launch)traffic to a running instance.

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

DAST scan scope:

• All 24 API endpoints (authenticated + unauthenticated)
• Authentication flowsflows: (login, registration, logout, session handling)management
• RateFinancial limitingendpoints: (verifyremittance, 10/60sqr-payment, limits enforced)balance
• CSRFKYC protectionendpoints: (OriginSumsub headerwebhook validation)
• Input validation (IBAN, currency, language, amount)verification
• Security headers presence (HSTS,and CSP, X-Frame-Options, etc.)correctness
• SSL/TLS configuration (TLS 1.3, noHSTS, TLScorrect 1.0/1.1)cipher suites)
• JWTRate handlinglimiting (expiry, algorithm, revocation)
• Feature flag enforcement (cards endpoints return 404 when disabled)effectiveness

---

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

4.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

Status:Purpose: RequiredExpert beforemanual Phasesecurity 3assessment productionsimulating launcha (Finanstilsynetreal licensing requirement)attacker.

Property	Value
Frequency	BeforeAnnual productionminimum; launchREQUIRED +before annualfirst thereafterlive transaction; after major architectural changes
Scope	Full application + API + AWSinfrastructure infrastructure+ BankID/Open Banking integration points
Provider	External firm — TBD (retainer required before launch)
Methodology	OWASP Testing Guide v4.2 + PTES
ProviderRules of engagement	ExternalWritten securityagreement firmrequired (notbefore yeteach selected)engagement
Output	Full findings report + executive summary + remediation guidance
Blocking	Critical findings: system taken offline until remediated

Penetration test scope:

In-scope:
- Staging pre-launch: https://staging.getdrop.no
- Production (after launch):URLs: https://getdrop.no, https://api.getdrop.no
- AuthenticationAll authentication 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 handling,security, revocation)
- RateAuthorization limitingcontrols and(IDOR CSRFtesting protection— ALL user-scoped endpoints)
- AWSOpen AppBanking Runnerintegration configuration(PSD2 -consent Cloudflareflow WAF— configurationPhase 2)

Out-of-scope:
- Denial of service attacks
- Social engineering of staff without(unless priorseparately approvalscoped)
- AWSThird-party infrastructureservices itselfthemselves (AWS global responsibility)
-AWS, BankID Norge ASAS, systemsSumsub infrastructure)
- SumsubProduction systemsdatabase direct access (test on staging copy only)

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

KeyRequired before production launch:

• Completed penetration test areaswith forno Drop:
  unresolved
  Critical
  1. JWTor manipulationHigh (algorithm confusion, expiry bypass, forged tokens)findings
  2. SessionSource: revocationlegal/drop-gap-analysis-v2.md bypass (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§5 (Phase 2)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
• FeatureBuild flagTLPT bypassreadiness (cardsinto endpointssecurity whenprogram disabled)from launch
• FoedselsnummerEngage exposureFinansCERT (ensurefor neverthreat inintelligence plaintextto logsinform orTLPT API responses)scenarios

---

5.4. Vulnerability Classification & Remediation SLAs

5.4.1 Severity Classification (CVSS v3.1)

Severity	CVSS Score	Drop-Specific Definition
Critical	9.0-0 – 10.0	RCE,Remote code execution, full auth bypass, mass data exfiltration without authentication
High	7.0 – 8.9	Privilege escalation, auth bypass without(authenticated), credentials,significant mass PII exfiltration, JWT forgery, foedselsnummerdata exposure
HighMedium	7.0-8.4.0 – 6.9	Privilege escalation, IDOR (cross-userLimited data access),exposure, authCSRF, bypassstored (authenticated),XSS, SQLinsecure injectionconfiguration
MediumLow	4.0-6.0.1 – 3.9	CSRF, reflected XSS, rate limit bypass,Minor information disclosuredisclosure, theoretical risk
Low	0.1-3.9	Version disclosure, weak error messages, minor misconfigurations
Informational	N/A	Best practice recommendationsrecommendation, no direct exploitability

5.4.2 Remediation SLAs

Severity	SLA	Action on Breach of SLA
Critical	ContainmentImmediate containment in 4h; full remediation in 24 hours	Emergency — CISO + CTOCEO +notified. CEO. SystemService taken offline if risk cannot be mitigated.unmitigable.
High	7 calendar days	EscalateCISO totracks. CISO.Extension Engineeringrequires Leadwritten must approve extension.justification.
Medium	30 calendar days	Engineering Leadlead tracks. ExceptionQuarterly requires Security team sign-off.review.
Low	90 calendar days	Tracked in backlog.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.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

---

6.5. Security Code Review Checklist

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

Authentication & Authorization:

• No hardcoded credentials, JWT secrets,credentials or APIsecrets keysin code
• Password hashing uses bcrypt (cost >=≥ 12) — never SHA-256256, explicitlyMD5, rejectedor (fix C4)plaintext
• JWT validation: signature,signature (jose library), expiry, algorithm (iatHS256 claim verified via joseexplicit)
• SessionAuthorization revocation:checked on EVERY protected endpoint — AND user_id = ? in all protecteddata endpoints check sessions table for revoked = 0queries
• No role flagsescalation fromvia user-supplied input
• AllSession protectedtokens endpointsinvalidated haveserver-side authenticationon middlewarelogout applied(revoked = 1)
• LogoutRate revokeslimiting sessionsapplied server-sideto auth endpoints (not10 justreq/60s clearsenforced)
cookie)
•  CSRF: Origin header validated + sameSite:strict cookie

Input Validation:

• All user inputs validated using(type, Droplength, validatorsformat, (validateAmount,allowed validateIBAN, validateCurrency, validateLanguage, sanitizeText)values)
• AllParameterized queries for ALL database operations use parameterized (? queriesplaceholders — no string concatenationSQL concat)
• UserText datafields queriessanitized includevia AND user_id = ?sanitizeText() scoping(HTML tags stripped)
•  Amounts validated: positive, finite (IDORNumber.isFinite()), prevention)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, RC4RC4, (peror data-encryption-policy.mdECB §2.2)mode
• Random values usegenerated with crypto.randomBytes() —(OS not Math.random()CSPRNG)
• IVs/noncesJWT areuses randomjose (96-bitlibrary minimum)with andexplicit neversetProtectedHeader({ reusedalg: 'HS256' })
• No cryptographicPrivate keys / JWT_SECRET not in source code, logs, or errorAPI messagesresponses
•  Cookies: httpOnly:true, secure:true, sameSite:strict

Error Handling:

• No stack traces or internal pathsdetails in API error responses
•  Generic messages for authentication failures (noHTTP user500 enumeration)returns generic message)
• Errors logged to Sentry internally but not exposed into APIclient
responses
•  No user enumeration (same response for "user not found" and "wrong password")
•  Financial errors: generic message to user, detailed log server-side

Data Handling:

• FoedselsnummerFødselsnummer notnever logged inor plaintext (neverreturned in Sentry,API BetterStack, console.log)responses
• SensitiveCard datanumbers 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 anyserving cards-relatedgated endpoint
•  AML retention: user data deletion respects 5-year retention (Hvitvaskingsloven § 30)features

Dependencies:

• New dependenciesdependency reviewed withfor known CVEs (npm audit) before adding
• No end-of-life packagesdependencies introduced
• License compatible with MIT (MIT,approved Apache 2.0, BSD, ISC)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

Current pipeline (MVP):

Phase 3 Target)

Developer Commit
  +--→ Pre-commit hook: npmSAST auditincremental scan (SCA)Semgrep)
  |
        v→ Git Push

->Pull PRRequest
  |→ vSAST: VitestFull security testsscan (20+CodeQL tests)or |Semgrep)
  v→ SCA: npm audit + Snyk dependency check
  → Secret scanning: GitGuardian or GitHub secret scanning
  → IaC scanning: Checkov/tfsec (allwhen pass)AWS MergeTerraform tointroduced)
  main→ |All vpass → Build container

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

AppStaging
  Runner→ 

DAST:

TargetOWASP pipelineZAP scan (Phaseautomated) 2+):

→

flowchartAPI LRendpoint COMMIT[Developer\nCommit]validation
  -->|Pre-commit|→ SCA_INC[npmSecurity audit\nSCAheaders check]check
  SCA_INC→ -->|Pass|Pass PUSH[Git→ Push]Security PUSHGate

-->Security PR[PullGate
  Request]→ PRNo -->Critical/High VITEST[Vitest\nSecurityunresolved 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]to STAGINGproduction
  -->→ DAST[OWASPCritical/High ZAP\nDASTfound Scan]→ DAST -->|Pass| GATE{Security\nGate}

    GATE -->|Pass| PROD[Deploy to\nProduction]
    GATE -->|Fail| BLOCK[Block Deploy\nAlertdeploy, [email protected]]alert CISO

Pipeline security gate criteria:

Gate	Tool	Blocking Criteria
Pre-commit	npmSAST audit(incremental)	Critical CVEfindings in changed files
PR gate 1	VitestSAST security tests(full)	Any testCritical failureor High (unresolved)
PR gate 2	SAST (Phase 2)SCA	Critical orCVE Highin findingdependencies
PR gate 3	npm audit full	Critical CVE
PR gate 4	Secret scanningscan	Any detected secret
Post-build	Container scan	Critical CVE in base image
Post-staging	DAST (Phase 3)	Critical or High dynamic finding

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

---

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

Source: ~/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:

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

---

9. Reporting Format

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

Proof of Concept:
{STEPS_TO_REPRODUCE}

Impact:
{WHAT_AN_ATTACKER_CAN_DO}

GDPR/AML Implications:
{IF_PERSONAL_DATA_OR_FINANCIAL_DATA_AFFECTED}

Remediation:
{SPECIFIC_FIX}SPECIFIC_STEPS}

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

Owner: {ASSIGNED_ENGINEER}
SLA Due Date: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}

---

10.9. Metrics & KPIs

Metric	Target	Reporting Frequency
Critical findings resolved within 24h SLA	100%	MonthlyPer finding
High findings resolved within 7-day SLA	100%≥ 95%	Monthly
VitestMean securitytime testto passdetect rate(MTTD)	100%< (blocking)24 hours	Every PRQuarterly
MTTR — Critical	< 24 hours	Per incidentMonthly
MTTR — High	< 7 days	Monthly
OpenDeployments High+with findingspassing security gate (Phase 3)	0 at launch100%	Monthly
AnnualOpen penetrationHigh+ testfindings completedin backlog	Yes (before Phase 3)0	AnnualMonthly
npmPenetration audittest Critical— CVEscritical findings closed	0100% inwithin production30 days	ContinuousPer 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.

---

11.10. BugCompliance Bounty ProgramMapping

Status:

Planned —post-launch)Platform:bounty):

Acknowledgment:

within day

Triage:

within5

Safe

areprotectedfrom legal action

Testing Requirement	Standard	This Policy Section
Annual penetration test	IKT-forskriften §12, DORA Art. 24	§3.5
TLPT (PhaseThreat-Led Penetration Testing)	DORA Art. 26	§3.6
Vulnerability assessment	IKT-forskriften §12	§3.1-3.3
Security Intigriti or HackerOne Responsible disclosure (interim —testing before bugproduction	PSD2 ReportArt. security95, vulnerabilitiesFinanstilsynet tolicense [email protected]. requirement	§3.5
Vulnerability remediation SLAs	DORA Art. 9(4)(e), IKT-forskriften §10	§4.2
Security code review	IKT-sikkerhetspolicy §7.1 business(SSDLC)	§5
Incident businessresponse daystesting	DORA harbor:Art. researchers25, actingIKT-forskriften §9	Part of drill schedule in gooddata-breach-response-plan.md faith§10

---

Approval

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