David Mytton, Arcjetin CEO – Haastattelusarja

David Mytton, Arcjetin perustaja ja toimitusjohtaja, johtaa kehittäjien turvallisuusratkaisuihin erikoistunutta startup-yritystä, joka auttaa tiimejä upottamaan sovelluksiin vahvat suojaukset, kuten bottien havaitseminen, nopeusrajoitus, sähköpostin validointi, hyökkäyksen esto ja tietojen poistaminen suoraan sovelluskoodeihin, ollessaan johtajan roolissa kesäkuusta 2023 lähtien. Hän on myös perustanut Console-uutiskirjeen ja -podcastin, toiminut asiantuntijana, kuten Seedcampin asiantuntijana, ja aiemmin johtanut tuotekehitystä StackPathilla, kun hänen pilvitarkkailuyrityksensä myytiin, ylläpitäen vahvaa kiinnostusta kestävään laskentaan ja aktiiviseen kirjoittamiseen teknisiä aiheita.

Arcjet on rakennettu “turvallisuus-kohtaisen” filosofian ympärille, joka mahdollistaa kehittäjien suojelemisen sovelluksia yksinkertaisilla SDK-integraatioilla, asettamalla turvallisuuslogiikan liiketoimintalogiikan rinnalle, jotta voidaan tehdä matalan viiveen, kontekstiaavat päätökset ja poistaa tarve erillisestä infrastruktuurista; alusta tukee suojausten, kuten bottien esto, nopeusrajoitukset ja herkkien tietojen suodatus, ja jatkaa kehittymistä ominaisuuksilla, kuten paikallinen turvallisuusmalli ja laajennettu kehyksen tuki, heijastaen tehtäväänsä tehdä koodin sisäinen turvallisuus oletusarvo modernille sovelluksille. (fly.io)

Olet perustanut Server Densityn aikana, jolloin suorittaa infrastruktuuria suuressa mittakaavassa oli vähemmän standardoitu kuin nykyään, ja lopulta kasvattanut ja myynyt yrityksen. Katsottaessa taakse, mitkä olivat tärkeimmät opit, joita opit kehittäjille rakentamisesta ja tuotantojärjestelmien toiminnasta, ja miten se kokemus on muovannut ajattelutapasi ohjelmistosta nykyään?

Useimmat kehittäjän työkalut voittavat demon ja häviävät tuotannossa. Saada kehittäjä asentamaan mitään uutta on vaikeaa, joten “nopea käynnistys” on oltava kitkaton – mutta se on vain pöytäkirja. Todellinen epäonnistumistapa on se, mitä tapahtuu “se toimii” jälkeen: tuote rajoittuu, joten vakavat tiimit tulevat nopeasti pettyneiksi ja repivät sen irti.

Siksi Arcjetin koodin sisäinen sovelluksen turvallisuus on suunniteltu kahdelle todellisuudelle: tarvitset välittömän korjauskeinon rekisteröintispammiin, tilin petoksiin, bottihyökkäyksiin, API-virheisiin jne., ja tarvitset myös pääsy edistyneisiin ohjauksiin – käyttäjäkohtaisiin kiintiöihin, riskiperusteisiin sääntöihin ja kontekstiaavaisiin päätöksiin – ilman koko ohjelmiston uudelleenkirjoittamista.

Tuote ei ole käyttöliittymä. Tuote on suoritusaika, reunatapaukset, esimerkit ja viiteasiakirjat, joissa kehittäjät voivat luottaa.

Tuleva kokemuksesta, mitä johti sinut perustamaan Arcjetin, ja miksi koit sinun tuntea, että seuraava suuri muutos sovelluksen turvallisuudessa tarvitsi tapahtua koodin sisällä itsessään eikä verkon tai infrastruktuurin tasolla?

Reunamuuri on optimoitu väärään asiaan. Kehittäjät rakentavat ja toimittavat koodissa, ei hallintapaneelissa – ja AI-koodausagentit eivät “selaa” turvallisuuskonsolia suojelemaan sovellusta.

Jos suojauksesi ei voida ilmaista koodina, tarkastella pull-pyynnössä, testata CI:ssä ja käyttää sovelluksen rinnalla, se ei ole “kehittäjän ensisijainen turvallisuus”.

Arcjet on olemassa, koska turvallisuus kuuluu sovelluskerrokselle: versiohallinta, testattavuus, havaittavuus ja lähellä liiketoimintalogiikkaa, jossa todellinen tarkoitus elää.

