---
categories: [security]
date: 2026-05-20 00:00:00 +0000 UTC
lastmod: 2026-05-20 00:00:00 +0000 UTC
publishdate: 2026-05-20 00:00:00 +0000 UTC
series: [Security]
slug: firi-independent-security-reviews
tags: [security devsecops fintech crypto aws]
title: Seven Independent Security Reviews of Firi
---

Firi เผยแพร่สถานะความปลอดภัยของบริษัทต่อสาธารณะ นั่นมีความสำคัญ

บริษัทส่วนใหญ่พูดว่า security สำคัญ บริษัทน้อยกว่าที่จะเผยแพร่สรุปการประเมินความปลอดภัยจากบริษัทภายนอกเป็นปีต่อปี โดยเฉพาะในตลาดที่ระบบต้องปกป้องสินทรัพย์ของลูกค้า, fiat rails, การถอน crypto, กระบวนการยืนยันตัวตน, hot และ cold wallets, การดำเนินงานภายใน, โครงสร้างพื้นฐานบนคลาวด์ และ public APIs

Firi ทำเช่นนั้น หน้า security ของพวกเขาระบุการประเมินอิสระและสรุปรายงาน รวมถึงสรุปสาธารณะจาก mnemonic ที่ครอบคลุม AWS security, การทดสอบเว็บแอปพลิเคชัน และการตรวจสอบโค้ด

Firi เป็นลูกค้าของผมมาห้าปี ผมช่วยสร้างและเสริมความแข็งแกร่งให้แพลตฟอร์มนี้ และผมยินดีเสมอที่จะช่วยให้พวกเขาบรรลุระดับของ security engineering ที่มักเกี่ยวข้องกับบริษัทเทคโนโลยีระดับท็อปที่มีขนาดใหญ่กว่า

ดังนั้นผมอ่านรายงานเหล่านั้นแตกต่างจากคำพูดการตลาด รายงานเป็นแรงกดดันภายนอกต่อผลงานวิศวกรรม: ทีมต่างกัน, ปีต่างกัน, แบบจำลองการโจมตีต่างกัน, และคำถามเดิมซ้ำๆ ทุกครั้ง

ระบบนี้จะผ่านการตรวจสอบอย่างจริงจังได้หรือไม่?

สรุปสั้น ๆ: รายงานยังคงพบงานปรับปรุง แต่ก็ยืนยันทิศทางด้วยเช่นกัน ไม่มีการค้นพบระดับ critical หรือ high ในการทบทวนเว็บแอปพลิเคชันและโค้ดปี 2024 มีเพียงการค้นพบระดับ medium, low, และ informational ในการประเมิน AWS ปี 2024 ภาษาในรายงานก่อนหน้าและภายหลังเน้นเรื่องการควบคุมการเข้าถึง, การจัดการ input, ความต้านทานต่อการ injection, การพิสูจน์ตัวตน, และความทนทานด้านฝั่งไคลเอนต์

นั่นคือหลักฐานที่ผมให้ความเคารพ

## The Public Record

หน้า security ของ Firi ระบุว่าบริษัทเสร็จสิ้นการประเมินความปลอดภัยอิสระและการตรวจสอบโค้ด และมีลิงก์ไปยังสรุปสาธารณะ:

