Firi offentliggjør sikkerhetsnivået sitt. Det betyr noe.
De fleste selskaper sier at sikkerhet er viktig. Færre publiserer sammendrag fra uavhengige, eksterne sikkerhetsgjennomganger år etter år — særlig i et marked der systemet beskytter kundemidler, fiat-betalinger, kryptouttak, identitetsflyter, varme og kalde lommebøker, intern drift, skyinfrastruktur og offentlige API-er.
Det gjør Firi. Sikkerhetssiden deres viser uavhengige vurderinger og rapportsammendrag, blant annet offentlige sammendrag fra mnemonic som dekker AWS-sikkerhet, testing av webapplikasjoner og kodegjennomgang.
Firi har vært kunden min i fem år. Jeg har bidratt til å bygge og herde plattformen, og hjelper dem gjerne med å nå et nivå innen sikkerhetsutvikling som vanligvis forbindes med langt større 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 kritiske eller høye funn i 2024 web application og kodegjennomgang. Bare middels, lave, og informative funn i 2024 AWS sikkerhetsvurdering. Sterkt språk i tidligere og senere gjennomganger om access control, behandling av inndata, injection resistance, autentisering, og client-side resilience.
Det er den typen bevis jeg respekterer.
Offentlig dokumentasjon Lenke til overskrift
Firi’s egen sikkerhetsside sier at selskapet har fullført uavhengige sikkerhetsvurderinger og kodegjennomgang, og lenker til offentlige sammendrag:
- Firi sikkerhet page
- 2024 mnemonic AWS Security Assessment summary
- 2024 mnemonic Security Testing and Code Review summary
Den offentlige historikken jeg har jobbet ut fra inkluderer også disse vurderingene:
| År | Vurdering | Ekstern kontrollør | Fremtredende resultat |
|---|---|---|---|
| 2022 | Sikkerhetstest | Netsikkerhet | Positive observasjoner av tilgangskontroll, motstand mot injeksjon og sterk autentisering. |
| 2022 | Sikkerhetstest | River Security | Applikasjonen ble beskrevet som svært godt sikret, med herdede skript og rensede inndata. |
| 2023 | Sikkerhetstest | River Security | Rapporten fremhevet forsvarstiltak som utgjorde en reell forskjell. |
| 2024 | Kodegjennomgang | mnemonic | 12 funn, uten kritiske funn eller funn med høy alvorlighetsgrad. |
| 2024 | Penetrasjonstest av infrastruktur | mnemonic | 15 funn: 2 middels, 11 lave og 2 informative. |
| 2025 | Penetrasjonstest av interne systemer | Sygnia | Ingen av injeksjonsforsøkene i applikasjonen lyktes. |
| 2026 | Proof of Compliance | HackerOne | Validering av etterlevelse gjennom HackerOne. |
Dette er ikke en trofé-liste. Det er en nyttig tidslinje fordi den viser gjentatt eksponering for ekstern gjennomgang.
Dette tar jeg med meg Lenke til overskrift
Det viktige signalet er ikke “null funn.”
Zero funn kan bety at et system er sterkt. Det kan også bety at omfanget var for lite, tidsrammen var for kort, testeren hadde dårlig synlighet, eller at rapporten unngikk nyttig detaljer.
Det bedre signalet er dette:
- uavhengige kontrollører kom tilbake over flere år
- testingen dekket applikasjonsatferd, code, infrastruktur, og interne systemer
- funnene holdt seg unna kritiske og høye i de offentlige 2024-sammendragene
- tilbakemeldingen nevner gjentatte ganger herding, rensing av inndata, autentisering, og fungerende forsvarskontroller
- 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.
Hvorfor dette var krevende Lenke til overskrift
Firi er ikke et enkelt CRUD-produkt.
Det befinner seg i et vanskelig sikkerhetsdomene. Produktet har consumer UX, financial flaves, crypto custody, identity verification, signing, withdrawal controls, internal tools, og cloud infrastruktur. Det skaper mange måter å feile på:
- kontoovertakelse
- sviktende tilgangskontroll
- injeksjon
- usikker håndtering av lommebøker
- svake godkjenningsflyter
- feilkonfigurert skyinfrastruktur
- lekkasje av hemmeligheter
- usikre interne verktøy
- dårlig revisjonsspor
Ingeniørproblemet er ikke å legge til én sikkerhetsfunksjon. Ingeniørproblemet er å få mange kjedelige controls til å fungere sammen:
- autentisering som er vanskelig å omgå
- autorisasjon som sjekkes på serversiden
- behandling av inndata som ikke stoler på klienter
- uttaksflyter som krever sterk bekreftelse
- infrastruktur som følger minste privilegium
- hemmeligheter som ikke eksponeres tilfeldig
- logging som hjelper etterforskning uten å lekke sensitive data
- driftsprosesser som ikke avhenger av at én person gjør det riktige manuelt
Det er jobben.
Sikkerhet er en retning, ikke et sertifikat Lenke til overskrift
De 2024 mnemonic-rapportene er et godt eksempel på hvordan jeg foretrekker å snakke om sikkerhet.
Web og kodegjennomgang-sammendraget sier mnemonic dokumenterte 12 funn og observerte ingen kritiske eller høye severity funn. Det er sterkt. Det sier også at det var middels, lave, og informative funn. Det er normalt. En seriøs gjennomgang bør finne ting å forbedre.
AWS assessment-sammendraget sier mnemonic fant 15 sikkerhetsproblemer, inkludert to middels severity issues og elleve lave severity issues. Det sier også at IAM-strategien virket robust og gjennomtenkt, samtidig som det anbefalte forbedringer.
Det er ærlig sikkerhetsarbeid: anerkjenn den gode arkitekturen, og fiks så den gjenværende risikoen.
Jeg stoler på det mer enn en ren slagord.
Den tekniske lærdommen 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 sikkerhet begynner. Det er hvor antakelsene dine blir angrepet.
Derfor bryr jeg meg om kjedelige ingeniørvaner:
- små angrepsflater
- eksplisitte tillitsgrenser
- IAM med minste privilegium
- deterministisk validering
- sikre standardvalg
- kodegjennomgang som spør hvordan en funksjon kan misbrukes
- gjennomgang av infrastruktur før produksjonsendringer
- hendelsesorientert logging
- dokumenterte driftsprosedyrer
Disse vanene gir ikke dramatiske skjermbilder. De gir rapporter hvor seriøse kontrollører sliter med å finne høye-impact paths.
Det er gevinsten.
Dette beviser ikke rapportene Lenke til overskrift
Jeg vil være presis her.
Disse rapportene beviser ikke at Firi, eller noe system, er permanent sikkert. De beviser ikke at hver komponent var innenfor omfanget hvert år. De fjerner ikke behovet for kontinuerlig overvåkning, patching, intern gjennomgang, hendelseshåndtering, og nye vurderinger.
De beviser noe smalere og mer nyttig:
En sikkerhetssensitiv plattform ble gjentatte ganger testet av uavhengige selskaper, over flere år, og de offentlige sammendragene viser et system med meningsfull defensiv modenhet og ingen kritiske eller høye funn i 2024 application og kodegjennomgang.
Det er en reell prestasjon.
For meg er det også en påminnelse om hvordan god sikkerhetsutvikling bør føles fra utsiden: rolig, repeterbar, og vanskelig å bryte.