Arcjet upottaa AI-pohjaisen uhkien havaitsemisen suoraan sovelluksen pyynnön käsittelijöihin. Teknisen näkökulman mukaan, mitkä edut tämä paikallinen, koodin sisäinen lähestymistapa tarjoaa verrattuna perinteisiin reunamuuriin perustuviin turvallisuustyökaluihin?

Pyynnön käsittelijän sisällä sinulla on identiteetti, istunto-tila, ostohistoria, tili-ikä, ominaisuusliput, tietokantatodellisuus. Voit tehdä päätöksen, kuten: “Tämä näyttää outolta, mutta se on uskollinen asiakas – korota todennus sen sijaan, että estät.” Verkkoproksi ei voi tehdä sitä, koska sillä ei ole mitään käsitystä siitä, mikä on “asiakas”.

Tavoitteena ei ole enimmäkseen esto. Tavoitteena on minimoida väärät positiiviset kontekstiaavaisen turvallisuuden avulla, koska kallein turvallisuusvirhe on esto oikean asiakkaan maksamisesta tai lukitseminen oikeasta käyttäjästä.

AI on dramaattisesti muuttanut hyökkäyksen taloutta, bottien skrapauksesta ja rekisteröintispammista automaattiseen API-hyökkäykseen. Mitä hyökkäyksiä näet useimmin tuotannossa tänään, ja miten ne kehittyvät, kun hyökkääjät omaksuvat enemmän kehittyneitä AI-järjestelmiä?

AI:n tuottavuuden hyödyt auttavat myös hyökkääjiä! Suuri muutos on tilavuus ja iterointinopeus: enemmän tunnistekoodin täyttöä, enemmän automaattista rekisteröintispammia, enemmän bottien skrapausta, enemmän API-tutkimusta ja nopeampi “aseiden valmistus” uusille haavoittuvuuksille.

Näemme myös hyökkääjien suorittavan tiukemmat palautekytkentät: he testaavat puolustuksia, sovittavat kehotetta ja lasteja, kierrättävät infrastruktuuria ja jatkavat, kunnes he pääsevät sisään. Se on tällä hetkellä kaikki nopeudesta, ei hienostuneisuudesta.

On edelleen liian vähän ihmisiä, jotka seuraavat parhaita käytäntöjä, kuten salasananhoitajan käyttöä, 2-kertaisen todennuksen käyttöönottoa phish-resistenteillä tunnistekoodilla, kuten avainnapeilla tai kiinteillä avaimilla, ja riippuvuuksien ajan tasalla pitämistä. Kun hyökkäysten määrä kasvaa, se tulee olemaan yhä tärkeämpää.

Yksi suurimmista jännitteistä turvallisuudessa on sovelluksen suojaaminen ilman kehityksen hidastamista. Miten tiimit, jotka käyttävät Arcjetia, ovat pystyneet integroimaan turvallisuuden työprosesseihinsa ylläpitäen nopean julkaisujakson?

Arcjet toimii missä tahansa ympäristössä, myös koodausympäristössä kannettavassa tietokoneessa. Se tarkoittaa, että kehittäjät voivat testata sitä ilman tuotannon käyttöönottoa. Tämä on merkittävä etu, koska voit vahvistaa sen ja osoittaa integraation ilman erityisiä lupia ja ilman vaaraa vaikuttaa tuotantoon. Tämä ratkaisee klassisen ongelman, jossa turvallisuustiimit pakottavat kehittäjiä omaksumaan työkaluja, jotka heikentävät heidän kykyään tehdä työtään.

Arcjet on saavuttanut varhaisen menestyksen AI-käyttökohteen ja e-commerce-alustoilla. Mitkä tekijät tekevät näistä ympäristöistä erityisen haavoittuvia modernille automaattisille hyökkäyksille, ja miksi perinteiset puolustukset eivät yleensä onnistu?

Nämä kaksi kategoriaa jakavat yhtäläisyyden, jossa jokainen väärä pyyntö on suora kustannus.

AI-tuotteet maksavat tokeneista ja päätelystä – hyökkääjät muuttavat voittosi heidän leikkikentäkseen skrapauksen, automaation ja ilmaisen tason viljelyn kautta. E-commerce maksaa petoksista, peruutuksista, varastoinnin väärinkäytöstä ja tilin kaappauksesta. Molemmat ovat hypersensitiivisiä väärille positiivisille, koska oikeiden käyttäjien esto on kirjaimellisesti tulojen menetys.

