CRACI vs Sonatype

Det korte svar

Sonatype er bedst til styring af open source: politikker, der afgør, hvilke komponenter der er tilladt, en firewall, der stopper dårlige pakker ved repositoriet, og analyse, der fortæller dig, hvad der endte i din applikation. CRACI er en GitHub Actions-kompatibel CI-runner, der registrerer hver ekstern afhængighed, et build trækker ind, og producerer SBOM, provenance og compliance-dokumentation ud fra den registrering. Sonatype er en scanner og en portvagt. CRACI er en registrator, hvis policy gates også kan blokere et build på baggrund af fund. De fleste teams, der har brug for begge, vil køre dem side om side.

Hvilket Sonatype-produkt er hvad

Sonatype sælger flere produkter, og navnene betyder noget for denne sammenligning:

• Sonatype Lifecycle er produktet til software composition analysis (SCA) og politik, der kører selvhostet eller som SaaS.
• Sonatype Repository Firewall blokerer komponenter, der ikke består dine politikker, og sætter dem i karantæne, før de kommer ind i dine repositories. Det er designet til Sonatype Nexus Repository. Sonatype Firewall Pro dækker andre repository managers, såsom JFrog Artifactory, Cloudsmith og GitHub Packages, til npm, Maven, PyPI og NuGet.
• Sonatype SBOM Manager importerer, overvåger og deler SBOM'er, med et VEX-workflow.

Produktpakkerne er ved at ændre sig. Sonatypes prisside siger, at alle Lifecycle-funktioner nu er inkluderet i Sonatype Guide, at nye kunder køber Guide til SCA og styring, og at Guide også indeholder compliance-funktionerne fra SBOM Manager.

Overblik

Hvad Sonatype gør godt

Politik i stor skala. Lifecycle leveres med 18 standardpolitikker og mere end 30 tilpasselige begrænsninger, der dækker regler for sikkerhed, jura og arkitektur. Licenspolitikker spænder over mere end 2.000 open source-licenser. Det prioriterer fund med data om reachability, breaking changes og tilgængelige opgraderinger og kan åbne Golden Pull Requests med de foreslåede opgraderinger.

Ser på det, buildet producerede. Lifecycle-integrationer bruger som standard Advanced Binary Fingerprinting, som undersøger alt, der er inkluderet i applikationen efter buildet, også indlejrede afhængigheder, og kan identificere omdøbte eller ændrede komponenter. Først derefter falder det tilbage på lockfiles og manifester. Hver scanningsrapport kan eksporteres som en SBOM i CycloneDX eller SPDX.

Stopper dårlige pakker ved døren. Repository Firewall håndhæver dine standarder for sikkerhed, licenser og kvalitet ved download og sætter mistænkelige komponenter i karantæne. CRACI har intet tilsvarende i dag: Blokering af pakker er på roadmappen.

Passer til enhver pipeline. Sonatype integrerer med Jenkins, GitHub Actions, GitLab CI, Azure DevOps og Bamboo samt Maven, Gradle og en CLI til andre CI-servere. CRACI understøtter kun GitHub Actions i dag, med GitLab CI og Jenkins på roadmappen.

Hvor CRACI er anderledes

Det registrerer buildet i stedet for at analysere outputtet

Binær fingerprinting fortæller dig, hvad der er inde i den færdige applikation. Det fortæller dig ikke, hvad buildet downloadede undervejs: compilere og toolchains, install-scripts, base-images, release-binærfiler hentet med curl eller pakker gendannet fra en cache. Det ser CRACI, fordi det er runneren. En pakkebevidst proxy observerer trafik til pakkekilder, mens jobbet kører, og dækker npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder samt kilde- eller download-presets. Dokumentationen for afhængighederne følger med CI-caches, så cachelagrede pakker stadig tælles med.

Hver SBOM angiver sin egen fuldstændighed, pr. job og pr. cache: Complete, Complete with connections, Incomplete, Unavailable eller Not recorded. Har registreringen et hul, ved du det.

Det styrer, hvor buildet kan nå hen

Repository Firewall styrer, hvad der kommer gennem repositoriet. En egress-politik i CRACI styrer, hvad buildet overhovedet kan nå. Politikker er default deny eller default allow, med 24 indbyggede presets for softwarekilder og typede brugerdefinerede kilder til npm, PyPI, apt, apk, Go-proxyen, Nix, Cargo, OCI-registries og Git. De valideres, før jobbet starter, og blokerer ved fejl (fail closed). Sammen lader de to dig sikre, at build-jobs kun henter pakker fra de kilder, du godkender, og at de kilder kun leverer pakker, du tillader.

Det holder øje med det leverede

API'et returnerer SBOM'er, netværkstraces og provenance. CRACI signerer ikke provenance. CRACI samler sårbarheder på tværs af builds og repositories og bliver ved med at genvurdere overvågede SBOM'er.

Et overblik over, hvad der er udrullet hvor

CRACI's inventaroversigt viser præcis, hvilke softwareversioner der er udrullet til hvilke produkter, globalt. Når en ny sårbarhed dukker op, kan du se, hvilke produkter der kører den berørte version, i stedet for at stykke det sammen fra release notes og regneark.

Hvornår du skal bruge begge

• Du kører allerede Nexus Repository med Firewall. Behold det som portvagt. Tilføj CRACI, så hvert build har en registrering af, hvad det hentede, og en egress-politik, der holder builds på dine godkendte kilder.
• Din juridiske afdeling er afhængig af Lifecycles licenspolitikker. Behold dem. CRACI inkluderer metadata om deklarerede licenser i sin SBOM-eksport og håndhæver også licenspolitik.
• Du samler SBOM'er i SBOM Manager. SBOM Manager importerer CycloneDX og SPDX, de samme formater, som CRACI eksporterer, så SBOM'er fra buildet kan ligge ved siden af dem, du allerede administrerer.
• Dine pipelines er på Jenkins eller Azure DevOps. Sonatype passer til det i dag. CRACI kræver, at de pipelines først er på GitHub Actions; Jenkins er på roadmappen.

Til Cyber Resilience Act

Sonatype offentliggør en CRA-brugervejledning og en CRA-tjekliste og positionerer SBOM Manager som sit CRA-produkt. Dets vejledning fremhæver generering af VEX-filer til at rapportere om kendte sårbarheder i SBOM'er og Nexus Repository som et opdateringssted til distribution af sikkerhedsopdateringer.

CRACI dækker dokumentationssiden fra buildet: en SBOM for hver release med angivet fuldstændighed, provenance, løbende sårbarhedsovervågning og SBOM-eksport som CycloneDX eller SPDX. Det automatiserer en væsentlig del af den synlighed i og dokumentation for softwareforsyningskæden, som virksomheder har brug for i deres bredere CRA-compliance-proces. Ingen af værktøjerne gør et produkt compliant alene. Se CRA-compliance og hvad CRA er.

Tilføj CRACI ved siden af Sonatype

CRACI erstatter runneren, ikke GitHub Actions. Ændr runs-on til craci i et workflow, og kørsler vises stadig i GitHubs brugerflade. Dine Sonatype-trin bliver i workflowet. Start med én release-pipeline, sammenlign CRACI's SBOM med din Lifecycle-rapport, og se på, hvad kun én af dem så.