CRACI vs. Mend.io

Lyhyt vastaus

Mend.io on sovellusten tietoturva-alusta. Mend AppSec yhdistää omalle koodillesi tarkoitetun Mend SAST:n ja avoimen lähdekoodin riippuvuuksille ja konteille tarkoitetun Mend SCA:n, ja Mend Renovate pitää riippuvuudet ajan tasalla automaattisilla pull requesteilla. CRACI on GitHub Actions -yhteensopiva CI-runneri, joka tallentaa jokaisen ulkoisen riippuvuuden, jonka buildi hakee, ja tuottaa SBOM:n, alkuperätiedot ja vaatimustenmukaisuuden näytön tästä tallenteesta. Mend on skanneri. CRACI on tallentaja. Jos käytät Mendiä nyt, CRACI lisää kerroksen eikä korvaa yhtäkään.

Lyhyesti

Missä Mend.io on hyvä

Saavutettavissa olevan priorisointi. Mend SCA jäljittää kutsugraafin koodistasi suorien ja transitiivisten riippuvuuksien läpi ja päättelee, kutsuuko sovelluksesi todella haavoittuvaa funktiota. Se karsii listaa havainnoista, joihin tiimin on reagoitava. CRACI kokoaa haavoittuvuudet buildien ja repositorioiden yli, mutta se ei tee reachability-analyysiä.

Koodi riippuvuuksien lisäksi. Mend SAST kattaa yli 30 kieltä, ja Mend CLI skannaa avoimen lähdekoodin komponentit, oman koodin, konttikuvat ja infrastruktuurikoodin. CRACI ei tee mitään näistä.

Riippuvuuksien pitäminen ajan tasalla. Mend Renovate avaa pull requesteja vanhentuneista paketeista yli 90 paketinhallintatyökalussa. Renovate CLI- ja Community-versiot ovat ilmaisia; Enterprise lisää tietoturvaominaisuuksia ja tukea.

Lisenssit, haitalliset paketit ja SBOM:t. Mend SCA tunnistaa suorien ja transitiivisten riippuvuuksien lisenssit ja valvoo käytäntöjä, kuten AGPL:n estämistä kaupallisissa tuotteissa. Se merkitsee typosquat-paketit, dependency confusion -tapaukset ja paketit, joissa on takaovi- tai tietojen ulosvientikoodia. Se tuottaa SPDX- ja CycloneDX-SBOM:eja, ottaa vastaan kolmansien osapuolten SBOM:eja ja soveltaa VEX-tietoja.

Missä CRACI on erilainen

Havainnointia jälkikäteisen päättelyn sijaan

Mendin oma dokumentaatio suosittelee skannaamista build-vaiheen jälkeen, koska buildi antaa skannerille pääsyn yksityisiin rekistereihin ja ulkoisiin artefakteihin, ja skannaaminen ilman buildia voi antaa epätarkkoja tuloksia. Se on hyvä vaisto. CRACI vie sen askeleen pidemmälle: sen sijaan, että se lukisi projektin buildin valmistuttua, se tallentaa itse buildin.

CRACI-runnerin paketit tunnistava välityspalvelin havainnoi liikennettä pakettilähteisiin jobin ajon aikana npm-, PyPI-, RubyGems-, Composer-, Cargo-, Go-, Nix-, OCI-, apt-, apk- ja Git-lähteiden osalta sekä latausesiasetusten osalta. Riippuvuusnäyttö kulkee CI-välimuistien mukana, joten myös välimuistista palautetut paketit ovat mukana. Jokainen SBOM ilmoittaa kattavuutensa jobeittain ja välimuisteittain: Complete, Complete with connections, Incomplete, Unavailable tai Not recorded.

Build-verkon hallinta

Koska CRACI ajaa jobin, se voi rajata, minne jobi ottaa yhteyttä. Egress-käytännöt ovat oletuksena estäviä tai oletuksena sallivia, ja niissä on 24 sisäänrakennettua ohjelmistolähteiden esiasetusta sekä tyypitetyt mukautetut lähteet npm:lle, PyPI:lle, apt:lle, apk:lle, Go-proxylle, Nixille, Cargolle, OCI-rekistereille ja Gitille. Ne validoidaan ennen jobin käynnistymistä ja toimivat fail closed -periaatteella. Mend havaitsee haitallisen paketin, kun se on jo riippuvuuspuussasi. Egress-käytäntö rajaa jo etukäteen, mihin lähteisiin buildi pääsee. Nämä kaksi kerrosta toimivat eri hetkinä.

Näyttö buildista

API palauttaa SBOM:t, verkkojäljet ja alkuperätiedot. CRACI ei allekirjoita alkuperätietoja.

Inventaario siitä, mitä on käytössä missäkin

CRACI:n inventaarionäkymä näyttää tarkasti, mitkä ohjelmistoversiot ovat käytössä missäkin tuotteessa maailmanlaajuisesti. Kun uusi haavoittuvuus ilmenee, näet, missä tuotteissa on haavoittuva versio, eikä sinun tarvitse koota tietoa julkaisutiedotteista ja taulukoista.

Kumpi sopii

• Pääongelmasi on koodin ja riippuvuuksien havaintojen jono. Mend SAST:n, reachability-analyysin ja Renovaten kanssa on tehty juuri tähän.
• Sinun on todistettava, mitä kuhunkin julkaisuun meni. CRACI tallentaa sen buildeittain ja kertoo, kuinka kattava tallenne on.
• Buildisi tekevät muutakin kuin asentavat lukitustiedostosta. Työkaluketjujen lataukset, peruskuvat ja curl-haut ovat kohtia, joissa havainnointi tuo eniten lisäarvoa.
• CI/CD-putkesi ovat Azure DevOpsissa, Bitbucketissa tai CircleCI:ssä. Mend sopii nyt. CRACI tukee tällä hetkellä vain GitHub Actionsia, ja GitLab CI ja Jenkins ovat tiekartalla.

Kyberkestävyyssäädöksen näkökulmasta

Mend.io julkaisee CRA-vaatimustenmukaisuusoppaan ja sivun, joka kytkee sen tuotteet säädökseen: Mend AppSec CycloneDX- ja SPDX-SBOM:eille ja reachability-analyysiin perustuvalle priorisoinnille, Mend Renovate jatkuvalle haavoittuvuuksien käsittelylle riippuvuuspäivitysten kautta, ja lisenssien noudattaminen dokumentoituna tietoturvatilanteen rinnalla.

CRACI tuo näyttöä buildista: SBOM:n jokaisesta julkaisusta kattavuus ilmoitettuna, alkuperätiedot, jatkuvan seurannan ja SBOM-viennin CycloneDX- tai SPDX-muodossa. Se automatisoi merkittävän osan siitä ohjelmistotoimitusketjun näkyvyydestä ja näytöstä, jota yritykset tarvitsevat laajempaan CRA-vaatimustenmukaisuusprosessiinsa. Mikään yksittäinen työkalu ei tee tuotteesta vaatimustenmukaista. Katso CRA-vaatimustenmukaisuus ja mikä CRA on.

CRACI:n lisääminen Mend.io:n rinnalle

CRACI korvaa runnerin, ei GitHub Actionsia. Vaihda työnkulun runs-on arvoon craci, niin ajot näkyvät edelleen GitHubin käyttöliittymässä. Mend CLI -vaiheesi pysyy paikallaan buildin jälkeen. Aja yksi julkaisuputki CRACI:lla ja vertaa sen SBOM:ia Mendin inventaarioon samasta commitista.