--- 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 publishes its security posture publicly. That matters. Most companies say security is important. Fewer companies publish independent security summaries from external firms year after year, especially in a market where the system protects customer assets, fiat rails, crypto withdrawals, identity flows, hot and cold wallets, internal operations, cloud infrastructure, and public APIs. Firi does. Their security page lists independent assessments and report summaries, including public summaries from mnemonic covering AWS security, web application testing, and code review. Firi has been my client for five years. I helped build and harden this platform, and I am always happy to help them reach a level of security engineering that is usually associated with much larger top-tier technology companies. So I read those reports differently than a marketing quote. They are outside pressure on the engineering work: different teams, different years, different attack models, and the same question every time. Can this system stand up to serious review? The short version: the reports kept finding improvement work, but they also kept validating the direction. No critical or high findings in the 2024 web application and code review. Only medium, low, and informational findings in the 2024 AWS security assessment. Strong language across earlier and later reviews about access control, input handling, injection resistance, authentication, and client-side resilience. That is the kind of evidence I respect. ## The Public Record Firi's own security page says the company has completed independent security assessments and code review, and links to public summaries: - [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) The public history I have worked from also includes these assessments: | 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. | This is not a trophy list. It is a useful timeline because it shows repeat exposure to external review. ## What I Take From It The important signal is not "zero findings." Zero findings can mean a system is strong. It can also mean the scope was too small, the timebox was too short, the tester had poor visibility, or the report avoided useful detail. The better signal is this: - independent reviewers came back across multiple years - the testing covered application behavior, code, infrastructure, and internal systems - the findings stayed out of the critical and high range in the public 2024 summaries - the feedback repeatedly mentions hardening, sanitization, authentication, and working defensive controls - the company was willing to publish summaries instead of hiding the process That is what mature security looks like in practice. Not perfect. Not finished. But exposed to pressure, improved, and reviewed again. ## Why This Was Hard Firi is not a simple CRUD product. It sits in a difficult security domain. The product has consumer UX, financial flows, crypto custody, identity verification, signing, withdrawal controls, internal tools, and cloud infrastructure. That creates many ways to fail: - account takeover - broken access control - injection - insecure wallet operations - weak approval workflows - cloud misconfiguration - secret leakage - unsafe internal tooling - poor auditability The engineering problem is not to add one security feature. The engineering problem is to make many boring controls work together: - authentication that is hard to bypass - authorization that is checked server-side - input handling that does not trust clients - withdrawal flows that require strong confirmation - infrastructure that follows least privilege - secrets that are not casually exposed - logging that helps investigation without leaking sensitive data - operational processes that do not depend on one person doing the right thing manually That is the work. ## Security Is a Direction, Not a Certificate The 2024 mnemonic reports are a good example of how I prefer to talk about security. The web and code review summary says mnemonic documented 12 findings and observed no critical or high severity findings. That is strong. It also says there were medium, low, and informational findings. That is normal. A serious review should find things to improve. The AWS assessment summary says mnemonic found 15 security issues, including two medium severity issues and eleven low severity issues. It also says the IAM strategy appeared robust and well thought through, while still recommending improvements. That is honest security work: acknowledge the good architecture, then fix the remaining risk. I trust that more than a clean slogan. ## The Engineering Lesson The lesson I take from these assessments is simple: Security has to be designed into the system before the audit. If you wait until the external test starts, you are too late. By then, the architecture already exists. The authentication model already exists. The data boundaries already exist. The operational shortcuts already exist. External testing is not where security begins. It is where your assumptions get attacked. That is why I care about boring engineering habits: - small attack surfaces - explicit trust boundaries - least-privilege IAM - deterministic validation - defensive defaults - code review that asks how a feature can be abused - infrastructure review before production changes - incident-oriented logging - documented operational procedures These habits do not produce dramatic screenshots. They produce reports where serious reviewers struggle to find high-impact paths. That is the win. ## What This Does Not Prove I want to be precise here. These reports do not prove that Firi, or any system, is permanently secure. They do not prove every component was in scope every year. They do not remove the need for continuous monitoring, patching, internal review, incident response, and new assessments. They prove something narrower and more useful: A security-sensitive platform was repeatedly tested by independent companies, across several years, and the public summaries show a system with meaningful defensive maturity and no critical or high findings in the 2024 application and code review. That is a real achievement. For me, it is also a reminder of what good security engineering should feel like from the outside: calm, repeatable, and hard to break.