Two ways to put CRACI in front of your build
Pick whichever is useful right now, and we'll shape the call around it.
Artūrs Vavilovs
Account Executive, CRACI · Helsinki
CRACI is a team of 14 in Helsinki, backed by Lifeline Ventures. We're onboarding every team personally before general availability, and we won't ask you to rip anything out to find out whether this is useful.
What we'll go through
- Point one representative workflow at CRACI (runs-on: craci) and compare build time and cost side by side
- Walk through the SBOM the build recorded, including the hidden dependencies that lockfile-based tools miss
- See how the egress policy blocks connections a build does not need, before they leave the runner
Is build time something your team complains about, or has everyone quietly accepted it?
- Where the build's SBOMs and vulnerability records fit the frameworks you answer to: the CRA, NIS2, ISO 27001, SOC 2 and PCI DSS
- See how every shipped build is monitored for new vulnerabilities, and how build history shows which builds contained one and for how long
- If the CRA applies to you, how CRACI submits the vulnerability notifications to the authorities on your behalf
When a vulnerability lands in a dependency, how long does it take you to find out which of your releases contain it?
Pick a time
Choose a slot, add your name and email, and the invite goes out straight away.
What you can check on the call
About 2x faster builds
Compared with GitHub-hosted runners, thanks to faster hardware, shorter queue times and caching. Whether you see the same on your workflows is what the call is for.
SBOMs recorded from the build itself
CRACI sees what each job pulls in as it runs, so the SBOM describes what shipped, not what a lockfile suggests.
Egress policy at the runner
With a default-deny policy the runner allows only the sources a build needs, so a compromised package cannot send your secrets to an attacker's host.
SBOMs from the build that shipped
CycloneDX and SPDX exports with every transitive dependency, recorded while the release built rather than reconstructed afterward.
Exposure you can show
Shipped builds are re-checked as new vulnerabilities appear, and build history shows which builds contained one and for how long.
Provenance through the API
The API returns SBOMs, network traces and provenance for each build, so the evidence comes out of the build itself.
Backed by
