Cum să rămâneți în vârful securității în 2023

Securitatea și performanța sunt piatra de temelie pentru fiecare proiect, site, aplicație și componentă pe care o dezvoltați. Dar, în acest peisaj în continuă schimbare, poate fi o provocare să rămânem la curent cu cele mai bune practici fundamentale, în timp ce inovăm.

În această conversație, auziți de la cei mai buni tehnologi despre cum se mențin la vârf de securitate și performanță în 2023.

Difuzoare:

• Ramadass Prabhakar, SVP și Chief Technology Officer la WP Engine
• Lawrence Edmondson, CTO la Barbarian
• Sergi Isasi, VP Product, Application Performance la Cloudflare
• Tim Nash, consultant de securitate WordPress la timnash.co.uk
• Jimmy Squires, CTO la Space150

Transcriere:

RAMADASS: Bună, tuturor. Bun venit la cea de-a patra ediție a Decode. A fost minunat să vedem creșterea numărului de participanți în fiecare an. În ultimii câțiva ani, a existat o schimbare semnificativă în peisajul securității în industrie. Am văzut buletine de știri regulate despre încălcări ale securității și securitate, deoarece un subiect apare frecvent în discuțiile cu clienții și dezvoltatorii deopotrivă. Așadar, astăzi, am adunat un grup fabulos de experți din industrie pasionați de securitate și sunt aici pentru a răspunde întrebărilor noastre și a ne împărtăși cunoștințele lor. Deci, să începem cu o scurtă introducere pentru membrii noștri. Lawrence, la tine.

LAWRENCE EDMONDSON: Vă mulțumim foarte mult că ne-ați primit. Lawrence Edmondson aici, CTO al Barbarian. Barbarian este o agenție digitală cu servicii complete. Ne aflăm în New York.

RAMADASS: Mulțumesc, Lawrence. La tine, Sergi.

SERGI ISASI: Mulțumesc. Sunt VP de produse la Cloudflare. Cloudflare, construim produse care fac orice ca clienții și partenerii noștri, cum ar fi WPE, să se conecteze la internet mai sigur și mai rapid, iar eu sunt în San Francisco.

MODERATOR: Mulțumesc, Sergi. Și Tim, la tine.

TIM NASH: Sunt consultant de securitate WordPress aici, în Marea Britanie. Și practic îmi petrec viața speriând dezvoltatorii.

MODERATOR: Mulțumesc. Și Jimmy.

JIMMY SQUIRES: Da, mulțumesc. Sunt cu Space 150, de asemenea, o agenție digitală cu servicii complete din Minneapolis și CTO acolo.

MODERATOR: Vă mulțumim că ați acceptat să faceți parte astăzi la panelul nostru. Așa că aș dori să ne încep să vorbim despre ceva unic pe care îl faceți astăzi în domeniul securității în cadrul organizației dumneavoastră sau în cadrul echipelor dumneavoastră. Deci poate să începem cu Sergi.

SERGI ISASI: Da, voi juca din intro-ul lui Tim, unde el sperie dezvoltatorii. Unul dintre lucrurile pe care încercăm să le facem mai mult la Cloudflare este să oferim clienților noștri mai multe informații despre traficul lor și să reducem sarcina operațională. Așadar, din punct de vedere istoric, dacă ați dori să găsiți ce ar putea afecta rețeaua dvs., ce v-ar putea ataca, ați implementa un WAF, l-ați pune în modul jurnal și apoi ați pune un analist de securitate să se uite la jurnalele și vezi ce a detectat. Și există mult mai puține resurse pentru a face asta în zilele noastre.

Prin urmare, accentul nostru pentru acest an este să oferim clienților noștri informații despre atacurile pe care le vedem asupra lor, chiar dacă nu folosesc produsul care ar preveni acest atac astăzi. Astfel, ei pot ști dacă aplicația lor este atacată sau, în general, este în stare bună. Și acesta este obiectivul nostru pentru restul anului, prezentând toate produsele noastre de securitate și anunțând clienților noștri ce s-ar putea întâmpla sau ce se întâmplă de fapt în rețeaua lor și dacă doresc sau nu să o blocheze.

MODERATOR: Minunat. Sună cu adevărat puternic. Aștept cu nerăbdare să aud mai multe despre asta. Deci, Tim, ce zici de tine?

TIM NASH: Deci lucrez cu o mulțime de clienți diferiți, atât agenții, dar și site-uri web individuale mai mici. Și fac o mulțime de recenzii de cod și de site-uri. Și până în acest an, nu am văzut creșterea numărului de oameni care le pasă atât de mult încât oamenii să fie destul de fericiți să primească o recenzie și să facă doar munca pe care le spui să o facă. Așa că, dacă le oferiți o grămadă de recomandări, ele vor urma. Dar apoi, dacă revin pe site anul viitor, le mai dau doar o grămadă de recomandări. Așa că am văzut foarte mult o schimbare în acest ultim an de oameni de fapt suficient de îngrijiți încât să pună întrebări. Și astfel, pentru mine, auditurile de cod au fost aruncate în marele, lung aici linia 6, 4, 2 din acest fișier, bla, trebuie făcut așa.

