Noutați

SAST pentru JavaScript in GitLab 11.8

Testarea statică a securității aplicațiilor (SAST) vă permite să găsiți vulnerabilități în cod de fiecare dată când trimiteți modificări în depozit. Cu aceste informații disponibile în cererea de îmbinare, puteți să aveți mai întâi grijă de securitate și să detectați probleme chiar înainte de a fi adăugate la sucursala stabilă. Datorită testării statice a securității aplicațiilor (SAST), GitLab scanează codul și ajută la detectarea potențialelor vulnerabilități chiar și în conductă. În versiunea 11.8, adăugăm limbi JavaScript la lista de SAST acceptate, pe baza suportului existent pentru node.js. Acum puteți scana orice fișiere JavaScript, scripturi statice și HTML. O practică importantă la DevSecOps chiar acum este scanarea modificărilor de fiecare dată când ne angajăm, iar cu această actualizare SAST acoperim unul dintre cele mai populare limbi web, ajutând utilizatorii să detecteze mai devreme riscurile în codul JavaScript. Odată cu lansarea 11.8, adăugăm JavaScript pe lista de limbi acceptate de functionalitati de scanare erori de securiate. Nu trebuie să schimbați nimic în conductele dvs., proiectele JavaScript sunt detectate și analizate automat pentru vulnerabilitățile de securitate. De asemenea, face parte din DevOps Auto. Dacă utilizați GitLab CI / CD, puteți analiza codul sursă pentru vulnerabilitățile cunoscute folosind testarea statică a securității aplicațiilor. Puteți profita de SAST fie prin includerea jobului CI în fișierul dvs. .gitlab-ci.yml existent, fie implicit folosind Auto SAST furnizat de Auto DevOps. GitLab verifică raportul SAST, compară vulnerabilitățile găsite între sucursalele și sucursalele-țintă și arată informațiile din dreptul cererii de îmbinare. Rezultatele sunt sortate în funcție de prioritatea vulnerabilităților: Critical High Medium Low Unknown Everything else Pentru a lansa un asemenea job, în mod implicit, aveți nevoie de GitLab Runner cu dockerul sau kubernetes care rulează în modul privilegiat. Dacă utilizați Runners partajat pe GitLab.com, aceasta este activată în mod implicit. Pentru GitLab 11.9 și versiuni ulterioare, pentru a activa functionalitatea, trebuie să includeți șablonul SAST.gitlab-ci.yml care este furnizat ca parte a instalării dvs. GitLab. Pentru versiunile GitLab anterioare datei de 11.9, puteți copia și utiliza jobul așa cum a fost definit acel șablon. Adăugați următoarele în fișierul dvs. .gitlab-ci.yml:

Read More

Ce nu vor putea niciodată static analysis

Ce este practic, source code static analysis? Trimitem câteva surse code la intrare, iar la ieșire într-un timp scurt (mult mai scurt decât testul) obținem câteva informații despre codul nostru. Limitarea fundamentală și insurmontabilă din punct de vedere matematic este că nu putem obține în acest fel o clasă destul de restrânsă de informații. Cel mai cunoscut exemplu de problemă care nu poate fi rezolvat cu ajutorul static analysis este problema de oprire: aceasta este o teoremă care dovedește că este imposibil să dezvolte un algoritm general care să determine prin codul sursă al unui program dacă se va bucla sau se va termina într-un timp finit. O extensie a acestei teoreme este teorema lui Rice, care afirmă că, pentru orice proprietate non-privată a funcțiilor computabile, a determina dacă un program arbitrar calculează o funcție cu această proprietate este o problemă algoritmic nesolvabilă. De exemplu, este imposibil să scrii un analizator care stabilește, folosind orice cod sursă, dacă programul analizat este o implementare a unui algoritm care calculează, să zicem, pătratul unui număr întreg. Astfel, funcționalitatea analizatorilor statici are limită insurmontabile. În toate cazurile, analizatorul static nu va putea niciodată să detecteze astfel de lucruri, cum ar fi, de exemplu, apariția unei „excepții de indicator nul” în limbile nuloase sau în toate cazurile va determina apariția unui „atribut care nu se găsește” în limbile tipizate dinamic. Tot ceea ce poate face cel mai avansat analizor static este să izoleze cazuri particulare, dintre care numărul dintre toate problemele posibile cu codul sursă este, fără exagerare, o scădere a găleții. Static analysis nu este o căutare a erorilor Concluzia rezultă din cele de mai sus: static analysis nu este un mijloc de reducere a numărului de defecte dintr-un program. Mă aventurez să spun: atunci când este aplicat pentru prima oară proiectului dvs., va găsi locuri „ocupate” în cod, dar cel mai probabil nu va găsi defecte care să afecteze calitatea programului. Exemplele de defecte găsite automat de analizatori sunt impresionante, dar nu trebuie să uităm că aceste exemple au fost găsite prin scanarea unui set mare de baze de coduri mari. După același principiu, crackerele care au capacitatea de a încerca câteva parole simple pe un număr mare de conturi găsesc în cele din urmă acele conturi care au o parolă simplă. Asta înseamnă că nu trebuie aplicată static analysis? Sigur că nu! Și, exact pentru același motiv, de ce merită să verificați fiecare nouă parolă pentru prezența acesteia în stop-list a parolelor „simple”.