Perinteiset puolustukset suojaavat pääasiassa kaistanleveyttä ja infrastruktuuria. Modernit hyökkääjät kohdistavat liiketoimintalogiikkaa: rekisteröintivirran, maksuvirran, promo-logiikkaa, tilin palautusta ja API-päätepisteitä. Siksi yleiset reunamuurin ohjaimet ja “ratkaise se CAPTCHAn avulla” kasvavat yhä vähemmän.

Turvallisuusohjelmiston kehittäminen sisältää erilaisia kompromisseja kuin havainnointi tai seuranta. Mitä yllätti sinua eniten turvallisuustuotteen kehittämisestä verrattuna aiempaan kokemukseesi infrastruktuurityökalujen kanssa?

Havainnoinnissa asiakkaat luottavat sinun saatavuuteen. Turvallisuudessa asiakkaat luottavat sinun turvallisuuteen ja siihen, ettei sinusta tule heidän uusin toimitusketjun hyökkäys.

Turvallisuustuotteen rakentaminen tarkoittaa turvallisuusyhtiön pyörittämistä. Käytämme kehyksiä, kuten SOC 2, minimoidaan kolmansien osapuolien riippuvuudet ja kohdellaan kehittäjien kannettavia tietokoneita ja työkalujen pääsyä tuotantovarusteina. Tämä tarkoittaa paljon seurantaa ja nopeita reaktioita mahdollisiin ongelmiin.

Sovellukset riippuvat yhä enemmän AI-agenteista, jotka toimivat käyttäjien puolesta. Miten kehittäjien tulisi miettiä identiteettiä, aikomusta ja luottamusta sovelluskerroksella?

Kun AI-agentit toimivat käyttäjien puolesta, identiteetti loppuu olemasta binäärinen kirjautumistila ja muuttuu valtuutusongelmaksi: kuka toimii, kenen puolesta, millä valtuuksilla, kuinka kauan ja millä rajoituksilla.

Kehittäjien tulisi siirtyä jatkuvaan vahvistamiseen: kohdella jokaista pyyntöä uutena luottamuksellisena päätöksenä perustuen kontekstiin – käyttäjän historia, laitteen signaaleja, istunnon käyttäytymistä ja toiminnan riskiä. “Aikomus” voidaan johtaa käyttäytymisestä ajan myötä, ei otsikkoista.

Tämä tarkoittaa askelten luomista (vahvistus, nopeusrajoitus, kitka) korkean riskin toimien ympärille, kuten salasanan palautus, maksu ja tokenin luominen – ja tee nämä ohjaimet koodin sisällä, jossa sovellus voi erottaa uskollisen asiakkaan botista, jolla on varastettu eväste.

Edetessäsi, miten näet koodin sisäisen, kontekstiaavaisen turvallisuuden kehittyvän seuraavien vuosien aikana, kun AI-luotu liikenne jatkuu kasvamassa?

Reunamuurityökalut eivät katoa – mutta ne tulevat olemaan karkeat suodattimet asioille, jotka käsitellään parhaiten verkon tasolla, kuten DDoS-hyökkäykset. Täsmätarkat päätökset tapahtuvat sovelluksen sisällä, käyttäen todellista kontekstia.

Jos upotettu turvallisuus tulee modernien sovellusten oletusmalliksi, mitä se tarkoittaa kehittäjille, jotka testaavat, käyttöönottoivat ja ajattelevat turvallisuudesta tuotantojärjestelmissä?

Jos upotettu turvallisuus tulee standardiksi, tiimit tulevat testaamaan hyökkäyksiä samalla tavalla kuin he testaavat oikeellisuutta: turvallisuuden yksikkötestit, toistettavat hyökkäysmallit ja CI-tarkastukset riskialttiiden päätepisteiden osalta.

Suurempi muutos on, että AI-koodausagentit toteuttavat turvallisuuden koodina, ei hallintapaneelin konfiguraationa. Agentit voivat ehdottaa, tarkastella ja vahvistaa suojaustoimia vain, kun ohjaimet ovat repositoriossa: käytännöt, säännöt, testit ja instrumentointi. Jos “turvallisuuskerros” on web-käyttöliittymä, agentti ei voi testata muutoksia toimittaa turvallisesti.

Se on todellinen syy, miksi “turvallisuus koodissa” voittaa – se sopii siihen, miten moderni ohjelmisto (ja moderni AI-tukeva kehitys) todella rakennetaan.

Kiitos hienosta haastattelusta, lukijat, jotka haluavat oppia enemmän, voivat vierailla Arcjetissa.