Am scăpat de toate astea și am început cu adevărat să mă concentrez pe educație și mi-am dat seama că, să fiu sincer, ceea ce își doresc majoritatea oamenilor este să nu vi se spună, trebuie să remediați această linie, dar să vi se spună, iată cum să remediați. fiecare linie care este acolo. Deci, pentru mine, marea schimbare și marea schimbare a focalizării a fost către educație. Și acesta este ceva la nivelul întregii industrie. Cred că sunt din ce în ce mai mulți oameni care vorbesc despre securitate anul acesta decât anul trecut și din ce în ce mai mulți din anii precedenți.

MODERATOR: Nu, e minunat. Îmi place foarte mult acea concentrare de a trece de la a-ți oferi peștele la a te învăța cum să prinzi peștele. Deci asta e cu adevărat...

TIM NASH: Încercam să evit cu orice preț această analogie pentru că sunt clișeu.

MODERATOR: Mulțumesc.

TIM NASH: Doar bine făcut.

MODERATOR: Bine, Jimmy.

JIMMY SQUIRES: Da, cred că sunt atât de multe, am decis să mă concentrez pe un lucru cu adevărat specific despre care să vorbesc la acest răspuns. Și asta vă restrânge cu adevărat domeniul de aplicare atunci când aveți de-a face cu jetoane și acces API. Cred că încălcarea depozitului Heroku, GitHub de anul trecut a fost o reamintire foarte bună că deții doar controlul asupra atâtor lucruri. Deci, atunci când lucrăm cu dezvoltatorii noștri, amintindu-le importanța acelei politici de acces limitate pe orice platformă sau sistem cu care ați putea lucra. De multe ori, un dezvoltator își dorește cu adevărat un acces destul de deschis la începutul dezvoltării doar pentru ușurință. Și, uneori, acele lucruri pe care le suntem probabil – cu toții rușine să recunoaștem – nu sunt înăsprite la nivelul la care ar trebui să fie înainte de producție. Deci, începeți devreme, luând în considerare acele domenii de securitate.

MODERATOR: Mulțumesc, Jimmy. Și Lawrence, știu că și tu lucrezi mult cu dezvoltatorii. Deci, ce căutați toți în fața asta pentru asta?

LAWRENCE EDMONDSON: Da, sigur. Doar ca să construim pe ce a spus Jimmy, cu siguranță, amândoi lucrăm în publicitate. Așa că cred că vedem multe aceleași provocări atunci când lucrezi în publicitate față de lucrul într-un mediu de produs. Pentru noi, atingem o mulțime de tehnologii diferite, o mulțime de stive de tehnologie diferite. Trebuie să fim agnostici din punct de vedere tehnic. Deci, ceea ce vedem este că consumatorii se implică în mai multe moduri acum prin intermediul dispozitivelor mobile și sociale. În urmă cu câțiva ani, desktopul era principalul mijloc de accesare a site-urilor și a conținutului. Acum este complet răsturnat. A trecut de la desktop la mobil la, acum, social.

Prin urmare, straturile API și straturile de aplicație trebuie să fie blocate în moduri care au un pic de paranoia sănătoasă asociată cu ele. Așadar, ceea ce vedem este că spectrul de atac este în creștere, așa că căutăm în mod constant noi modalități de a-i determina pe DevOps să gândească ca programatori, astfel încât să înțeleagă modalitățile posibile prin care lucrurile pot fi încălcate. Deci cam asta facem azi.

MODERATOR: Mulțumesc pentru asta. Și ați menționat cum crește vectorul de atac. Și asta e ceva pe care îl avem aici, la WP Engine, ne-am uitat mai mult din modul în care adoptați un mecanism de apărare în profunzime. Așa că nu aveți încredere în niciun strat pentru a fi sigur. Și așadar, cum încorporați asta în modul în care codificați și în modul în care scrieți software-ul. Deci mulțumesc pentru asta. Pe măsură ce ați vorbit cu toții despre tendința în schimbare care se întâmplă acolo, încălcări care s-au întâmplat în ultimul an. Așadar, când priviți 2023, care sunt câteva teme sau amenințări majore cărora le acordați atenție? Și poate, Sergi, ne poți începe. Da.

