DevSecOps in the pipeline

We add automated security checks to your pipelines so that vulnerable code, dependencies or container images do not reach production. Every release gets a software bill of materials (SBOM) and a signature that is verified before deployment.

from CZK 150,000

3 to 10 weeks depending on the option, up to 3 pipelines CZK 150,000, 4 to 8 pipelines CZK 280,000, 9 to 15 pipelines CZK 400,000. Excl. VAT.

Book a consultation

What we offer

We roll the checks out gradually. At first they only report, once tuned they start blocking. That way false positives do not stop development and old findings do not block work overnight.

The result is a pipeline that guards security on its own, and evidence you can show an auditor, for example for the secure development requirements of NIS2.

We do not write applications. We work only on infrastructure, cloud and DevOps.

When it makes sense

NIS2, customers or internal audit require secure development and traceability.
You have no overview of vulnerabilities in dependencies and container images.
Your security team checks manually, late and only at random.
You want to be sure that only what passed your pipeline goes to production.

What you get

Automated security checks in every build.
Builds with critical and high findings blocked according to your policy.
An SBOM and a signature for every release, signature verified before deployment.
A clear exception process with an owner and an expiry date.
A findings overview for the security team and evidence for audits.

DevSecOps implementation in detail →

What exactly we do

We prefer the tools you already have. The default set is open source, so licences are not a requirement.

Static code analysis (SAST): For example Semgrep or SonarQube, depending on the tools you already use.
Dependency and licence checks (SCA): Known vulnerabilities in libraries and problematic licences.
Image and infrastructure as code scanning: Trivy and Checkov for containers and Terraform.
Secrets in code: Gitleaks in the pipeline and a recommendation for pre-commit checks.
SBOM: A component list in CycloneDX or SPDX format for every artifact.
Artifact signing: Cosign, with the signature verified at deployment (in Kubernetes with Kyverno), so an unsigned image cannot be deployed.
Policy and gate: What blocks, thresholds by severity, an exception process with expiry.
Findings overview: A central view for security, based on your tools, for example GitHub Advanced Security or DefectDojo.

Options and scope

The price depends on the number of pipelines:

Option	Scope	Price	Duration
S	up to 3 pipelines	CZK 150,000	3 to 4 weeks
M	4 to 8 pipelines	CZK 280,000	5 to 6 weeks
L	9 to 15 pipelines	CZK 400,000	8 to 10 weeks
Over 15	each extra pipeline	+CZK 25,000	depends on scope

Who works on it

Three people work on the project. The effort in days is for option M.

Senior, project lead
8 days

Responsible for
Designs the pipeline security policy, agrees it with your security team, reviews blocking rules and exceptions, writes the security report, runs the workshop.

What you get from them
Main contact, policy, report
Middle
10 days

Responsible for
Integrates the checks into pipeline templates, SBOM, signing, signature verification at deployment, the blocking gate.

What you get from them
Working checks and gate
Junior
12 days

Responsible for
Sets up the checks in each pipeline, collects the baseline findings, tunes false positives, writes documentation.

What you get from them
Configured pipelines, documentation

We assign work by complexity: juniors do routine work from templates, the middle takes the harder parts, and the senior owns the design, quality control and risk decisions. You do not need to decide who does what. The effort in days is indicative and only explains the price. The price is fixed and does not depend on the days actually worked.

How the project runs

The project has four phases; the timeline is for option M (4 to 8 pipelines). The key step is moving from report mode to blocking mode, which we do only after tuning.

Week 1: analysis and security policy
Goal: Agree what is checked and what blocks.
- Inventory of pipelines, languages and the tools you already have.
- Tool choice for each type of check.
- Policy design: thresholds, what blocks, exception process, owners.
- Policy approved by your security team.
Output: Approved pipeline security policy. Who: senior, inventory by the junior
Weeks 2 and 3: rollout in report mode
Goal: Run the checks in all pipelines, without blocking yet.
- Checks integrated into templates and individual pipelines.
- Connection to the findings overview.
- Baseline: how many findings exist today.
Output: All pipelines run the checks, findings baseline. Who: middle templates, junior pipelines
Week 4: tuning, SBOM and signing
Goal: Remove false positives and add traceability.
- Tuning rules and false positives.
- Triage of existing findings with developers: we explain what they mean and how to fix them (your developers do the fixes).
- SBOM and a signature for every artifact.
Output: Tuned checks, SBOM and signatures. Who: junior tuning, middle SBOM and signing, senior triage
Weeks 5 and 6: blocking and handover
Goal: Switch on blocking and hand over to your team.
- Switch to blocking: new critical and high findings stop the build, old baseline findings have a remediation plan.
- Signature verification before deployment.
- Security report and audit evidence.
- Documentation and a workshop for developers and security.
Output: Pipelines with blocking, report, evidence, a trained team. Who: middle blocking, senior report and workshop