Read More

RAD versus Low Code

Dezvoltarea Low Code este în prezent un subiect foarte discutat. Dacă se credem în declarațiile producătorilor, atunci aceste instrumente sunt răspunsul inevitabil al IT la nevoia tot mai mare de software în întreprinderi. Acestea se adresează utilizatorilor interesați din punct de vedere tehnic din departamentele de specialitate și pot îmbunătăți cooperarea cu dezvoltatorii de software. Principalul obiectiv este reducerea timpului de introducere pe piață. Dezvoltatorii vor deveni de prisos și va trebui să ne facem griji pentru meseria noastră? Și care este relația cu dezvoltarea rapidă a aplicațiilor? În dezvoltarea de software, instrumentele au fost întotdeauna utilizate pe scară largă pentru a accelera procesul de dezvoltare a noilor aplicații. Este important să utilizați cel mai bun suport de instrument posibil pentru sarcina respectivă. Nici o așa-numită „Overtooling” și nici o utilizare prea minimalistă a instrumentelor nu sunt convenabile în vederea unei eficiențe ridicate a ciclului de dezvoltare. Cu o utilizare prea mică a instrumentelor, prea multe sarcini sunt efectuate manual, chiar dacă există instrumente mature și adecvate care simplifică și accelerează lucrarea. Unul ar risipi potențialele de economie și cu acesta bani și timp. RAD Vs. Low Code Instrumentul tipic de dezvoltare software este mediul de dezvoltare integrat (IDE). (RAD) înseamnă o dezvoltare rapidă a aplicațiilor. Conceptul de bază este așa-numitul model de proces prototip. Acesta servește la flexibilitatea dezvoltării software în comparație cu modelele procedurale clasice și la adaptarea rapidă la cerințele în schimbare. Lucrul obișnuit despre instrumentele de dezvoltare rapidă a aplicațiilor este că acestea vă permit să trageți și să fixați interfața de utilizator și să personalizați proprietățile folosind un designer. De asemenea, sunt disponibile componente non-vizuale. De exemplu, pentru a interacționa cu o bază de date din aplicație sau pentru a invoca un dialog de fișier. Extensiile, pluginurile sau bibliotecile externe pot fi utilizate, de obicei, pentru a extinde gama de componente în mai multe moduri. Scopul RAD Tools este de a scuti dezvoltatorul de activități de dezvoltare software de rutină. Acest lucru crește semnificativ eficiența procesului de dezvoltare. Cu toate acestea, utilizarea acestui tip de instrument menține în permanență dezvoltatorul într-un control complet al codului sursă. Cele mai multe dintre mediile de dezvoltare integrate utilizate astăzi sunt pe piață de mulți ani și sunt în continuă evoluție pentru a asigura protecția investițiilor într-o oarecare măsură. Software-ul produs pe această bază poate fi utilizat de obicei ani mai târziu într-o nouă versiune a instrumentului RAD să fie editate și dezvoltate în continuare. Într-o altă direcție este tendința pe care cineva ar dori să amâne dezvoltarea de aplicații de afaceri către departamentele de specialitate. Capacitățile de dezvoltare sunt reduse, iar cererea de soluții software în companii este în continuă creștere. Utilizatorii cu experiență tehnică și pricepuți (Citizen Developer) pot fi capabili să își asume unele dintre sarcinile de dezvoltare. În acest scop, li se oferă instrumente extrem de integrate care le permit să creeze în mare parte soluții software. Aceste instrumente sunt denumite Low Code sau, în cazuri speciale, fără platforme de cod. Low înseamnă un cod cât mai mic atunci când creați software. De obicei, sunt utilizate pentru aplicații de vânzare, de marketing sau de planificare a producției. Încep de la nivelul funcțiilor unui software (cazuri de utilizare). Există un potențial mare de standardizare aici, cum ar fi introducerea datelor bazate pe formular, crearea interfeței cu utilizatorul, implementarea fluxului de lucru și conectarea la IT-ul companiei existente. Niciun sistem de cod nu promite livrarea de software fără codificare. Cu toate acestea, acest lucru poate funcționa numai pentru sarcini […]

Read More

Cum se utilizează corect analiza statică