SERGI ISASI: Sigur. Și asta o să sune prostesc pentru că este 2023 și o să spun cuvântul DDOS, dar este totuși un lucru. Și a fost cu adevărat o schimbare interesantă în ultimele nouă, 12 luni în lumea DDOS. Volumetric nu este cu adevărat un vector DDOS în zilele noastre. Există mult mai puțină reflecție. Și din perspectiva unui actor de amenințare, este atât mai ușor să lansați un DDOS, deoarece aveți o mulțime de instrumente disponibile, nu? Aproape ne-am întors la zilele de script TD, dar aveți și mult mai puține sisteme compromise de atacat. Deci, dacă încercați să reflectați, nu există o mulțime de infrastructură care să fie gestionată de cineva care poate nu și-a corectat sistemul, așa că puteți lua un pachet și îl puteți transforma la 10. Asta nu mai este un lucru prea mare.

Deci se mută la stratul 7. Și stratul 7 este atât mai scump de lansat, deoarece aveți nevoie de mult CPU pentru a face acest lucru, dar este și mult mai scump de atenuat. Deci, dacă aveți un fel de sistem de protecție DDOS, trebuie de fapt să acceptați conexiunea, să o examinați și apoi să începeți să o aruncați față de ceva ce ați putea să o aruncați la un strat inferior. Ceea ce am găsit și am atenuat cel mai mare DDOS Layer 7 raportat chiar luna trecută. Tema mare a acestor atacuri sunt dispozitivele mai puternice.

Deci, dacă vă gândiți la toate lucrurile pe care le-am conectat acasă în zilele noastre, procesorul de pe acel dispozitiv este semnificativ mai bun decât era chiar acum trei sau patru ani. Deci, camera ta face mult mai mult. Deci are un procesor mai robust, chiar și routerele tale sunt de fapt o mașină destul de puternică. Și orice compromis la aceste dispozitive poate permite un atac mare, mai mare, mai ales că, dacă compromiteți unul, acum le compromiteți practic pe toate care sunt conectate.

Celălalt lucru despre care vorbim puțin în aceste zile, dar este puțin mai liniștit, este că am trecut de la dispozitive hardware compromise la conturi compromise pe serviciile cloud. Serviciile cloud au CPU efectiv nelimitat. Deci, dacă pot avea acces la un număr de conturi de persoane sau companii și pot face tot ce vreau în acel sistem cloud, pot lansa un atac extrem de mare. Și asta vedem în atacurile de doborâre de record. Deci da, 2023, încă DDOS, încă un lucru, dar acum la nivelul 7 față de straturile inferioare.

MODERATOR: Mulțumesc. Este înfricoșător, dar, de asemenea, în același timp, cred că arată cum continuăm să ne îmbunătățim protocoalele de securitate și zona de interes continuă să crească. Știu, Lawrence, tu și cu mine vorbisem în trecut despre inteligența artificială ca fiind atât un boom, cât și o amenințare. Mi-ar plăcea să aud câteva dintre gândurile voastre despre AI generativă și despre modul în care vedeți că aceasta va afecta de fapt suprafața de securitate în 2023.

LAWRENCE EDMONDSON: Deci sunt foarte entuziasmat, foarte optimist cu AI. Suntem la Barbarian, dar, în același timp, este foarte înfricoșător. Potențialul ca ceva de genul unui chatGPT să fie folosit în moduri rău intenționate. Deci, de exemplu, ați putea cere Chat GPT să vă comenteze codul. Și de fapt face o treabă destul de decentă, în funcție de ce limbă și de cât de dezordonat este codul tău, face o treabă destul de bună. Așa că următorul lucru, cred, îl vom vedea pentru Chat GPT – și acest lucru s-ar putea să fie deja în curs, deoarece în fiecare zi, se spune că Chat GPT face asta. Ca și astăzi, tocmai am văzut că este capabil să răspundă în Slack și să găsească răspunsuri în Slack.

Deci, cred că următorul lucru, în ceea ce privește securitatea, în Chat GPT este ca Chat GPT să găsească exploit-uri și să scrie codul într-un cod rău intenționat pentru a exploata cu adevărat punctele slabe pe care le găsește. Deci vedem asta, mai ales potențialul pentru asta în memorie. Deci atacurile de memorie nu lasă o semnătură tot timpul. Deci, virușii și scanerele tradiționale de viruși, lucrează la căutarea semnăturilor unui atac. În cadrul atacurilor de memorie, atacați aplicația. Faci ceva de genul o depășire a tamponului. Căutați să compromiteți aplicația în timpul execuției. Cred că Chat GPT este de fapt gata să facă asta. Și cred că este doar o chestiune de timp până când vedem primul exploat ChatGPT la scară largă.

TIM NASH: Cum ți-ai imagina că se va întâmpla asta de fapt? Pentru că, evident, ChatGPT, în esență, este doar un set de solicitări API către un server. Și trimiți o solicitare care spune, hei, generează-mi un cod rău intenționat. Îl întoarce înapoi. Adică, există o mulțime de oameni care generează deja cod rău intenționat. Cum ai face ca asta să fie mai rău decât codul rău intenționat care există deja?