How we work together

Main contact: The project lead (a senior). Accountable for the result, deadlines, risks and decisions. Day to day you can talk to anyone on the team directly.
Communication: A shared Slack or Teams channel and a ticketing system of your choice. Every question and change leaves a trail.
Kick-off: At the start we confirm the scope, access, contacts and the dates of the key milestones.
Weekly status: A short 15 to 30 minute sync: what is done, what is next, what we need from you and which risks we see.
Final readout: We present the results to your team and management and go through the next steps.
Escalation: Junior → middle → project lead. If a deadline or a major risk is at stake, the project lead contacts you the same day.
Working hours: Working days, 8:00 to 17:00 Central European Time. Production changes happen in a window you choose, always through your change management.

What we need from you

The timeline holds if we have the following. If something is delayed, the schedule moves by the same time and we tell you straight away.

Access to the repositories and the CI platform (changes through pull requests you approve).
A security contact who approves the policy and exceptions.
Developers from each team for findings triage (about 1 hour per team).
Decisions on tools and any licences.
Cluster access for signature verification, if you deploy to Kubernetes.

Access and security

Every team member has their own named account. We do not use shared accounts.
We ask only for the permissions a phase needs. Where read access is enough, we work read-only.
We do not take data out of your environment. Our documents contain only the summaries the result needs.
When the project ends, you remove our access, or we remove it on request and confirm it.
If you wish, we sign an NDA before the kick-off.

What is included and what is not

Included in the price

SAST, SCA, image and IaC scanning, secrets in code
SBOM and artifact signing, signature verified before deployment
Pipeline security policy and exception process
Findings overview, security report, audit evidence
Documentation and workshop

Not included: priced separately or on your side

Fixing vulnerabilities in application code (done by your developers, we help interpret them)
Dynamic testing of the running application (DAST) and penetration tests
Licences for commercial tools
ISMS and security documentation outside the pipelines

If we find during the project that reality differs from what we assumed, we tell you before we work outside the scope. We send a short estimate of the impact on price and timeline and continue only once you agree.

Deliverables and acceptance

Deliverable	Contents	Form
Pipelines with checks	All pipelines in scope with checks and blocking	In your repository
Security policy	Thresholds, blocking, exceptions, owners	Document
SBOM and signatures	For every release	Automatic in the pipeline
Security report	Baseline, current state, trend	PDF and findings overview
Audit evidence	Proof of checks in the development process	Document
Workshop	For developers and security	Recorded meeting

The project is done when:

All pipelines in scope run the agreed checks.
A test build with a critical vulnerability is blocked.
Every release has an SBOM and a signature.
An unsigned image cannot be deployed (if you deploy to Kubernetes).
Security has access to the findings overview.

We hand over the deliverables and go through them with you. We incorporate comments in one round within 5 working days of receiving them.

Risks and how we handle them

Risk	How we handle it
A large number of findings at the start	Old findings go into the baseline with a remediation plan. We block only new critical and high ones.
False positives slow development down	Checks only report at first. Blocking is switched on after tuning.
Checks slow down the build	Parallel runs, caching, and a split into fast checks in every build and thorough nightly checks.
Many languages and technologies	We choose the tools in the first phase based on your languages.

Price and terms

from CZK 150,000 excl. VAT for option S (up to 3 pipelines). M CZK 280,000, L CZK 400,000, over 15 pipelines +CZK 25,000 each.

Duration by option: 3 to 10 weeks.
Prices exclude VAT, invoiced in CZK or EUR.
Work outside the scope: a separate quote, always in advance.

What can follow

Next steps

1A short 30 minute call: we look at your environment and check that the service fits what you need.
2We confirm the scope, the start date and the contact people.
3We send the contract and the list of access we need to start.

Frequently asked questions

Will it stop our development?

No. We roll the checks out gradually and switch on blocking only after tuning. Old findings block nothing.

Do we have to buy licences?

No. The default tool set is open source. If you already have a commercial tool, we use it.

Will you also fix the vulnerabilities found?

Your developers fix the code. We explain what a finding means and how to fix it, and help with priorities.

Tell us what you are working on.

Thirty minutes, free. We reply within one working day.