We address the technical requirements of
CRANIS2UKSC

How it looks today

Before we propose anything, we describe the state we usually find.

Most of your product is someone else's code. No one has to attack you directly — a library or a tool you use is enough. One compromised element reaches everyone who downloads it, along with the update.

What we do

We define the scope after an assessment. Rarely do all four elements come in at once.

You know what your product is built from.

We generate the bill of materials automatically with every release, not by hand once a year — so the question "do you use this library" stops being a week-long project. We sign artifacts so the client can independently verify they received what came out of your process. New dependencies pass a check before they enter the project, because the cheapest moment to reject a risky library is before it is added. We arrange the whole thing to close the technical layer of the CRA requirements.

SyftCosignTrivyGitLab CI

Four stages

01

We create a bill of materials

An SBOM generated automatically with every release, not once a year by hand.

02

We sign artifacts

The client can verify they received what came out of your process.

03

We control dependencies

A new library passes a check before it enters the project.

04

We prepare for CRA

Technical documentation and the ability to respond to a vulnerability report.

What stays with you

You answer "do you use this library" in a minute

The client can independently verify the package's origin

The bill-of-materials requirement is closed technically

Questions we get
most often

How long does it take?+

We define the scope after a call and an assessment. Smaller engagements close in a few weeks; larger ones we split into stages, so the result is visible after the first.

Do we have to give you access to the code?+

Usually not to all of it. In most cases access to the build pipeline configuration and organization settings is enough. We define the scope in writing before we start.

Does our team have to get involved?+

Yes, but not full time. We need contact with someone who knows the system, and a review of our changes. The rest is on us.

What if we already have tools?+

We plug into what already works for you. Replacing a tool is the most expensive and least often necessary way to improve security.

Do we become dependent on you?+

You don't have to. We work with standards and tools your team knows or will quickly learn — not a proprietary method only we understand. Everything is documented and handed over.

Won't this slow down releases?+

We wire controls so they run in the background. If one starts blocking work, we tune it or move it to a different point in the process.

Want to reduce risk
and IT costs?

Book a free call →
We reply within 24h on business days