LAWRENCE EDMONDSON: Deci asta este exact lucrul. Există deja un depozit mare din care să înveți. Deci, ChatGPT, ceea ce face, se uită de fapt – trebuie să antrenezi modelul. Deci, de-a lungul timpului, inginerii antrenează modelul să recunoască când cineva spune asta, asta este de fapt ceea ce spun. Deci, înțelegeți contextul. Deci exact asta este, dar într-un mod diferit. Este antrenarea modelului pentru a scrie cod și ceea ce înseamnă de fapt. Și unele limbi sunt foarte ușoare. Deci PHP, destul de ușor de scris cod în PHP. Aceste limbi interpretate sunt mult mai ușoare. Este mult mai dezordonat, dar față de a face ceva ca un Java, care trebuie compilat, știi ce vreau să spun?

Așadar, cred că o modalitate ușoară de a face acest lucru ar fi să creezi un model bazat pe chatGPT 3 pe care, de fapt, să-l antrenezi, să treci prin chestiile de sintaxă, să treci prin toate lucrurile de bază ale informaticii și apoi să o iei. un pas înainte și mergeți, OK, aceste pachete NPM au aceste exploit-uri. Caută-l și găsește o modalitate de a – au aceste vulnerabilități, îmi pare rău, și caută o modalitate de a exploata acele vulnerabilități. Îți garantez că nu suntem prea departe să vedem așa ceva să se întâmple.

MODERATOR: Mulțumesc, Lawrence. Cred că este o zonă foarte în curs de dezvoltare. Ceea ce este interesant în acest spațiu este doar că, cu inteligența artificială, în general, are atât acel echilibru pentru ceea ce îl puteți folosi, fie că este să folosiți aceste semnături pentru a preveni și a învăța din ea pentru a vedea cum ne puteți împiedica scrierea unui cod slab sau a unui cod vulnerabil. Și, în același timp, așa cum am văzut că oamenii vorbesc despre, hei, am scris primul meu plug-in în cinci minute cu Chat GPT, cred că-da, este mai mult despre cum asta începe să le permită oamenilor să creeze puțin malware Mai repede? Dar cred că are ambele aspecte.

Este mai mult despre cum puteți continua să utilizați oricare dintre aceste instrumente pentru a vă îmbunătăți doar scrierea codului, dar pentru a scrie cod mai sigur. Și știu, Tim, acesta este un domeniu de pasiune pentru tine. Doriți să vorbiți mai mult despre modul în care vedeți că Secure Code evoluează în 2023 și despre ce faceți în acel spațiu?

TIM NASH: Ei bine, vreau să spun, în multe privințe, Chat GPT este un bun exemplu în acest sens. Dacă mă gândeam la un vector de atac, voi fi sincer, nu mă gândeam să facă o scanare în masă, să-l hrănească cu multe lucruri ca un actor rău. Mă gândeam la el ca la un dezvoltator de cod obișnuit care încerca să economisească timp și introducea lucruri în Chat GPT și le arunca și nu înțelegea neapărat pe deplin tot codul care este scris, produs, care nu a scris niciun test pentru Fă-te că ești de acord. Acesta este doar un lucru rapid, este doar un scenariu rapid, totul este în regulă. Intră în producție, nu e bine și arde totul.

Acum, acesta este exact același lucru pe care fiecare dezvoltator îl face în fiecare zi, indiferent. Chat GPT nu schimbă acest lucru, dar îl activează puțin mai ușor. Dă – există mai puține bariere.

SERGI ISASI: Da, deci nu este chiar același lucru cu copierea și lipirea de la Stack Overflow, la care cred că te referi, Tim, care este practic tot ce fac eu pentru cod. Dar cred că este o creștere a eficienței cu siguranță, atât pozitiv, cât și negativ. Dar cred că permite schimbări mai subtile și exploatarea mai rapidă a ceva care mai mult este un motor bazat pe semnătură, nu poate ajunge din urmă. Deci, atunci când faceți detecție, trebuie să aveți un sistem care să spună că arată similar cu ceva ce am văzut în trecut, spre deosebire de potrivirea directă cu ceva ce am văzut în trecut. Și asta este de fapt și din partea detectării, probabil cel mai bine servit cu ML sau AI sau cum vrei să-i spui.

Am învățat că, cu trafic automatizat pe, știi, practic roboți. Cea mai bună modalitate de a afla cum ocolesc detectarea bazată pe semnătură este cu ML. Dar acum treci de la, știu absolut că acest lucru este rău, la, ei bine, este probabil să fie automatizat sau probabil să arate ca o semnătură pe care am văzut-o înainte, dar nu o potrivire exactă.

