Build security in, not bolt it on.
CyberMentee helps engineering teams identify security risks, build practical skills and embed effective controls into the software delivery lifecycle, including AI-assisted development.
The earlier a flaw is caught, the cheaper it is to fix. That is why we start where the code is written, not where the pentest report lands.
Three areas, one goal: security that is part of how you build.
Three complementary capabilities, not separate products. We combine them according to where your team is.
Understand the risks
Assess application security, development practices, CI/CD workflows and the risks introduced by AI-assisted coding. Turn findings into a prioritised improvement plan.
Engineering Security AdvisoryBuild stronger teams
Practical secure coding, DevSecOps and AI-code security training, tailored to your team's technology, workflows and experience.
Training formatsPut security into practice
Integrate security controls into code review, CI/CD pipelines and software supply chains, with clear ownership and useful engineering evidence.
Security in your workflowAI writes the code. Who reviews the risk?
The pentest report is back. Forty pages of findings the team has seen before. Patching them one by one is not the fix: the goal is developers who stop writing them in the first place.
- The same vulnerability classes appear in every report: injection, broken authentication, leaked secrets, vulnerable dependencies.
- Generic e-learning gets clicked through and forgotten. It never touches your actual codebase or pipeline.
- Security feels like something done to the team after the fact, instead of part of how they build.
Security built into every stage of how your team already works.
Security works best when it becomes part of everyday engineering decisions, from design and coding to build, test and release. Scanners and gates find problems; clear ownership and agreed review and release rules decide what happens next, so we work on both.
Write it safely
Secure coding patterns, secret scanning and threat modeling a real feature.
AI-generated code goes through the same gatesCatch issues early
SAST and dependency scanning in the pipeline, tuned to cut the noise.
Verify security
DAST, IaC scanning and review gates that fail clearly on what actually matters.
Protect what you ship
Supply chain integrity and runtime checks, owned by the team that ships.
Application security, approached as engineering.
These topics run through all three areas: assessment, training and implementation. Pick what your team needs most; everything is adapted to your stack.
Secure coding
The OWASP Top 10 in your languages: injection, authentication, secrets and the patterns that prevent them.
Threat modeling
Find risk at design time on a real feature: trust boundaries, attack surface, blast radius.
Pipeline security
SAST, DAST and SCA in CI/CD as enforced quality gates.
Dependencies & supply chain
Software composition analysis, SBOM and artifact integrity, so what you ship is what you built.
Secure SDLC & governance
Roles, approval gates and traceable evidence: an operating model, not a checklist.
Training for NIS2 and ISO/IEC 27001 programmes
Covers the secure development side of both frameworks, with attendance and completion records. Training supports your compliance work; it does not make you compliant on its own.
Free NIS2 secure-development checklistAI-assisted development
AI-assisted development accelerates delivery. It also increases the importance of clear ownership, code review and security controls. The question is not whether teams use AI, but whether their engineering practices can keep pace. We cover how to review AI-generated changes, which controls belong in CI/CD, and how to limit what assistants and agents can access.
AI code and vibe coding security trainingVibe coding & no-code AI builds
More features, and even whole apps, are built from natural-language prompts, sometimes by people with little engineering or security background. The result often works but is rarely safe by default: hardcoded secrets, missing authorisation, injectable inputs. We cover where these builds break and which review gates catch the problems before production.
From a short taster to deeper, hands-on training.
Training works when developers can apply it to their own engineering environment. Our sessions focus on practical decisions, real-world failure modes and secure development workflows. Short tasters use focused practice exercises; deeper workshops use your own code and development workflows where practical and agreed.
Dev Security Taster
A live session where the team finds and fixes real vulnerability classes in a purpose-built practice application, then discusses how the lessons apply to your own code.
- Hands-on from the first minute
- No preparation needed on your side
- A clear picture of where the gaps are
For: teams that want to see the approach before committing.
Book a tasterHands-on Workshop
The core format. We tailor the workshop to your team's languages, development workflow and security challenges. Exercises can include code review, threat modeling and designing CI/CD security controls, on your own code where practical and agreed.
- Tailored to your languages and workflow
- Exercises on your own code where practical and agreed
- What the team learns applies to the next development task
- Reviewing AI-generated changes safely
For: teams ready to change how they build.
Plan a workshopSecurity Mentoring Retainer
Keeps security in the room after the workshop. Within an agreed monthly scope: review of selected new code and pipeline changes, plus office hours for the development team.
- Review of selected new code and configuration
- Office hours when the team gets stuck
- An experienced security voice without a new hire
For: teams that want the change to last.
Discuss a retainerEngineering Security Advisory
Focused security engineering support for teams that need to understand a risk, make an architectural decision or improve a development control. We work within a defined scope and turn technical findings into actionable engineering decisions. It is not a managed or 24/7 service, and not an open-ended retainer.
Typical questions we work on
- How should code review and approval work when part of the code is AI-generated?
- Which security checks should we build into our CI/CD process so that the findings stay manageable?
- What could go wrong with this feature? Threat modeling a design before it is built.
- Where do we need tighter handling of secrets, dependencies and build artifacts?
- Which application security practices and evidence should our NIS2 or ISO/IEC 27001 work rely on?
What you get
- Clear findings. A focused review of the relevant application, architecture or delivery workflow, with the identified risks and their engineering impact.
- Prioritised next steps. Practical recommendations, ownership considerations and a realistic improvement sequence.
- Implementation support. Hands-on assistance to integrate agreed controls into development workflows, where this is part of the engagement scope.
AI Development Security Health Check
An assessment we are developing for teams that already use AI coding assistants or developer agents. It reviews how AI-assisted development affects code quality, security ownership, tool permissions and existing review controls. Because it is in development, every engagement starts with a scoping conversation about your setup.
What it looks at
- Where assistants and agents are used, and what they can read, run and change
- Access to repositories, secrets, package registries and CI/CD
- Which human review and approval steps are actually enforced for AI-generated changes
- Whether there is traceable evidence that security checks and approvals were actually carried out
Why it matters now
Coding agents act with real permissions. A token made available to an AI agent, or an agent that can merge to the main branch or run arbitrary commands in CI, can turn a development tool into new attack surface. The questions are simple; the answers are often spread across tools and teams.
Practical security, grounded in engineering experience.
CyberMentee is founder-led. Its founder has spent his career securing production systems and teaching engineers, at university and in his own courses, so training and advisory are built around engineering work rather than slides.
Barnabás Sándor, Ph.D.
Security works best as part of the development process, not as a check at the end. For more than 15 years I have worked hands-on in DevSecOps, security architecture and automation. My previous employers include MOL Group, 4iG Group, GE Digital and Morgan Stanley, where my work included leading security teams and introducing DevSecOps practices. I hold a PhD in cybersecurity and teach developers at university and in my own courses.
Connect on LinkedInThe things teams ask first.
Who is the training for?
Can you work on our own code and pipeline?
Does this help with NIS2 or ISO/IEC 27001?
Which languages and tech stacks do you cover?
Do you cover AI-generated code and Copilot security?
Do you cover vibe coding and no-code AI builds?
What is the AI Development Security Health Check?
How does engineering security advisory work?
How long is it, and what is the format?
Is it remote or on-site, and in which languages?
Can you prepare training material for our organisation?
What does it cost?
How is this different from generic security e-learning?
How do we get started?
Which service are you interested in?
Choose a service below. If you are not sure yet, describe your team, your stack and what prompted this. We will reply with where we would start, without a sales deck.