Assessment · Training · Implementation

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.

Tailored to your stack English & Hungarian Founder-led · 15+ years in security
What we do

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.

Assess

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 Advisory
Enable

Build stronger teams

Practical secure coding, DevSecOps and AI-code security training, tailored to your team's technology, workflows and experience.

Training formats
Implement

Put 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 workflow

AI writes the code. Who reviews the risk?

Volume
More changes reach review than before, while review capacity stays the same.
Patterns
Generated code can contain well-known vulnerability classes, such as injection, missing authorisation checks or hardcoded secrets, and still look correct.
Access
Coding agents can read repositories, run commands and reach credentials or pipelines, so their permissions become part of your attack surface.
If this sounds familiar

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.
The approach

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.

Commit

Write it safely

Secure coding patterns, secret scanning and threat modeling a real feature.

AI-generated code goes through the same gates
Build

Catch issues early

SAST and dependency scanning in the pipeline, tuned to cut the noise.

Test

Verify security

DAST, IaC scanning and review gates that fail clearly on what actually matters.

Deploy

Protect what you ship

Supply chain integrity and runtime checks, owned by the team that ships.

What we cover

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 checklist
Practical security training

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.

Start here

Dev Security Taster

Half day · remote or on-site

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 taster
Ongoing

Security Mentoring Retainer

Monthly · remote

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 retainer
Advisory

Engineering 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

  1. Clear findings. A focused review of the relevant application, architecture or delivery workflow, with the identified risks and their engineering impact.
  2. Prioritised next steps. Practical recommendations, ownership considerations and a realistic improvement sequence.
  3. Implementation support. Hands-on assistance to integrate agreed controls into development workflows, where this is part of the engagement scope.
AI development securityIn development

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.

Who's behind it

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., founder of CyberMentee

Barnabás Sándor, Ph.D.

Founder, trainer & advisor

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 LinkedIn
15+years in security8years teaching developersPhD · Óbuda University lecturer
Previous employers4iG Group · MOL Group · GE Digital · Morgan Stanley
Newsletter

Build Security In

The engineering side of security: secure coding, DevSecOps, AI code and NIS2, for teams who ship. One email per new issue.

Questions

The things teams ask first.

Who is the training for?
Software engineering teams, tech leads and architects who ship code, from product and platform teams to DevOps and SRE, as well as CTOs and security leads who want to understand what should change. No prior security background is needed: we start from the way the team already works.
Can you work on our own code and pipeline?
In the hands-on workshop, where it is practical and agreed: we adapt the exercises to your languages, repositories and CI/CD setup, and agree access and scope in advance. The half-day taster uses a purpose-built practice application, so it needs no access or preparation on your side.
Does this help with NIS2 or ISO/IEC 27001?
It can support that work. NIS2 requires covered organisations to manage cybersecurity risk, including security in the development and maintenance of systems, and to include cybersecurity training among their measures. ISO/IEC 27001 has controls for secure development and for security awareness and training. Our training addresses the engineering side and provides attendance and completion records you can keep as evidence of training. Training alone does not make an organisation compliant, and we do not give legal advice on how the rules apply to you.
Which languages and tech stacks do you cover?
Most modern stacks: JavaScript/TypeScript, Python, Java, C#/.NET, Go and PHP, across web, API and cloud-native applications. The CI/CD work covers common platforms such as GitHub Actions, GitLab CI, Azure DevOps and Jenkins. If your stack is not on the list, ask: the principles are the same and we tailor the examples to you.
Do you cover AI-generated code and Copilot security?
Yes, and it runs through every format rather than sitting on a single slide. AI assistants generate code quickly and can introduce well-known vulnerability classes, while the extra volume puts pressure on review. We show developers how to review AI-generated changes for typical failure modes, how to limit what assistants and agents can access, and which checks belong in the pipeline so speed does not outrun security.
Do you cover vibe coding and no-code AI builds?
Yes. It is no longer only developers who ship code: product and operations people now assemble apps from prompts too, often without a security background. We show where that code breaks (hardcoded secrets, missing authorisation, injectable inputs), the review gates that catch it before production, and where to draw the line so non-engineers can build without shipping an incident.
What is the AI Development Security Health Check?
A focused assessment approach we are developing for teams that use AI coding assistants or agents. It looks at where these tools are used, what they can access, which review and approval steps are enforced and what evidence your development controls produce. It is in development, so it starts with a scoping conversation.
How does engineering security advisory work?
We first agree a specific question, for example how AI-generated changes should be approved or which CI/CD controls to enforce, then the scope, the access needed and the expected outcome. Every engagement has an agreed scope and an end point; it is not an ongoing managed security service.
How long is it, and what is the format?
From a half-day taster to a one- or two-day hands-on workshop, plus an optional monthly retainer. Sessions are lab-based rather than slide-driven: developers spend most of the time finding and fixing real vulnerability classes.
Is it remote or on-site, and in which languages?
Both. Workshops run on-site across the EU or fully remote, whichever suits the team, and the retainer is delivered remotely. Sessions and materials are available in English and Hungarian.
Can you prepare training material for our organisation?
On request, yes: we can prepare content tailored to your roles, stack and internal policies, in English or Hungarian. We scope this case by case; it is not an off-the-shelf course catalogue.
What does it cost?
It depends on the format, team size and how much we tailor to your stack. Training and advisory engagements are scoped on a short call. Tell us your team size and goals and we will send a clear quote, with no obligation.
How is this different from generic security e-learning?
Generic e-learning is watched once, forgotten and never touches your code. This is live and hands-on, adapted to your stack and, in workshops, run on your own code where practical, led by someone who has secured production systems and taught engineers for years. The goal is changed habits, not a completion badge.
How do we get started?
Start with a half-day taster or a 30-minute scoping call. We look at where your team is, what is worth fixing first and whether training, advisory or both fit best, and you leave with a clear next step either way.
Get in touch

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.

We use your details only to reply to your enquiry. See our privacy policy.