MODERATOR: Minunat. Mulțumesc. Mulțumesc, Sergi și Tim pentru acest context adăugat. Deci, printre participanții noștri, avem o mulțime de dezvoltatori și agenții care sunt prezente astăzi aici. Și mulți oameni se gândesc să stabilească cele mai bune practici, mai ales că scenariile se schimbă în ceea ce privește vectorii de amenințare. Așadar, care sunt cele mai bune practici pe care le-ați recomanda atunci când construiți un site, o aplicație sau o platformă sau chiar când începeți un nou proiect. Deci, care sunt unele lucruri la care oamenii ar trebui să fie atenți?

SERGI ISASI: Așa că pot începe asta. Ar fi mai mult pe partea operațională decât pe partea dezvoltării. Cred că unul dintre lucrurile pe care le predicăm aici este să presupunem că ceva rău se va întâmpla. Deci se apropie o breșă, nu poți să fii surprins de ea. Este posibil să se întâmple la un moment dat. Și cheia noastră – așa că, unul, creează o carte de alergare pentru asta. Așadar, atunci când se întâmplă, știți ce persoane să contactați și care va fi răspunsul dvs., atât de la detectare, cât și de la răspuns, dar și comunicând clienților dumneavoastră dacă îi afectează. Și din acest punct de vedere, lucrul pe care cred că îl facem foarte bine la Cloudflare și a făcut parte din brandul nostru și cred că ne-a servit foarte bine este să fim sinceri, deschiși și cât mai comunicativi pe cât ați putea fi despre orice. asta s-a intamplat.

Deschiderea a fost esențială pentru restabilirea încrederii clienților atunci când se întâmplă ceva, fie că este vorba despre o breșă software sau despre o greșeală pe care ați făcut-o în ceea ce privește un incident. Ascunderea în spatele ei nu este niciodată chemarea potrivită.

MODERATOR: Da.

JIMMY SQUIRES: Cred că și altceva este și noi – acum că toată lumea este în mod evident la distanță și mai ales în echipele de dezvoltare, de fapt își ia timp la începutul unui proiect pentru a face niște tablă și planificare arhitecturală. Este atât de ușor să te scufundi direct în cerințe și să anulezi poveștile de dezvoltare, dar să petreci timp cu colegii tăi pentru a contesta cum ar putea fi exploatat acest lucru? Execută scenarii. Facem o mulțime de planificare a scenariilor care duc la o mulțime de conversații bune cu, cum vrem să sprijinim diferite părți ale aplicației.

LAWRENCE EDMONDSON: Și doar despre asta, nu știu dacă știe cineva, dar MPM este de fapt cel mai mare depozit de biblioteci partajate – este cel mai mare depozit de biblioteci de aplicații de acolo, dar asta înseamnă că prezintă și cel mai mare risc. Deci, un lucru de care suntem foarte conștienți atunci când luăm un proiect nou dacă folosim NPM este să ne asigurăm că ne uităm la vulnerabilități, că blocăm versiuni pe care le împingem pentru a le produce, că înainte de a facem o actualizare, ne asigurăm că este ceva compatibil, dar și foarte sigur. Nu există amenințări deschise, deoarece am văzut o mulțime de vulnerabilități strecurate prin NPM. Deci, acesta este doar un lucru la care trebuie să fii atent.

TIM NASH: Cred că facem buclă peste tot.

JIMMY SQUIRES: Haide, Tim.

TIM NASH: Cred că trecem peste tot la ideea că, într-adevăr, încrederea este complet ruptă în ciclurile de dezvoltare de ani de zile. Oamenii ajung să-și dea seama acum. Și dacă ești un dezvoltator PHP care lucrează în WordPress, de exemplu, stai acolo apelând acțiuni și filtre, dar nu ar trebui să ai încredere în acele acțiuni și filtre. Orice date care vin, ar trebui să le validați, ar trebui să le verificați. Ar trebui igienizat. Dar când iese din baza de date, tot nu ar trebui să ai încredere în el.

Chiar dacă este posibil să fi pus acele date în baza de date, nu ar trebui să ai încredere în datele care ies. Dacă transmitem ceva unei biblioteci terțe, fie acel NPM, fie acel pachet compozitor sau doar un alt plugin WordPress, imediat ne-a lăsat controlul, nu avem din nou încredere în el. Dar când revine, chiar dacă l-am verificat, tot nu avem încredere în el. Și dacă ai acea mentalitate, ca dezvoltator, că fiecare bucată de date nu ar trebui să fie de încredere și ar trebui să fie izolată până la capăt și ar trebui să faci verificările de securitate la fiecare punct dat, vei veni cu un sistem mult mai sigur. S-ar putea să ieși cu un sistem puțin mai lent. S-ar putea să întâlniți un sistem puțin mai frustrant și unul care are nevoie de mult mai multe teste pentru a vă asigura că ceea ce faceți nu cauzează de fapt mai multe probleme decât ajută.

MODERATOR: Da.

TIM NASH: Adaugă complicații, dar ajungi cu un sistem mult mai sigur. Și pentru majoritatea oamenilor, asta își doresc.

LAWRENCE EDMONDSON: Da.

