01
Security architecture review
Threat modeling, trust boundaries, identity, cryptography. We review the design before it becomes production - and you leave with a list of concrete changes, not a risk spreadsheet.
Secure development · applied research
Security is not a layer on top. It is a property of the architecture.
cybbrio is a small lab focused on cybersecurity and AI. We design secure applications and infrastructure, test and audit them, and introduce secure development wherever security is a priority - in banks, at technology vendors, in AI environments and in software companies with their own specific rules.
Four areas we specialise in
01 - 04
02
Secure development and DevSecOps
Security across the whole development lifecycle: SAST, DAST and SCA implementation, dependency and licence checks, secret management, vulnerability management and CI gates. Tuned so the team is not drowning in false positives. The same foundation carries our Cyber Resilience Act readiness work - most of the Annex I requirements are exactly this.
03
IoT and smart building security
Network, embedded devices and the physical world in one. We analyse integration platforms, device communication and system behaviour at the edge - including anomaly detection locally, without the cloud.
04
AI and shadow AI security
Unsanctioned use of AI tools inside the company as well as AI security in your product: prompt injection, data leaking into models, and rules people can actually follow. We also secure AI agents in corporate environments - so they do not slow developers down.
+ web application penetration testing · risk analysis · threat modeling · oversight of outsourced development
For software companies
We understand teams that build software themselves
A software company does not need an audit that makes work impossible afterwards. It needs controls that pass code review, find and mitigate vulnerabilities fast, fit into the pipeline and do not stop a release. That is most of our work - security written in the language of developers, not compliance spreadsheets.
Security that does not block releases
CI gates tuned to catch what matters instead of blocking every merge.
AI agents in the development environment
Agents and assistants have access to code, secrets and infrastructure. We set their boundaries and oversight so they do not get in developers' way.
Local inference instead of the cloud
We work on running AI agents and models securely on premises - inference at your side, so code, secrets and client data never leave your infrastructure. Our automated security review builds on the same foundation.
Training for developers
Specialised security training written for developers, not for management - including safe use of AI tools and agents in development. On your code and your cases.
Your environment, not a template
Monorepo, in-house framework, legacy core or an embedded target - we work with what you have, not with the ideal case from a methodology.
Examples of what we solve
problem → our answer
Developers use AI tools and nobody knows what data goes in.
We map the real use of AI in the company, set rules for data and give agents boundaries and oversight - so nobody has a reason to work around them.
Dependencies have not been updated for years and everyone fears the upgrade.
A dependency inventory and SBOM, a step-by-step update plan and a CI gate that only guards what matters. No single jump across three major versions.
Anyone can slip a package into the build.
Supply chain security: version pinning, signing and verification of artefacts, isolated builds and a review of permissions in CI and registries.
Development runs on machines with SSH into production.
We separate environments and identities, introduce time-bound access through a bastion or just-in-time, and a traceable audit trail. Developers reach production when they have a reason to.
Secrets live in the repository and in .env files.
We introduce secret management, rotation and scanning of the repository history. The leak is then solved once, systematically, not again at every incident.
Security is dealt with a week before release.
Threat modeling over the design and security criteria in the definition of done. A fix in the design costs a fraction of a hotfix after a penetration test.
Nobody knows exactly what is exposed to the internet.
We map the surface: subdomains, forgotten test instances, unrestricted admin panels and APIs without authentication. Most incidents start with something forgotten.
There is no DevSecOps, security is a one-off exercise.
We build DevSecOps from the ground up: SAST and DAST in the pipeline, SCA over dependencies and licences, container and IaC scanning, secret detection in the repository and gates with sensible thresholds. Set up so the team can run it without us.
Security maturity levels are not defined.
We set the target security maturity according to what the company actually needs - one level for an internal tool, another for a product in a regulated environment - plus measurable steps to get there.
There is no threat catalogue or risk analysis.
We build a threat catalogue for your systems and a risk analysis that can actually support decisions - not a document filed away for the auditor.
Adopting AI without letting data leave the company.
We design and build local AI solutions on your own inference - models and agents run on your side and data stays inside. We use the same setup for automated security review of code.
A product is going to the EU market and nothing about the CRA is documented.
We determine the product class, run a gap analysis against Annex I and fill in the missing processes and documentation. Reporting obligations apply from 11 September 2026 and full compliance from 11 December 2027 - there is less time than it seems.
What working with us looks like
pick a process and a step
Web application penetration test · step 01 / 05 · 1-3 days
Scope and rules
We agree the goals, boundaries, environment and communication channels. We define what is in scope, what must not be touched and what happens if we find something critical in the middle of the night.
- Deliverable
- Test plan and rules of engagement
Web application penetration test · step 02 / 05 · 2-4 days
Recon and mapping
We map the application surface: endpoints, roles and permissions, authentication flows, dependencies and technologies used. The goal is to understand the system, not just run a scanner.
- Deliverable
- Attack surface map
Web application penetration test · step 03 / 05 · 3-8 days
Verification by exploitation
We verify findings by real exploitation - manually, with focus on application logic and chained flaws. Automation is only an assistant. Every step is documented so it can be reproduced.
- Deliverable
- Evidenced findings with reproduction steps
Web application penetration test · step 04 / 05 · 2-3 days
Report and priorities
We describe findings by their business impact, not just by the vulnerability name. Each one comes with reproduction, risk rating and a concrete fix proposal for developers.
- Deliverable
- Report and a walkthrough for the team
Web application penetration test · step 05 / 05 · 1-2 days
Retest
After the fixes we verify that the finding is really gone and that the fix did not introduce a new problem. The retest is part of the price, not an extra item.
- Deliverable
- Remediation confirmation
AI and shadow AI security · step 01 / 05 · 1-2 weeks
Mapping AI usage
We find out which AI tools are really used in the organisation, by whom and with what data - including the unsanctioned ones. No witch hunt; the goal is an accurate picture.
- Deliverable
- Register of AI tools and data flows
AI and shadow AI security · step 02 / 05 · 3-5 days
Data and risk classification
We define what may and may not be sent to models: trade secrets, personal data, source code, client data - together with the legal and contractual framework of the vendors.
- Deliverable
- Rules for handling data in AI
AI and shadow AI security · step 03 / 05 · 1-2 weeks
AI security in the product
Threat model of the AI component: prompt injection, indirect injection through processed data, excessive agent permissions, tool isolation and data leakage between customers.
- Deliverable
- Threat model and proposed controls
AI and shadow AI security · step 04 / 05 · 1-2 weeks
Controls and guarantees
Decision logging, human approval for sensitive actions, limits and budgets, resilience testing against manipulation. So AI can act, but never unsupervised.
- Deliverable
- Set of controls and test scenarios
AI and shadow AI security · step 05 / 05 · 3-5 days
Policy and training
A readable AI policy and short training for the team. Rules people can follow are the only defence against shadow AI that actually works.
- Deliverable
- AI policy and a trained team
Smart home security audit · step 01 / 05 · 1-2 days
Device and network inventory
We list what actually runs in the building: devices and protocols (KNX, Zigbee, Z-Wave, Modbus, IP cameras), cloud dependencies, remote access and who is responsible for what.
- Deliverable
- Map of the system and its dependencies
Smart home security audit · step 02 / 05 · 1-2 days
Segmentation and access
We check network separation, VLANs, remote access, password and role management. We care about who can reach what from where - including the integrator and the device vendor.
- Deliverable
- Findings in segmentation and identity
Smart home security audit · step 03 / 05 · 2-5 days
Device and traffic testing
We analyse device-to-device traffic, default passwords, update mechanisms, encryption and firmware. We look for ways the building could be controlled from outside.
- Deliverable
- List of vulnerable devices
Smart home security audit · step 04 / 05 · 2-3 days
System behaviour
We measure a baseline of normal operation and check what the system does during an outage, cloud loss or a targeted attack. Local anomaly detection at the edge builds on this baseline.
- Deliverable
- Scenarios and a detection proposal
Smart home security audit · step 05 / 05 · 1-2 days
Remediation plan
Measures ordered by risk and cost, split into what the integrator, the vendor and the user should do. Without replacing the whole installation.
- Deliverable
- Remediation plan and a retest date
CRA readiness (Cyber Resilience Act) · step 01 / 06 · 1-2 weeks
Product classification and scope
We determine which of your products fall within the scope of the regulation and into which class - default, important or critical. That decides whether self-assessment is enough or a notified body is required.
- Output
- List of products in scope and their classes
CRA readiness (Cyber Resilience Act) · step 02 / 06 · 2-4 weeks
Gap analysis against Annex I
We compare your current development and operations against the essential requirements of Annex I: security by design, default configuration, data protection, vulnerability handling. The result is a list of specific gaps, not general advice.
- Output
- Gap analysis with priorities and effort estimate
CRA readiness (Cyber Resilience Act) · step 03 / 06 · 2-3 weeks
24-hour reporting process
We set out how an actively exploited vulnerability and a severe incident are recognised, who decides on reporting, through which channel and with what template. This obligation applies from 11 September 2026, ahead of the rest of the regulation.
- Output
- Reporting procedure, roles and notification templates
CRA readiness (Cyber Resilience Act) · step 04 / 06 · 4-8 weeks
Vulnerability handling and support period
We introduce an SBOM, tracking of vulnerabilities in dependencies, free security updates and a coordinated disclosure policy. We also define the product support period and what you guarantee within it.
- Output
- SBOM, VDP and a defined support period
CRA readiness (Cyber Resilience Act) · step 05 / 06 · 4-8 weeks
Documentation and conformity assessment
We prepare the technical documentation under Annex VII and the basis for the EU declaration of conformity and CE marking. Certification is carried out by a notified body - we get you ready for it and accompany you through it.
- Output
- Technical documentation and declaration basis
CRA readiness (Cyber Resilience Act) · step 06 / 06 · ongoing
Post-market surveillance
We set up continuous monitoring of the product on the market, reporting across the supply chain and regular review of documentation, so compliance does not last only until certification day.
- Output
- Surveillance plan and review calendar
Experience and track record
Security engagements cannot be displayed with the client's name. We list the type of environment and the role the founder held or holds there. Specific names on request and by agreement.
-
Banking systems
Security of a core banking system and the surrounding services built as part of a new digital bank - the part where the general ledger lives.
security architect
-
Military logistics system
A fully integrated microservices-based military logistics system - asset management, equipment maintenance, and supplies for units at home and on foreign missions. Architecture and security design.
security architect
-
Encrypted communication without server infrastructure
A mobile messenger for environments with high confidentiality requirements: a custom cryptographic core, national-grade encryption algorithms and elliptic curves required by the client, and a protocol with continuous key renewal. No central server - traffic passes through a relay that sees neither the content nor metadata about who talks to whom.
cryptography · government
-
Encryption module for data links
Development of an encryption module protecting IP traffic according to the cryptographic standards mandated by a state client: implementation of primitives, key management and distribution, separation of the crypto core from the rest of the system, and verification that the module withstands an attack on its own hardware.
cryptography · defence
-
Analysis and visualisation of communication data
A system for processing large volumes of intercepted communication data and visualising it as relationships between parties. Emphasis on the integrity and traceability of processing, role-based access control and an audit trail - with data of this kind, insider misuse is a bigger risk than an attack from the internet.
government · data security
-
Federation of public administration portals
Designing the security rules for federating portals across the agendas of different ministries from the end user's point of view - citizens and companies alike: how an identity is verified once and carried between agendas, where one authority's trust in another ends, and how it stays traceable who accessed which data. Delivered for one of the large consulting firms.
security design
-
Smart homes and surveillance
Security of the solutions developed by a company building intelligent homes with alarm and surveillance: the integration platform, configuration tools and operational security of installations at end customers.
security architect
-
Autonomous AI agent systems
Security architecture of autonomous agent systems: permission boundaries for individual agents, isolation of tools and data, control over irreversible actions, defence against prompt injection, and an audit trail that shows why an agent did what it did.
AI architect
-
Security review agents
An agent-based solution for autonomous security review of code and changes, running on local inference - so source code and secrets never leave the customer's infrastructure. Findings go straight into the development process, not into a separate report.
AI architect
-
Identity and authentication of AI agents
Answering the question every security team asks once agents start acting on their own: which agent performed this action, on whose authority and with what permissions. Agent identity designed separately from the user's identity, verifiable delegation between agents with narrowing scope, short-lived credentials and immediate revocation of the whole chain during an incident.
AI and identity security
-
Vulnerability management
Vulnerability management for a major Czech bank, extending into the whole banking group - unifying the record of findings, priorities and remediation deadlines across dozens of systems and suppliers.
security architect
-
IoT platform
Security of a platform connecting devices in buildings: network separation, secure device enrolment and updates, protection of gateway-to-cloud traffic, and limiting what a single compromised device can do to the rest of the installation.
security architect
-
Secure mesh communication for extreme conditions
Design and development of a low-power mesh communication system on the IEEE 802.11ah standard (Wi-Fi HaLow) for environments without infrastructure and with demanding climatic conditions: routing algorithms, transport security, power optimisation and long-range reliability testing.
research and development
-
Data collection platform for distributed devices
Hardware and software platform for remote collection of multimedia data: embedded design, remote device management, signed OTA firmware updates, monitoring and centralised infrastructure management for long-term unattended operation in the field.
embedded and platform security
-
Robot Process Automation
A high-throughput RPA system for a banking environment that integrates and reports data across all systems daily. We handled robot access to sensitive data, credential management and the audit trail - while keeping delivery fast.
security architect
-
Law firm system
A system for team management and secure storage of legal documents and publications in large law firms. Access rules between cases, encryption at rest, and security and performance testing.
security architect
-
Low-latency systems
Design and implementation of communication protocols for microcontroller-based devices. Running in hundreds of installations where latency is as much a problem as downtime.
security design
-
NATO codification catalogue
A NATO codification application used in 23 countries - responsibility for the database architecture, time-critical search algorithms and integration of adjacent systems.
architect
Research
We keep part of our capacity for applied research
We collaborate with academia - among others with the Faculty of Information Technology and the Faculty of Electrical Engineering at Brno University of Technology - on machine learning, AI agents, security models and smart living. This is not marketing: it is how we know how new technology behaves before a client deploys it.
Who is behind it
A small team with a long track record
Mgr. Vojtěch Zavřel
founder · security architect
More than 25 years in the field - from similarity search research at Masaryk University through enterprise frameworks to the architecture of banking and military systems. Security has been his long-term focus: designing security architectures, leading threat modeling and vulnerability management in banking, testing web applications and introducing secure development into teams that build software. An architect who also reads code.
Ing. David Podzimek, DiS.
senior security engineer · AI platform architect
Builds systems from hardware and edge up to high-throughput cloud platforms with an AI/ML layer. Experience from specialised solutions for the military, security forces and e-commerce - environments where security and reliability are a precondition for deployment. Here he leads the design of AI platforms, agent systems and local inference.
Egor Koriakov
security project manager · security engineer
More than 15 years in an R&D company working on communication protection - from engineer of communication security systems to project manager. He led the delivery of high-precision complexes for monitoring communication channels (GSM, SHF, UHF) and contributed to an optical channel encryptor for satellite links. He then built his own cryptographically strong hardware-software solution for protecting classified communication.
Mgr. Jiří Mikulášek
architect · DevSec
Architect of highly available cloud services - years on a platform for universal data processing and analytics, and since 2023 on an AI agent built on top of it. Alongside that, integration and automation of smart home systems. He treats security as part of design and operations, not as a review at the end, and approaches new technology with an open mind.
Ing. et Mgr. Lukáš Matěna
IoT security specialist · system designer
Specialist in the security of IoT systems and smart buildings. He designs and delivers large installations, so he knows their weak points from practice: device protocols, integration platforms, remote access and what actually fails in operation.
More people on the team
network security · penetration testing · compliance
Besides the people above, the team includes further experienced colleagues working on network and infrastructure security, penetration testing, forensics and compliance (NIS2, ISO 27001, DORA). For each assignment we put together the team the problem requires - responsibility for the result always stays with us.
Thinking about the security of a system that does not exist yet? That is the cheapest moment.
Tell us what you are building. We reply within two business days and say straight away whether it is a fit for us - or who to ask instead.