Secure coding training on code that looks like yours
Workshops for software developers on the flaws we find when we test applications, how to recognise them in your own code and how to fix them for good.
Overview
Why developers need more than a checklist
Most vulnerabilities are not exotic. They are the same few classes, such as injection, broken access control and weak session handling, written again in a new feature by someone who was never shown what they look like in their own language. A list of rules does not change that. Seeing the flaw in realistic code, and fixing it yourself, does.
Black Fox builds its secure coding training from what we find in penetration tests and code reviews. We tailor it to the languages and frameworks your teams use, so the examples are in code your developers recognise and the fixes use the features of the stack they already work in.
The training is defensive throughout. Developers learn how a weakness is exploited only as far as they need to understand why it matters, and spend their time on recognising it, fixing it and writing the test that keeps it from coming back.
Who it is for
Development teams that build web applications, APIs or mobile back ends, teams whose penetration tests keep finding the same classes of flaw, new hires joining an engineering team, and organisations whose framework or customers expect developers to receive regular secure development training, as PCI DSS and ISO/IEC 27001 programmes commonly do.
The work, from scoping to evidence.
What we do
Common vulnerability classes
The flaws behind most real findings, such as those in the OWASP Top 10: injection, broken access control, cross-site scripting, insecure deserialisation and server-side request forgery, among others.
Authentication and sessions
Password storage, multi-factor authentication, session tokens, cookies, password reset flows and authorisation checks, and the mistakes we see most often in each.
Input and output handling
Validation, parameterised queries, output encoding, file uploads and parsing untrusted data, with the safe patterns your framework already provides.
Dependencies and frameworks
Choosing and updating libraries, reading advisories, handling secrets and configuration, and using framework security features as intended rather than around them.
Secure design and code review
Thinking about trust boundaries and abuse cases before writing code, and review habits that catch security problems in pull requests.
Writing security tests
Unit and integration tests that check access control, input handling and other security behaviour, so a fixed flaw stays fixed.
How the engagement runs
Kickoff
We meet your engineering leads, agree the audience, the topics, the format and the language, and sign an NDA first if you need one.
Tailoring
We look at your languages, frameworks and the kind of applications you build, and adapt the examples and exercises to match.
Workshops
Interactive sessions online or on site, in English, German or French, mixing short explanations with hands-on exercises on realistic code.
Exercises
Participants find and fix flaws in prepared code written in your stack, then write tests that prove the fix holds.
Follow-up
A summary of what was covered, the questions that came up and suggestions for what to practise or extend next.
What you receive
- Training plan tailored to your teams and stack
- Workshops with exercises on realistic code
- Training materials and exercise code for your records
- Attendance records for audit evidence
- Summary report with recommendations for follow-up
Questions
Which languages and frameworks do you cover?
We tailor the training to your stack, for example Java and Spring, C# and ASP.NET Core, Python and Django, JavaScript or TypeScript with Node.js and React, PHP or Go. Tell us what your teams use and we will confirm what we can cover.
Is this the same as your DevSecOps training?
No. Secure coding training focuses on the code developers write and review. DevSecOps training covers security in the pipeline and the delivery process. The two can be combined.
Will developers learn to attack systems?
Only as far as it helps them understand a flaw in their own code. The focus is on recognising weaknesses, fixing them and testing the fix, not on attacking systems they do not own.
Can you use our own code in the exercises?
Yes, if you want to, under an NDA and access you control. Otherwise we use prepared code written in your languages and frameworks.
Related services
- Advisory and responseDevSecOps trainingHands-on DevSecOps training from Black Fox Security: CI/CD security, infrastructure as code, containers, cloud, supply chain, secrets and threat modelling.
- Advisory and responseDevSecOps and secure developmentDevSecOps from Black Fox Security: secure SDLC, threat modelling, code review, security in CI/CD, dependency and secret scanning, and developer training.
- Offensive securityPenetration TestingPenetration testing by Black Fox Security: black, grey and white box tests against an agreed scope, business and technical reports, and a retest of your fixes.
- Advisory and responseCyber hygiene trainingPractical cyber hygiene training from Black Fox Security: passwords, MFA, phishing, updates, data handling and remote work, tailored to your tools.
Fix the flaw before it is written
Tell us which languages your teams use and what your last tests found. We will propose training that fits your code.