MODERATOR: Da. Ai dreptate. Este vorba despre a nu avea încredere în nicio altă bucată de cod care vine. Și despre ceea ce au vorbit Jimmy și Sergi, este să ai un plan și dintr-o perspectivă arhitecturală, sau dintr-o perspectivă operațională, dar să aduci toate acestea în practica ta generală, fie că este vorba despre mecanisme de codare securizate sau dacă ai un manual de incidente. Deci, Tim, sunt foarte interesat să aud mai multe de la tine în jur – faci multe antrenamente, predai mult în întreaga lume. Care sunt unele greșeli comune pe care le vedeți pe măsură ce oamenii încep să lucreze la proiecte sau greșelile pe care le-ați fi făcut, eu le-am făcut multe.

TIM NASH: Voiam să spun, sunt destul de sigur că sunt vinovat de fiecare greșeală despre care urmează să vorbesc. Iar cel mai mare și cel mai simplu este să fii o persoană drăguță. Majoritatea dezvoltatorilor presupun o bună intenție. Majoritatea oamenilor presupun că veți folosi aplicația lor așa cum ați scris aplicația lor. Acum, destul de des, nu scriem documentație, astfel încât utilizatorul nu are idee cum să folosească aplicația în primul rând, dar aceasta este o problemă separată. Un actor rău va intra și va lua orice bug și va pleca, asta nu este o eroare, pentru un actor rău, asta este o caracteristică. Asta e o oportunitate. Face ceva la care dezvoltatorul nu se așteaptă, prin urmare, există o cale potențială în asta.

Și în general, ceva pe care îl vezi din când în când, când spui, uite, ai un set de teste unitare. Oh, minunat. Dar ai testat doar lucrurile pozitive, rezultatul pe care l-ai dorit. Nu ai testat ce se întâmplă dacă ieșim în afara acestor granițe. Tocmai ai testat pentru a te asigura că lucrul funcționează conform cu ceea ce dorește șeful tău. Deci ceea ce aveți cu adevărat sunt teste de acceptare, teste de acceptare dubioase. Și apoi se reduce la toate elementele de bază. În calitate de dezvoltator, este dat înapoi în acest sens, nu aveți încredere în lucruri. Și dacă sunteți un dezvoltator WordPress în special, WordPress are de fapt niște funcții de ajutor foarte bune pentru a face tot felul de lucruri standard de securitate pe care le cerem oamenilor să le facă.

Și este vorba de a le educa și de a învăța să le folosești. Când fac recenzii de cod, iar și iar voi vedea aceleași probleme. Și dacă îl văd o dată într-o bucată de cod, îl voi vedea de 1.000 de ori în același set de cod. Și vor fi lucruri de genul, da, ei bine, am permis doar ca orice chestii vechi să apară pe pagină. Nu ne-am obosit să verificăm dacă avea sau nu ceva acolo. Da, am pus lucruri în baza de date. Uite, s-ar putea să arate ca o interogare SQL, s-ar putea să nu.

Toate aceste lucruri sunt ușor de remediat și am oferit deja instrumentele pentru a le remedia. Și motivul pentru care nu le reparăm este adesea că nici măcar oamenii nu știu că nu ar trebui să lase aceste lucruri să se întâmple, doar că devenim leneși, facem lucrurile rapid, luăm cod din Stack Overflow, facem ca Chat GPT să facă lucruri pentru noi, nu verificăm lucrurile. Și o mulțime de probleme de securitate provin din această stare de, trebuie să mă grăbesc. Trebuie să mă grăbesc. Trebuie să mă grăbesc, trebuie să fac asta. Trec la următorul lucru, trec la următorul lucru.

Așadar, în mod ciudat, pentru mulți dezvoltatori, de fapt, oferindu-le timp și spațiu și spunând, este în regulă să-ți ia timp pentru a verifica cu adevărat ceea ce ai făcut, astfel încât, atunci când vine vorba, și în cazurile în care intru în joc, Mă întorc și spun, ei bine, toate aceste lucruri, iar dezvoltatorii par nesăbuiți. Se duc, da, știm toate astea. Doar că nu am avut timp.

Deci, sperăm, să le oferim oamenilor mai mult timp și să le oferim instrumentele, pe care le avem deja în special în WordPress. WordPress are un set cu adevărat genial de funcții de ajutor pentru cele mai comune probleme de securitate pe care le-ați avea într-un plugin sau o temă WordPress. Deci, este vorba doar de a le învăța și apoi de a investi timp pentru a le implementa efectiv.

MODERATOR: Da. Și cred că este foarte puternic, investește timp. Cel mai adesea, dezvoltatorii știu ce trebuie remediat. Deci, acordându-le timp. Deci chiar îmi place acel mesaj. Și Jimmy, știu că ai adus asta în propriul flux de lucru la agenția ta. Doriți să vorbiți mai multe despre practicile de flux de lucru sigur pe care le-ați implementat?

