CRACI vs. Black Duck

Det korte svar

Black Duck er en bred portefølje inden for applikationssikkerhed, bygget op omkring produktet til software composition analysis (SCA), med statisk analyse, binæranalyse, fuzzing og posture management omkring det. CRACI er en GitHub Actions-kompatibel CI-runner, der registrerer hver ekstern afhængighed, et build henter, og producerer SBOM, provenance og compliance-dokumentation ud fra den registrering. Black Duck er en scanner, og en grundig en af slagsen. CRACI er en registrator. For de fleste producenter supplerer de to hinanden.

Overblik

Hvad Black Duck gør godt

At finde open source, som ingen har deklareret. Black Duck SCA kombinerer scanning af pakkemanagere med signaturscanning, detektion af snippets for delvis eller ændret kode og binæranalyse. Det betyder noget, når kode er kopieret ind i et repository eller vendoret uden et manifest. Fundene bygger på Black Duck Security Advisories, med alvorlighed, prioritering og reachability-målinger, og platformen markerer ondsindede pakker.

Licenser. Black Duck identificerer deklarerede og ikke-deklarerede licenser, fuld licenstekst og copyright-data, og dets KnowledgeBase følger mere end 2.750 open source-licenser. CRACI medtager deklarerede licensmetadata i sin SBOM-eksport og håndhæver licenspolitikker.

Binærfiler og firmware. Black Duck Binary Analysis undersøger eksekverbare filer, biblioteker, containere og firmware uden adgang til kildekoden. Modtager du binærfiler fra tredjeparter, eller skal du tjekke et færdigt firmware-image, er det et område, CRACI ikke dækker.

Mere end SCA. Coverity leverer statisk analyse på tværs af 22 sprog, Defensics laver fuzz-test, og Software Risk Manager samler fund som et system til application security posture management (ASPM). Black Duck integrerer med Jenkins, GitLab, Azure DevOps, Bitbucket Pipelines, CircleCI, TeamCity og mange andre CI-systemer. Dets Bridge CLI kan åbne Fix PRs, der opgraderer sårbare direkte afhængigheder.

Hvor CRACI er anderledes

Det er vidne til buildet

Hver teknik ovenfor inspicerer noget: et manifest, et kildetræ, en binærfil. Ingen af dem ser buildet, mens det kører, herunder de toolchains, install-scripts, base-images, release-downloads og cachede pakker, der former outputtet, men måske ikke er synlige i det. CRACI er runneren, så det ser den aktivitet direkte. En pakkebevidst proxy overvåger trafikken til pakkekilderne for npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk og Git-kilder samt download-presets. Dokumentationen for afhængighederne følger med CI-caches.

Hver SBOM angiver sin fuldstændighed, pr. job og pr. cache, i fem statusser: Complete, Complete with connections, Incomplete, Unavailable og Not recorded. Eksport til CycloneDX og SPDX er inkluderet.

Det styrer buildets netværk

Fordi CRACI kører jobbet, kan du sætte en egress-politik for det: default deny eller default allow, 24 indbyggede presets for softwarekilder og typede brugerdefinerede kilder til npm, PyPI, apt, apk, Go-proxyen, Nix, Cargo, OCI-registries og Git. Politikker valideres, før jobbet starter, og blokerer ved fejl (fail closed), og CRACI kan advare dig, når et job overtræder en politik. En scanner rapporterer om det, der kom ind. En egress-politik begrænser, hvad der kan komme ind.

Provenance og overvågning

API'et returnerer SBOM'er, netværkstraces og provenance. CRACI bliver ved med at genvurdere overvågede SBOM'er for nye sårbarheder.

Et inventar 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.

Hvilken passer bedst, og hvornår du skal bruge begge

• Embedded-produkter bygget med Yocto. CRACI kan køre Yocto- og BitBake-builds på sine runnere, op til 32 vCPU og 96 GB, med en egress-politik, der supplerer BitBakes egne netværkskontroller. CRACI's SBOM registrerer, hvad buildet hentede, inklusive værtspakker og GitHub Actions, som Yoctos create-spdx-SBOM udelader, med en package URL for hver Rust-crate. Black Duck Binary Analysis kan derefter tjekke det færdige image. Se Yocto-guiden.
• Kode med en lang historik af kopieret eller vendoret open source. Snippet- og signaturscanning er Black Ducks styrke. Behold den.
• Teams på GitHub Actions, der har brug for release-dokumentation. CRACI registrerer hvert build, opbevarer SBOM'en og provenance-dataene for det og eksporterer SBOM'er som CycloneDX eller SPDX.
• Pipelines på Jenkins, GitLab eller Azure DevOps. Black Duck er det rette valg i dag. CRACI understøtter i dag kun GitHub Actions, med GitLab CI og Jenkins på roadmappen, så de pipelines skal flyttes først.

Til Cyber Resilience Act

Black Duck udgiver en række CRA-sider om frister, kravet om rapportering af sårbarheder inden for 24 timer og hvorfor det anser SCA alene for utilstrækkeligt til CRA. Det knytter sin portefølje til forordningen: Black Duck SCA til at analysere kodebaser op imod EUVD- og NVD-data og generere SBOM'er, Coverity med en CRA-tilpasset checker-mulighed annonceret i juli 2026, Defensics til robusthedstest og Software Risk Manager til politikbaserede kontrolpunkter. Argumentet er, at forordningen kræver flere lag: SCA til komponenter plus statisk og dynamisk test af din egen kode og dine tjenester.

CRACI tilføjer dokumentation fra selve buildet: hvad der gik ind i hver release, hvor komplet den registrering er, og løbende overvågning bagefter, med SBOM'er, der eksporteres som CycloneDX eller SPDX. Det automatiserer en væsentlig del af den indsigt i og dokumentation for softwareforsyningskæden, som virksomheder har brug for i deres bredere proces for CRA-compliance. Læs mere om CRA-compliance og industriel IoT.

Tilføj CRACI ved siden af Black Duck

CRACI erstatter runneren, ikke GitHub Actions. Ændr runs-on til craci i et workflow, og kørslerne vises stadig i GitHubs brugerflade. Black Ducks scanningstrin bliver i workflowet. Vælg én produkt-release, sammenlign CRACI's build-time SBOM med din Black Duck-stykliste, og gennemgå de komponenter, som kun ét af værktøjerne fandt.