Firi publiserer sin sikkerhetsposisjon offentlig. Det betyr noe.

De fleste selskaper sier at sikkerhet er viktig. Færre selskaper publiserer uavhengige sikkerhetssammendrag fra eksterne firmaer år etter år, spesielt i et marked der systemet beskytter kundeaktiva, fiat-rail, crypto-utbetalinger, identitetsflyter, hot og cold wallets, interne operasjoner, cloud-infrastruktur og offentlige API-er.

Firi gjør det. Deres sikkerhetsside lister uavhengige vurderinger og rapportoppsummeringer, inkludert offentlige sammendrag fra mnemonic som dekker AWS security, web application testing, og code review.

Firi har vært min klient i fem år. Jeg hjalp til med å bygge og hardne denne plattformen, og jeg er alltid glad for å hjelpe dem med å nå et nivå av security engineering som vanligvis forbindes med mye større top-tier teknologiselskaper.

Så jeg leser disse rapportene annerledes enn et markedsføringssitater. De er et ytre press på ingeniørarbeidet: forskjellige team, forskjellige år, forskjellige angrepsmodeller, og det samme spørsmålet hver gang.

Kan dette systemet stå distansen mot en seriøs gjennomgang?

Den korte versjonen: rapportene fortsatte å finne forbedringsarbeid, men de validerte også retningen. Ingen critical eller high funn i 2024 web application og code review. Bare medium, low, og informational funn i 2024 AWS security assessment. Sterkt språk i tidligere og senere gjennomganger om access control, input handling, injection resistance, authentication, og client-side resilience.

Det er den typen bevis jeg respekterer.

The Public Record Lenke til overskrift

Firi’s egen security-side sier at selskapet har fullført uavhengige security assessments og code review, og lenker til offentlige sammendrag:

Den offentlige historikken jeg har jobbet ut fra inkluderer også disse vurderingene:

YearAssessmentExternal reviewerWhat stood out
2022Security testNetsecurityPositive observations around access control, injection resistance, and strong authentication.
2022Security testRiver SecurityThe application was described as being in a very good security state, with hardened scripts and sanitized input.
2023Security testRiver SecurityThe report called out defensive measures that made a real difference.
2024Code reviewmnemonic12 findings, with no critical or high severity findings.
2024Infrastructure pentestmnemonic15 findings: 2 medium, 11 low, and 2 informational.
2025Internal system pentestSygniaInjection attempts across the application were unsuccessful.
2026Proof of ComplianceHackerOneCompliance validation through HackerOne.

Dette er ikke en trofé-liste. Det er en nyttig tidslinje fordi den viser gjentatt eksponering for ekstern gjennomgang.

What I Take From It Lenke til overskrift

Det viktige signalet er ikke “zero findings.”

Zero findings kan bety at et system er sterkt. Det kan også bety at scope var for lite, timeboxen var for kort, testeren hadde dårlig synlighet, eller at rapporten unngikk nyttig detaljer.

Det bedre signalet er dette:

  • independent reviewers kom tilbake over flere år
  • testingen dekket application behavior, code, infrastructure, og internal systems
  • funnene holdt seg unna critical og high i de offentlige 2024-sammendragene
  • tilbakemeldingen nevner gjentatte ganger hardening, sanitization, authentication, og fungerende defensive controls
  • selskapet var villig til å publisere sammendrag i stedet for å skjule prosessen

Det er hvordan moden sikkerhet ser ut i praksis. Ikke perfekt. Ikke ferdig. Men utsatt for press, forbedret, og gjennomgått igjen.

Why This Was Hard Lenke til overskrift

Firi er ikke et enkelt CRUD-produkt.

Det befinner seg i et vanskelig security-domenet. Produktet har consumer UX, financial flows, crypto custody, identity verification, signing, withdrawal controls, internal tools, og cloud infrastructure. Det skaper mange måter å feile på:

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

Ingeniørproblemet er ikke å legge til én security-funksjon. Ingeniørproblemet er å få mange kjedelige controls til å fungere sammen:

  • authentication som er vanskelig å omgå
  • authorization som sjekkes server-side
  • input handling som ikke stoler på clients
  • withdrawal flows som krever sterk bekreftelse
  • infrastructure som følger least privilege
  • secrets som ikke eksponeres tilfeldig
  • logging som hjelper etterforskning uten å lekke sensitive data
  • operational processes som ikke avhenger av at én person gjør det riktige manuelt

Det er jobben.

Security Is a Direction, Not a Certificate Lenke til overskrift

De 2024 mnemonic-rapportene er et godt eksempel på hvordan jeg foretrekker å snakke om security.

Web og code review-sammendraget sier mnemonic dokumenterte 12 funn og observerte ingen critical eller high severity findings. Det er sterkt. Det sier også at det var medium, low, og informational funn. Det er normalt. En seriøs gjennomgang bør finne ting å forbedre.

AWS assessment-sammendraget sier mnemonic fant 15 security issues, inkludert to medium severity issues og elleve low severity issues. Det sier også at IAM-strategien virket robust og gjennomtenkt, samtidig som det anbefalte forbedringer.

Det er ærlig security-arbeid: anerkjenn den gode arkitekturen, og fiks så den gjenværende risikoen.

Jeg stoler på det mer enn en ren slagord.

The Engineering Lesson Lenke til overskrift

Læren jeg tar fra disse vurderingene er enkel:

Security må designes inn i systemet før revisjonen.

Hvis du venter til den eksterne testen starter, er du for sent. Da eksisterer arkitekturen allerede. Authentication-modellen eksisterer allerede. Datagrenser eksisterer allerede. Operasjonelle snarveier eksisterer allerede.

Ekstern testing er ikke hvor security begynner. Det er hvor antakelsene dine blir angrepet.

Derfor bryr jeg meg om kjedelige ingeniørvaner:

  • small attack surfaces
  • explicit trust boundaries
  • least-privilege IAM
  • deterministic validation
  • defensive defaults
  • code review som spør hvordan en funksjon kan misbrukes
  • infrastructure review før produksjonsendringer
  • incident-oriented logging
  • dokumenterte operational procedures

Disse vanene gir ikke dramatiske skjermbilder. De gir rapporter hvor seriøse reviewere sliter med å finne high-impact paths.

Det er gevinsten.

What This Does Not Prove Lenke til overskrift

Jeg vil være presis her.

Disse rapportene beviser ikke at Firi, eller noe system, er permanent secure. De beviser ikke at hver komponent var innenfor scope hvert år. De fjerner ikke behovet for kontinuerlig overvåkning, patching, intern gjennomgang, incident response, og nye vurderinger.

De beviser noe smalere og mer nyttig:

En security-sensitive plattform ble gjentatte ganger testet av uavhengige selskaper, over flere år, og de offentlige sammendragene viser et system med meningsfull defensive modenhet og ingen critical eller high funn i 2024 application og code review.

Det er en reell prestasjon.

For meg er det også en påminnelse om hvordan god security engineering bør føles fra utsiden: rolig, repeterbar, og vanskelig å bryte.