JIMMY SQUIRES: Da, absolut. Și într-adevăr, începe doar prin a avea ceva ce a spus Sergi că are un plan, de fapt, având linii directoare și standarde pe care echipa ta de dezvoltare să le urmeze. Știu că sună probabil foarte simplu, dar am văzut o mulțime de organizații și am auzit de la mulți ingineri pe care i-am angajat de-a lungul anilor că nu exista. Nu a existat organizare la locul de muncă de la care au venit.

Deci, ceea ce ne place să facem este să avem un set standard de linii directoare, toți noii noștri ingineri trebuie să citească de sus până jos. Nu este atât de greu încât să nu fie consumabil. Ne place să-l păstrăm în reducere, așa că totul este într-un depozit. Probabil că îl vom deschide la un moment dat. Nu există nimic acolo care să fie cu adevărat proprietar și apoi încurajăm pe toată lumea să contribuie la asta. Aceasta este o întrebare adresată tuturor inginerilor.

Deci, chiar și în liniile noastre directoare, fă găuri unde putem adăuga, unde putem fi mai buni, crescând continuu asta. Dar petrecerea timpului cu asta, unele dintre lucrurile de bază, cum ar fi OWASP, este o practică foarte veche, dar trecerea prin asta cu aplicația ta, luând în considerare aceste lucruri. Este un fel de ceea ce a spus Tim, într-adevăr este nevoie de timp și de a fi în regulă să-ți iei timp cu asta. Am vrut să adaug un punct în plus la conversația AI. Discuțiile cu câțiva dintre inginerii noștri săptămâna trecută a avut de fapt un eveniment. Pentru asta folosim Chat GPT este de fapt testarea unitară. Luând o funcție și explorând-o în moduri interesante, cum poți folosi ceva de genul Chat GPT pentru a scrie un test unitar în care nu vei fi cel mai bun autor al acelui test unitar, în sensul lui Tim. Acolo cred că putem folosi AI mult mai mult într-un mod preventiv.

LAWRENCE EDMONDSON: Da. Ceea ce facem de partea noastră, cred că listele de verificare și a avea un manual sunt grozave. Folosim instrumente automate, cum ar fi SonarQube și avem cu adevărat lining în loc și lucruri de genul acesta, doar pentru a crește calitatea codului cu lining, dar și folosim SonarQube pentru a ne asigura că codul este mai sigur, că căutăm pentru vulnerabilități și lucruri de genul ăsta. Cred că unele limbi sunt mai ușor de găsit exploatări decât altele, așa cum am menționat mai devreme, doar din cauza naturii limbii. Și, de asemenea, doar anumite cadre în care calitatea programatorilor care contribuie la acea bază de cod în mod obișnuit – de obicei vedem asta cu Open Source, unde este ca și cum – există o mulțime de copiere și lipire Stack Overflow, comparativ cu oamenii care au studiat de fapt. CS și știu cu adevărat ce fac. Deci ăsta e doar un lucru pe care l-am văzut.

TIM NASH: Simt că ar trebui să subliniem, cu siguranță pentru mine, că folosesc Stack OverFlow aproape în fiecare zi. Și așa suntem cu toții vinovați de asta. Este bine să-l baști pe el, dar nu cred… Adică, îmi amintesc când am început prima dată să codez. Am primit o revistă și am tastat codul din revistă și am apăsat pe Enter. Nu pot să-mi imaginez că web-ul funcționează cu adevărat astăzi dacă tot am rămas să facem asta și nu am avut Stack Overflow sau ceva similar.

Sergi: Nu, e acceleratorul. Și sperăm că AI este următoarea etapă a acestui lucru. Dar da, este un meme distractiv.

MODERATOR: Mulțumesc. Deci mă schimb puțin. Există o mulțime de impuls care se întâmplă în industrie în jurul implementărilor Headless și Headless. Și am văzut, de asemenea, în unele dintre celelalte canale de astăzi sau în alte sesiuni se vorbește despre Headless. Așa că, când am început să lucrăm cu Atlas la WP Engine, ne-am întâlnit cu o mulțime de dezvoltatori, iar securitatea a fost întotdeauna un motiv cheie. Deci, cum vedeți securitatea cu Headless? Și știu, Jimmy, aceasta este o zonă în care ai făcut niște proiecte în jurul ei. Ne-ar plăcea să primim părerea dvs. despre asta.

JIMMY SQUIRES: Da, lucrăm mult în Headless. Cred că aproape toate proiectele noastre în acest moment au probabil o abordare a arhitecturii Headless. Cred că vreau doar să fac câteva puncte despre el, în ceea ce privește securitatea. Așadar, cred că primul este că atunci când alegi o arhitectură Headless, în general, te pui mai mult în tabăra open source la început. Și există o mulțime de dezbateri, desigur, despre ce este mai sigur, sursă deschisă sau sursă închisă. Tind să cad în tabăra proiectelor OSS sunt mai sigure prin natura lor. Deci alegeți cadre precum Next, WordPress, unde aveți o comunitate gigantică. Și asta tinde să se preteze la mai multă securitate prin simpla expunere.

