Six-week programme for technical teams
One day of training fades. Six weeks of work leave the repository changed, with numbers to show for it.
First I measure where the team stands. Then I run the secure development workshop, review real pull requests with you and measure again in week 6. You end up with the controls in your repository, the evidence for your auditor and a before and after built from your own numbers.
For teams that run web applications or APIs in production. The workshop is in person at your company (5 to 8 hours depending on the team) and the rest we do remotely. In English or Spanish.
Can be subsidised through FUNDAE (Spanish training credit).
The problem you already have
The team leaves the course fired up and three weeks later the code looks the same as ever
If training is a single day, what people learned has to compete with the sprint, the deadlines and the incidents. Broken access control, injection and secrets in git history stay where they are, however well the team understood them on a Tuesday. They go when someone looks for them in the code, fixes them and leaves a test so they don’t come back.
And whoever asks you for training often wants proof of it. If you sell to banks, handle payments, hold ISO 27001 or go through a SOC 2 audit, developer training has to be documented, with date, content and attendees. An attendance sheet sometimes falls short.
The programme covers both. I measure where you are today, move from the workshop into your repository by reviewing real changes, and finish by measuring again so whoever decides can see what moved and what didn’t.
What the programme delivers
What you will have at the end of week 6
You can show all of this to whoever has to approve it. None of it depends on me promising a percentage.
- 01
A measured starting point
Indicators we choose together, measured on your own code and pipeline before a single hour of training.
Evidence: a diagnosis sheet with the week 0 values. - 02
Controls in your repository
In the last block of the workshop I leave the configurations and the pull request checklist on a branch of yours, and the team reviews and merges them.
Evidence: a branch with the changes, in your repository and under your permissions. - 03
Leadership gets decisions to make, with no slide deck in between
Three to five pages with what came out of the diagnosis, what we worked on and five prioritised actions, each with a proposed owner.
Evidence: a leadership report delivered in week 2. Careful, it is not an audit. - 04
The workshop applied to real pull requests
Two or three of your changes reviewed in writing with the same guidelines as the workshop, so the team sees how they apply to its own code and not to a practice app.
Evidence: written comments on your own pull requests. - 05
A before and after with your numbers
The same indicators from week 0, measured again in week 6, with what moved, what didn't and what I think happened.
Evidence: a comparison of week 0 against week 6.
How it unfolds
Six weeks, five phases
Every phase has an owner (the team or me) and a deliverable. The programme includes the full secure development workshop, and its syllabus is on its own page.
Diagnosis and baseline
The team answers a 10-minute survey about its stack, its practices and its doubts. I look at a sample of code and pipeline that you let me see, and we agree 4 to 6 indicators. With all of that I adapt the labs to your stack.
Deliverable: A diagnosis sheet with the baseline measurement.In-person workshop (5 to 8 hours depending on the team)
I run the full workshop at your premises. We do the last block on your repository, and there I leave the configurations and the pull request checklist on a branch of yours. The team decides what to merge.
Deliverable: A branch with configurations and checklist; individual certificates.Evidence and leadership report
I prepare the evidence pack from the attendance signed on the day of the workshop. With what came out of the diagnosis and the block on your own code, I write the leadership report, present it to you and we go through it together.
Deliverable: Evidence pack and a 3 to 5 page report with 5 prioritised actions.Q&A channel and pull request review
We open a channel in your Slack or Teams. I reply within two working days and it closes at the end of week 5. The team sends me two or three pull requests it wants reviewed with the workshop's guidelines and I comment on them in writing.
Deliverable: Written comments on 2 or 3 pull requests.Remote review and second measurement
Ninety minutes with the team to see what has been applied, what has not and why, and to adjust the configurations if needed. Before the session we repeat the measurement with the same indicators as in week 0.
Deliverable: A comparison between week 0 and week 6.
Week 1 is the full workshop, with its syllabus and labs: Secure development
Measure, don't promise
The indicators are chosen with you and measured twice
I won't promise that your code will have a given percentage fewer vulnerabilities. It depends on what you apply, and any figure I gave you would be made up. What I do is measure the same things before and after, with your data, and tell you what moved. These are the candidates, and we pick between four and six.
SAST findings per pull request
How many new findings come in with each change, measured over a window of pull requests before and another after.
Pull requests reviewed with the authorisation checklist
What share of the changes that touch endpoints goes through the programme's checklist.
Secrets found in the repository and its history
How many a secret scanner finds, and how many have been rotated and removed by week 6.
Dependencies with a known vulnerability and time to fix
How many the repository has and how long the team takes to update the critical ones.
Pipelines with a lockfile and actions pinned by SHA
What share of pipelines installs from the lockfile and references actions by full commit.
Team confidence, by survey
The same questions in week 0 and week 6 on whether people know how to review authorisation, inputs and dependencies. It is a perception and I report it as one.
Course or programme
| If you need | Workshop | Programme |
|---|---|---|
| The team learns to exploit and fix the most repeated flaws. | The course is fine. One day, six labs and the block on your own code. | Includes the whole course. |
| Knowing whether anything has changed weeks later. | It measures nothing. You take templates away and do the measuring yourselves. | Measured in week 0 and week 6, with the same indicators. |
| Leadership sees what to do and in what order. | No report. The findings stay with the team. | A 3 to 5 page report with five prioritised actions. |
| The team applies the workshop to its own code, with someone reviewing. | Everyone works on their own laptop during the last block. | A Q&A channel and written review of 2 or 3 of your pull requests. |
What stays with the company
Programme deliverables
Everything is yours from the week it is delivered. The lab material comes with an internal-use licence for 12 months.
- Diagnosis sheetWhat the team answers in the survey, what I see in the code sample and the baseline indicators.
- Configurations and PR checklist on a branch of yoursA per-endpoint authorisation checklist and CI gates adapted to your pipeline. It is a technical template and your team reviews it before merging.
- Compliance evidence packSigned attendance, an individual certificate with date, hours and content, a syllabus mapped to the standards that apply to you, and a one-page letter for your auditor.
- Leadership reportThree to five pages with five prioritised actions and a proposed owner for each.
- Written review of 2 or 3 pull requestsComments on real changes of yours, on your platform or on fragments, whichever you prefer.
- Measurement comparisonWeek 0 and week 6 with the same indicators, and what I would keep an eye on over the following months.
- Lab repository with solutionsByteBazaar, the lab briefs and the solutions. Internal-use licence for 12 months, so you can run them again with new joiners.
Included in the programme
Four things you take away on top of the six weeks of work
They are the same ones that come with the course. In the programme they sit inside the phases instead of arriving separately.
- +1
Compliance evidence pack
Signed attendance, an individual certificate with date, hours and content, a syllabus mapped to the standards that apply to you, and a one-page letter for your auditor.
- +2
Pre-workshop team survey
Ten minutes per person in week 0 to adapt the labs to your stack. If it doesn't arrive in time, I carry on with the standard syllabus.
- +3
Configurations on a branch of your repository
CI gates and a pull request checklist, which I leave in the last block of the workshop. It is a technical template that your team reviews and merges.
- +4
Lab repository with solutions
The day's practice exercises to repeat with new team members, with an internal-use licence for 12 months.
Compliance
What evidence the programme leaves and what it is for
The programme leaves the training documented. It does not certify that you comply with any standard, your auditor assesses that, and this record is one of the pieces they can use.
| Standard | What it asks for | What I leave as evidence |
|---|---|---|
| PCI DSS 4.0 · 6.2.2 | Training at least every 12 months for staff who develop bespoke software, covering secure design, secure coding and testing tools, documented. | A syllabus mapped to the requirement's points, signed attendance and an individual dated certificate. |
| ISO/IEC 27001:2022 · A.6.3 | Information security awareness, education and training appropriate to each person's role. | A record per person and per role with content and date. |
| ISO/IEC 27001:2022 · A.8.25 and A.8.28 | A secure development life cycle and secure coding, which includes training the people who write the code. | A mapped syllabus, plus the PR checklist and the CI gates left on your branch. |
| SOC 2 · CC1.4 and CC2.2 | A documented training programme, with completion records per employee and depth that fits the role. | A list with name, date, content and role, plus the leadership report. |
| DORA · Article 13(6) | Digital operational resilience training programmes for the staff of financial entities, proportionate to their role. | Attendance record and syllabus, for those within DORA's scope. |
Who it is for
For a team that wants to finish with a changed repository and numbers
A strong fit for
- Teams who run web applications or APIs in production.
- Tech leads and engineering managers who are asked to show that the team is trained in secure development.
- Companies with PCI DSS, ISO 27001, SOC 2 or DORA on the horizon, who need to document the training of the people who write code.
- Teams that would rather have a before and after comparison than a promise.
Not the right programme if
- You are looking for an inspirational talk for a whole department.
- You need to train two hundred people. A training platform costs less for that.
- You expect an audit or a pentest. Here the team searches its own code and there is no technical findings report.
- One day is enough for you. In that case, the course on its own.
Who delivers it
Security and development from someone who has worked on both sides
I’m Daniel Alfocea, and I’ve spent twenty years in development and security. At Banco Santander I was Principal Engineer in the AI department when the area was being set up. At BBVA I was Cybersecurity Tech Lead. At 42Crunch, in the UK, I was responsible for one of its API security products.
I’ve presented research at RSA Conference and OWASP AppSec EU, and I’m a regular speaker at RootedCON. Spain’s National Cybersecurity Institute (INCIBE) has asked me to judge its competitions several times. I founded Navaja Negra and the OWASP Madrid chapter. I’m the author of widely used security tools such as GoLismero, Plecost and Dockerscan, and of LAPIS, research published on arXiv on how to describe an API to a model with fewer tokens. With Alfonso Muñoz I wrote Secure MCP: A practical guide for developers, software architects and tech leads.
The lab application is mine and it is public. I run the six weeks myself from start to finish, from the baseline to the final review.
If something does not work
What I fix without charging you a cent
Configurations that do not work
If the configurations I leave in your repository do not work in your pipeline, I fix them in a free remote session and we repeat the week 6 review.
A team still stuck after 30 days
If 30 days after the final review the team has got stuck applying something from the programme, I give you an hour remotely, free.
This is not an audit, and I don't promise fewer vulnerabilities or any percentage of improvement. What I leave you is the before and after, measured with your numbers.
Format
A fixed proposal, once we have talked
The price depends on the duration and the size of the team, and we fix it after a call because the amount of code to review and the number of indicators we agree also count. It includes the full workshop, the evidence pack, the leadership report, the Q&A channel, pull request review, the final review and the second measurement.
- Participants from the same team or from areas that work together.
- In-person workshop at your company and everything else remote. In English or Spanish.
- Room, screen, wifi and laptops provided by the company, with Docker installed and access to each participant's repository.
- Access to a sample of code and pipeline for the diagnosis, on your platform and under your permissions.
- Travel outside Madrid agreed before the date is confirmed.
Before you ask for the call