Acualmente se vorbește din ce în ce mai mult despre analiza statică pentru căutarea vulnerabilităților ca etapă necesară a procesului de dezvoltare. Cu toate acestea, mulți vorbesc și despre problemele analizei statice. Dacă ați încercat vreun instrument specializat, puteți fi înspăimântat de rapoarte lungi, cu recomandări confuze, dificultăți în configurarea instrumentului și falsuri pozitive. Deci este încă necesară analiza statică? Experiența sugerează că este necesar. Și multe dintre problemele care apar atunci când vă uitați prima dată la instrument, este destul de posibil să rezolvați. Voi încerca să vă spun ce poate face utilizatorul și cum ar trebui să fie analizatorul astfel încât utilizarea sa să fie utilă și să nu se introducă „un alt instrument inutil, de care are nevoie Security Officer”. Despre analiza statică Deci, am vorbit deja despre limitările teoretice ale analizei statice. De exemplu, analiza statică profundă încearcă să rezolve probleme care sunt exponențiale în complexitate. Prin urmare, fiecare instrument caută un compromis între timpul necesar, resursele cheltuite, numărul de vulnerabilități găsite și numărul de falsuri pozitive. De ce avem nevoie de analize aprofundate? Orice IDE găsește foarte repede erori, uneori chiar și legate de securitate – care sunt unele probleme exponențiale? Un exemplu clasic este SQL injection (și orice altă injecție, cum ar fi XSS, RCE și altele asemenea), care trece prin mai multe funcții (adică citirea datelor de la utilizator și executarea interogării apar în diferite funcții). Căutarea acestuia necesită o analiză interprocedurală a fluxului de date, iar aceasta este o sarcină de complexitate exponențială. De acord, fără a căuta astfel de vulnerabilități, analiza nu poate fi considerată profundă. Din același motiv, trebuie să analizați codul în întregime și nu în părți – altfel, vulnerabilitățile interprocedurale pot fi ratate. În ultimii ani, am acumulat multă experiență în comunicarea cu clienții (potențiali) ai diferiților analizoare statice. În special, discutăm revendicările la instrumente pe baza rezultatelor primei utilizări (pilot). Majoritatea revendicărilor urmează într-un fel sau altul din limitările teoretice ale tehnologiei. În plus, este posibil ca instrumentele să nu aibă pur și simplu funcționalitatea de care utilizatorul are nevoie. Cu toate acestea, în opinia noastră, analizatorii se pot deplasa (și se îndreaptă) către utilizator în ceea ce privește rezolvarea problemelor identificate mai jos. Dar, de asemenea, trebuie să poți folosi analizoare, nivelând consecințele acelorași probleme – după cum se dovedește, acest lucru nu este atât de dificil. Hai să mergem în ordine. Vă puteți imagina o situație de model: decideți să încercați tehnologia în acțiune sau să alegeți un analizor static – efectuați un pilot. Desigur, nu aveți încredere în cazurile de test ale furnizorului și doriți să încercați să analizați codul dvs. (în același timp puteți găsi vulnerabilități reale și să le remediați). Vi se oferă un program de instalare sau o mașină virtuală pre-configurată cu un sistem pentru o perioadă scurtă de timp. Începutul analizei Mai întâi trebuie să lansați analiza. Accesați interfață și totul pare clar: încărcați arhiva cu codul sursă și faceți clic pe „analiză”. Dar nu: primiți mai multe formulare cu câmpuri diferite care trebuie completate cumva. Este necesar să indicați limbaje de programare, unele setări ale analizorului, selectați pachete de vulnerabilitate (de unde știți ce este inclus în ele?) Ș.a. Treci acest test și începe analiza. Ah, nu – o eroare de scanare. „Formatul nu corespunde cerințelor”, „Este necesar un […]

Read More

S-a anuntat oficial combinarea FMXLINUX cu DELPHI ȘI RAD STUDIO

Embarcadero Technologies a ajuns la un acord de distribuție OEM cu Eugene Kryukov pentru FmxLinux. Începînd cu 26 Iunie 2019, clienții Delphi și RAD Studio, cu mentenanță activă a edițiile Enterprise sau Architect, pot descărca, instala și utiliza FmxLinux pentru a construi aplicații FireMonkey pentru platforma Linux 64-bit. Se permite utilizarea atât pentru a adăuga Linux ca platformă la o aplicație FireMonkey existentă, fie pentru a construi o aplicație FireMonkey complet nouă pentru aplicații Linux.  De ce anume FMXLINUX? FmxLinux adaugă optiunea de dezvoltarea FireMonkey client UI pe Linux și adaugă abilitatea de a extinde suportul platformei noastre Linux de la server la scenarii desktop și chioșc. Aceasta nu este o ofertă unică, ci un acord de distribuție pe termen lung, deci v-om continua să susținem clienții Linux prin FmxLinux și în versiunile viitoare ale RAD Studio. FireMonkey pentru Linux oferă posibilitatea de a crea aplicații GUI pentru Linux, prin extinderea cross-platform framework pentru FireMonkey de la Delphi FmxLinux extinde suportul Delphi de la aplicațiile server la aplicațiile client FMX pentru distribuții populare Linux Include mai multe stiluri de user interface gata de utilizare Multe dintre componentele FMX, cum ar fi grilele, widget-urile, etc. funcționează perfect pe clienții Linux Folosiți funcțiile inovatoare ale RAD Studio, cum ar fi LiveBindings și multe altele, în aplicațiile client Linux Folosiți suportul WebKitGTK pentru a rula o aplicație FmxLinux ca aplicație Web HTML5 în browser

Read More