Deci cred că asta e una. Cred că a doua este ceva de genul Static Generation. Deci, o mulțime de site-uri web și produse care sunt construite, nu aveți nevoie de natura dinamică a unui sistem de management al conținutului mare, monolitic în sens tradițional. Puteți folosi ceva de genul Cloudflare și puteți genera cu adevărat static porțiuni mari din acea aplicație, reducându-vă astfel amprenta pentru vectori și expunere. Deci suntem mari fani ai asta. Și apoi, desigur, obțineți toate beneficiile de performanță și cu asta. Așadar, acestea sunt doar câteva puncte pe care am vrut să le fac despre arhitectura Headless. Dar multe alte motive din punct de vedere al securității că ne place. Dar cred că acestea sunt probabil două dintre cele mai mari zone remarcate.

TIM NASH: Aș dori să le reamintesc oamenilor că există încă un sistem de management al conținutului în spate. Și prea des aud că Headless este complet în siguranță. Este ca, da, dar acea instanță WordPress expusă care este încă acolo, doar pentru că nu o suni direct de pe site, da, este încă acolo pe admin.yoursite.com. Și tu nu ai... există o anumită convingere că, oh, da, ei bine, acum suntem în siguranță, așa că nu trebuie să ne facem griji că îl ținem la zi pentru că nu este site-ul web. E ca și cum, nu, nu, mai ai nevoie de toate lucrurile pe care le făceai înainte și acum avem și cealaltă parte.

Și vreau să spun, Headless este un termen grozav care se referă la ceva care există de mult timp și capătă o mulțime de impuls, dar făceam asta de înainte ca WordPress să aibă un API REST. Am împins conținut din WordPress către lucruri precum Jekyll pentru a obține cel puțin un site static din el. Iar raționamentul inițial pentru a face asta a fost acela de a varia sistemul WordPress sau sistemul de management al conținutului în interiorul rețelei. Așa că ai putea să-l blochezi și să-l feri de rețeaua mare și înfricoșătoare.

Acum avem o mulțime de companii de găzduire care oferă soluții Headless. And that infrastructure is now out in the cloud again. So we've sort of moved the big benefit for Headless. And we're slowly shifting it back into the public domain again, which seems like a very almost backwards move, but it's the only move for widespread adoption. So there's a balancing act we have there. But yeah, just a small little warning into the big space of keep the backend secure still. You can't just rely on it being–

TIM NASH: Just because something's got some HTML files at the front, the back end still needs to stay just as secure as before.

MODERATOR: Yeah, absolutely. I mean, Headless, by default, doesn't mean that everything is secure. It means that you have a different paradigm. And that's what I think I was interested in, looking at what practices that you bring in as you look at Headless infringers. So yeah, I think that's you're very apt in stating that you still have to secure both the CMS part, as well as the web part of it. So as we are wrapping up, what I would love to do is we have had a lot of good topics to talk about in here, but I would love to take like 10 seconds from each one of you to say that if there is one thing that our audience could do in these next two months after the end of the session, what would that be? What's your recommendation?

LAWRENCE EDMONDSON: I guess I'll start off. My recommendation would be very simple. Security should be everyone's business. I think a lot of times, security doesn't become a topic or consideration until there's a problem. If I were a developer, I would make sure that I am being very proactive in terms of taking the necessary steps. It's 2023, we shouldn't be storing anything in clear text.

Everything should be encrypted as much as you can. Use Hashicorp, encrypt your database and make sure that your keys are stored securely, or it's something that's not easily compromised. But that's what I would encourage folks to make sure that security is top of mind all the way throughout.

MODERATOR: Thank you, Lawrence. Sergi, what about you?

SERGIS ISASI: I would say get an inventory of what's exposed. Know what's on the internet and make sure that the proper– at least aware of what's there, if not fully protecting it.

MODERATOR: Thank you. And Jimmy?

JIMMY: Scenario planning. Take the time in your project to do the scenario planning and create those playbooks, both preventative and then reactive once something does happen, to Sergi's point earlier. What are your action steps for that? Take that time and the project will pay off dividends later.

MODERATOR: Wonderful. Mulțumesc. And Tim, bring us home.

TIM NASH: Oh, I want to reinforce what Lawrence said. Security is everybody's responsibility. Give people the time and space to actually do their jobs properly and you'll find that you will come out with a much more secure project.

MODERATOR: Thank you. Security is indeed everyone's responsibility. So thank you to our amazing panelists for taking the time today and also to everybody in the audience. Hope you enjoyed this session. Thank you and bye.