- [Firi security page](https://firi.com/no/om-oss/sikkerhet)
- [2024 mnemonic AWS Security Assessment summary](https://cdn.firi.com/docs/20241220_mnemonic_Firi_Report_AWS_Security_Assessment_v1.0__Summary_v2.pdf)
- [2024 mnemonic Security Testing and Code Review summary](https://cdn.firi.com/docs/20241213_Firi_mnemonic_SecurityTesting_Web_CodeReview-1.0__Summary.pdf)

ประวัติสาธารณะที่ผมทำงานจากยังรวมการประเมินเหล่านี้ด้วย:

| Year | Assessment | External reviewer | What stood out |
| --- | --- | --- | --- |
| 2022 | Security test | Netsecurity | Positive observations around access control, injection resistance, and strong authentication. |
| 2022 | Security test | River Security | The application was described as being in a very good security state, with hardened scripts and sanitized input. |
| 2023 | Security test | River Security | The report called out defensive measures that made a real difference. |
| 2024 | Code review | mnemonic | 12 findings, with no critical or high severity findings. |
| 2024 | Infrastructure pentest | mnemonic | 15 findings: 2 medium, 11 low, and 2 informational. |
| 2025 | Internal system pentest | Sygnia | Injection attempts across the application were unsuccessful. |
| 2026 | Proof of Compliance | HackerOne | Compliance validation through HackerOne. |

นี่ไม่ใช่รายการถ้วยรางวัล แต่มันเป็นไทม์ไลน์ที่มีประโยชน์เพราะแสดงการเปิดรับการตรวจสอบภายนอกซ้ำๆ

## What I Take From It

สัญญาณสำคัญไม่ใช่ "ไม่มีการค้นพบใดๆ"

ไม่มีการค้นพบสามารถหมายความว่าระบบแข็งแรงได้ มันก็สามารถหมายความว่า scope เล็กเกินไป, เวลาที่ใช้สั้นเกินไป, ผู้ทดสอบมองไม่เห็นพอ, หรือรายงานหลีกเลี่ยงรายละเอียดที่มีประโยชน์

สัญญาณที่ดีกว่าคือ:

- ผู้ประเมินอิสระกลับมาตรวจซ้ำในหลายปี
- การทดสอบครอบคลุมพฤติกรรมของแอปพลิเคชัน, โค้ด, โครงสร้างพื้นฐาน, และระบบภายใน
- ผลการค้นพบไม่อยู่ในช่วง critical และ high ในสรุปสาธารณะปี 2024
- ข้อเสนอแนะกล่าวถึงการเสริมความแข็งแกร่ง, การทำ sanitize, การพิสูจน์ตัวตน, และการควบคุมป้องกันที่ใช้งานได้จริงซ้ำๆ
- บริษัทยอมเผยแพร่สรุปแทนการซ่อนกระบวนการ

นั่นคือสิ่งที่ความปลอดภัยที่มีวุฒิภาวะเป็นในทางปฏิบัติ ไม่สมบูรณ์แบบ ไม่จบ แต่ถูกทดสอบ ถูกปรับปรุง และถูกตรวจสอบอีกครั้ง

## Why This Was Hard

Firi ไม่ใช่ผลิตภัณฑ์ CRUD ธรรมดา

มันอยู่ในโดเมนความปลอดภัยที่ซับซ้อน ผลิตภัณฑ์มี UX สำหรับผู้บริโภค, กระแสการเงิน, การเก็บรักษา crypto, การยืนยันตัวตน, การเซ็นต์, การควบคุมการถอน, เครื่องมือภายใน, และโครงสร้างพื้นฐานบนคลาวด์ นั่นสร้างวิธีล้มเหลวได้หลากหลาย:

- account takeover
- broken access control
- injection
- insecure wallet operations
- weak approval workflows
- cloud misconfiguration
- secret leakage
- unsafe internal tooling
- poor auditability

ปัญหาทางวิศวกรรมไม่ใช่การเพิ่มฟีเจอร์ความปลอดภัยหนึ่งอย่าง ปัญหาคือทำให้การควบคุมที่น่าเบื่อหลายอย่างทำงานร่วมกัน:

- authentication ที่ยากจะบายพาส
- authorization ที่ถูกตรวจสอบฝั่งเซิร์ฟเวอร์
- การจัดการ input ที่ไม่ไว้วางใจไคลเอนต์
- กระบวนการถอนที่ต้องการการยืนยันที่เข้มแข็ง
- infrastructure ที่ปฏิบัติตาม least privilege
- secrets ที่ไม่ถูกเปิดเผยโดยง่าย
- logging ที่ช่วยการสอบสวนโดยไม่รั่วไหลข้อมูลสำคัญ
- กระบวนการปฏิบัติการที่ไม่พึ่งพาบุคคลคนเดียวให้ทำสิ่งที่ถูกต้องด้วยตนเอง

นั่นคือการทำงาน

## Security Is a Direction, Not a Certificate

รายงาน mnemonic ปี 2024 เป็นตัวอย่างที่ดีของวิธีที่ผมชอบพูดถึง security

สรุปเว็บและการตรวจสอบโค้ดกล่าวว่า mnemonic บันทึก 12 การค้นพบและไม่พบการค้นพบระดับ critical หรือ high severity นั่นแข็งแกร่ง มันยังกล่าวว่ามีการค้นพบระดับ medium, low, และ informational นั่นเป็นเรื่องปกติ การตรวจสอบอย่างจริงจังควรพบสิ่งที่ต้องปรับปรุง

สรุปการประเมิน AWS กล่าวว่า mnemonic พบ 15 ปัญหาด้านความปลอดภัย รวมถึงสองปัญหาระดับ medium และสิบเอ็ดปัญหาระดับ low มันยังกล่าวว่า IAM strategy ดูแข็งแรงและคิดมาดี แม้จะยังแนะนำการปรับปรุง

นั่นคือการทำงานด้าน security อย่างซื่อสัตย์: รับทราบสถาปัตยกรรมที่ดี แล้วแก้ความเสี่ยงที่เหลือ

ผมไว้วางใจวิธีนั้นมากกว่าสโลแกนสะอาดๆ

## The Engineering Lesson

บทเรียนที่ผมได้จากการประเมินเหล่านี้เรียบง่าย:

Security ต้องถูกออกแบบเข้าไปในระบบก่อนการตรวจสอบ

ถ้าคุณรอจนการทดสอบภายนอกเริ่ม คุณมาสายแล้ว ตอนนั้นสถาปัตยกรรมมีอยู่แล้ว โมเดลการพิสูจน์ตัวตนมีอยู่แล้ว ขอบเขตข้อมูลมีอยู่แล้ว ทางลัดในการปฏิบัติการมีอยู่แล้ว

การทดสอบภายนอกไม่ใช่จุดเริ่มต้นของ security แต่มันคือที่สมมติฐานของคุณถูกโจมตี

นั่นคือเหตุผลที่ผมสนใจนิสัยวิศวกรรมที่น่าเบื่อ:

- พื้นที่โจมตีขนาดเล็ก
- ขอบเขตความเชื่อที่ชัดเจน
- least-privilege IAM
- การตรวจสอบแบบ deterministic
- ค่าเริ่มต้นแบบป้องกัน
- code review ที่ถามว่า feature จะถูกเอาไปทำร้ายอย่างไร
- การทบทวน infrastructure ก่อนการเปลี่ยนแปลงสู่ production
- logging ที่มุ่งเหตุการณ์
- เอกสารกระบวนการปฏิบัติการ

นิสัยเหล่านี้ไม่ให้ภาพหน้าจอที่น่าตื่นเต้น แต่ให้รายงานที่ผู้ตรวจสอบอย่างจริงจังยากที่จะหาทางที่สร้างผลกระทบสูง

นั่นคือชัยชนะ

## What This Does Not Prove

ผมต้องการชัดเจนตรงนี้

รายงานเหล่านี้ไม่พิสูจน์ว่า Firi หรือระบบใดๆ ปลอดภัยแบบถาวร พวกมันไม่พิสูจน์ว่าทุกคอมโพเนนต์อยู่ในขอบเขตทุกปี พวกมันไม่ลบความจำเป็นของการเฝ้าระวังอย่างต่อเนื่อง, การแพตช์, การทบทวนภายใน, การตอบสนองต่อเหตุการณ์, และการประเมินใหม่ๆ

พวกมันพิสูจน์บางอย่างที่แคบกว่าและมีประโยชน์กว่า:

แพลตฟอร์มที่มีความอ่อนไหวด้านความปลอดภัยได้รับการทดสอบซ้ำโดยบริษัทอิสระหลายแห่งในหลายปี และสรุปสาธารณะแสดงระบบที่มีวุฒิภาวะด้านการป้องกันที่มีความหมายและไม่มีการค้นพบระดับ critical หรือ high ในการทบทวนแอปพลิเคชันและโค้ดปี 2024

นั่นคือความสำเร็จที่เป็นรูปธรรม

สำหรับผม มันยังเป็นการเตือนความจำว่าการทำ security engineering ที่ดีควรให้ความรู้สึกอย่างไรจากภายนอก: สงบ, ทำซ้ำได้, และยากจะทำลายได้