From code to evidence
How can you verify a generated application’s safeguards before authorising a limited pilot?
- Lovable
- Claude Code
- Codex
3500 € per session, excl. VAT
In short
Over two days, totalling 14 hours excluding breaks, participants audit a generated application, address its priority risks and verify its safeguards through reproducible tests. The work results in a hardened prototype and a decision dossier for an isolated pilot, without claiming to achieve industrialisation.
Why this training?
A working interface can conceal missing server-side authorisation, exposed secrets or inadequately controlled inputs. Generated code must be treated as a proposal to examine, not as proof of security. The course links each risk to a verified fix. Coding assistance speeds up proposals; human review, negative tests and traceability enable the result to be assessed without confusing a demonstration with actual operational use. Running case study: Avelune Consignes, a fictitious organisation, is preparing a locker booking portal. Its generated prototype includes two roles and several sites: changing an identifier exposes other people’s bookings, while a dummy secret appears in the code. Transfer to the workplace: Apply the control matrix to an authorised internal prototype; have the residual risks reviewed by the security contact before any pilot, then rerun the tests after each generated change.
Objectives of this training
- Map data, roles and trust boundaries
- Prioritise vulnerabilities according to impact and exposure
- Correct access controls, inputs and secrets
- Run positive, negative and regression tests
- Substantiate a pilot decision with residual risks
Who is it for and what are the prerequisites?
Roles and tasks concerned
- Developers and application designers using code generation
- Technical leads overseeing prototypes and their security validation
Prior skills
- Be able to read and modify a web application’s code and its server routes.
- Be proficient in authentication, HTTP requests, testing and version control.
- Have already used a code generation assistant.
What you will work on
Define the exposed surface
Objective: Identify sensitive assets. Flows, roles, storage and trust boundaries.
Examine the generated code
Objective: Establish a verifiable diagnosis. Server routes, dependencies, configurations and limitations of assisted analysis.
Close off unauthorised access
Objective: Enforce server-side authorisation. Authentication versus authorisation; least privilege and booking ownership.
Control inputs
Objective: Limit unintended processing. Server-side validation, parameterised queries and output encoding.
Remove secrets
Objective: Prevent their exposure. External configuration, minimum permissions, revocation and code history.
Harden the configuration
Objective: Reduce avoidable exposure. Sessions, cookies, detailed errors and dependencies.
Oversee assisted changes
Objective: Keep proposed changes under control. Targeted instructions, code differences and human review.
Measure safeguards
Objective: Compare before and after. Negative tests, legitimate user journeys and regression testing.
Prepare the isolated pilot
Objective: Define its safeguards. Restricted access, logs without secrets, backup and rollback.
Substantiate the decision
Objective: Distinguish validation from deferral. Residual risks, responsibilities and suspension conditions.
What you take away
- Threat map and prioritised register
- Hardened prototype with a log of reviewed changes
- Before-and-after comparative test dossier
- Isolated pilot plan and suspension conditions
Method and assessment
- Short explanations followed by immediate practice on the running case study.
- Individual work followed by work in pairs, with peer review of outputs.
- Guided group discussion: what works, what needs correcting and what remains a human decision.
- Preparation: Prepare an isolated environment with test accounts and fictitious or anonymised data, without access to production. Check access to the authorised tools: Lovable, Claude Code or Codex; consult their official documentation for available capabilities and settings.
Observable criteria: Each priority risk has evidence, a fix or a justification for deferral. ; Access between users and between sites is denied server-side in the tests. ; No secrets are present in the delivered code or the checked logs. ; The report quantifies passed, failed and unexecuted tests, with reproducible evidence. ; Any unresolved blocking risk leads to a decision to defer the pilot..
Frequently asked questions
Are all three tools compulsory?
No, one authorised tool is sufficient; the exercises remain focused on the code and its evidence.
Can an internal project be used?
Only after authorisation, isolation and anonymisation; the fictitious case study remains available.
Will the prototype be ready for production?
No: the result prepares for a limited pilot, subject to the organisation’s validations.
Do successful tests prove complete security?
No, they cover defined scenarios; limitations and residual risks remain documented.
Last updated: