Your first seven steps in DevSecOps & AI security

Cyber Agoge · Free starter pack · 8 September 2026

Start small. These are seven learning sessions, not a promise that you will become job-ready in seven days. Allow roughly 30–45 minutes each and repeat any step you need. You do not need a paid cloud account or a bootcamp place.

1. Understand the company

Imagine FinTrust, a fictional practice bank. Draw four boxes: customer application, cloud hosting, software delivery pipeline and AI assistant. Connect them with arrows showing where information moves.

Write down: What information needs protecting? Who should see it? What could happen if a box stops working?

Your evidence: one diagram and three risks in plain English.

2. Learn how a change is recorded

Read GitHub’s introduction to repositories and pull requests: https://docs.github.com/en/get-started/start-your-journey/hello-world

Create a private practice repository if you want to try it. Add a README explaining your fictional system. Make a branch, improve the README and open a pull request.

Never put passwords, API keys or personal information in your repository.

Your evidence: a small change with an explanation of why you made it.

3. Plan who can do what

Make a table with customer, support colleague and administrator as rows. Add view own account, view another account and change access as columns. Mark which actions should be allowed.

Ask: does the server enforce this, or does the interface only hide a button?

Your evidence: an access table plus one test you would run in an authorised practice environment.

4. Design a safer release

Draw a release journey: change → review → checks → release. Explain what should happen if a security check fails or cannot run.

Read the illustrative project: https://www.cyberagoge.com/sample-project/

Your evidence: three expected outcomes—check passes, check fails, check unavailable. Label expectations separately from actual test results.

5. Give the AI assistant boundaries

Imagine the assistant can explain transactions. Decide whether it should also move money. Identify which actions need explicit human approval and which information it must never reveal.

Write a misuse scenario and a defensive rule. Use invented data only; you do not need to call an AI API.

Your evidence: one risk, one boundary and one test case.

6. Work through a small incident

Scenario: someone reports that a customer can see another customer’s details in the practice application.

Write five actions: confirm safely, contain exposure, preserve relevant evidence, correct the access rule, retest. Identify who needs an update. Never test another person’s system without permission.

Your evidence: a short incident timeline with assumptions clearly marked.

7. Explain your work

Use the project worksheet in this pack. Explain the risk, your proposed control, how you would test it and what remains unproven. Do not present a design exercise as a deployed fix.

Your evidence: a one-page write-up you could discuss with an instructor.

Choose the next step

Keep learning independently: https://tekyu.io/roles

Explore guided training and current dates: https://www.cyberagoge.com/bootcamp/

The bootcamp is optional. This pack is a learning aid, not a certification or a guarantee of employment.

My first security project — worksheet

Cyber Agoge · Free starter pack · 8 September 2026

Use this template for the fictional FinTrust practice environment or a system you own and are authorised to test. Keep customer data, secrets and confidential company names out of anything you share.

Project title

[What are you improving?]

Setting and permission

[Learning exercise / your own application / authorised company task]

[What is in scope? What is outside scope?]

The risk

[What could go wrong? Who or what would be affected?]

[What did you actually observe? Separate observations from assumptions.]

The control

[What change do you propose? Why should it help?]

[Who needs access, and who should be prevented from taking the action?]

Test plan

Evidence to keep

• A diagram or relevant configuration excerpt with secrets removed.

• The change or pull request, if implemented.

• Actual test output and date, if tested.

• A short explanation of any failures and remaining uncertainty.

What this does not prove

[List systems, behaviours and risks you did not assess. Passing one check does not establish that a whole application is secure.]

Your explanation in five sentences

1. The system needs to…

2. The risk is…

3. I proposed / implemented…

4. I tested / would test…

5. The remaining limits are…

Worked design example — not a real test result

Risk: a dependency warning can appear without preventing a release.

Proposed control: make a successful dependency check a prerequisite for release.

Test plan: check passes → release may proceed; check fails → release blocked; check unavailable → release blocked.

Actual results: not tested in this worksheet.

Limits: dependency checks do not test access control or AI behaviour.

See the expanded illustrative example: https://www.cyberagoge.com/sample-project/

The tools, without the jargon

Cyber Agoge · Free starter pack · 8 September 2026

You do not need to learn every tool before starting. Begin with the problem, then choose a tool that helps. This is an orientation guide, not an installation requirement or an offer of software licences. Availability and pricing can change.

Keep track of changes

Git and GitHub: record changes, review them and explain why they were made.

First question: could another person understand and review my change?

Start here: https://docs.github.com/en/get-started

Check changes before release

GitHub Actions: run checks as part of a software workflow.

Gitleaks: help identify secrets accidentally committed to code.

Semgrep: check code for patterns that may indicate security problems.

First question: what happens when a check fails, and who reviews the result?

Start here: https://docs.github.com/en/actions

Describe cloud infrastructure

AWS: hosts applications and supporting services.

Terraform: describes infrastructure as configuration that can be reviewed.

Checkov: checks infrastructure configuration for potential problems.

First question: who can access the system and where is that rule defined?

No paid cloud account is needed for the starter-pack exercises.

Understand what ships

Docker: packages an application and its dependencies into an image.

Trivy: examines supported software artefacts and configuration for risks.

Syft and cosign: help inventory software components and sign artefacts.

First question: what is in this release, and how do I know where it came from?

Test applications with permission

OWASP ZAP and Burp Suite: help inspect application requests and test behaviour.

First question: am I authorised to test this exact environment?

Use purpose-built training systems or your own application only.

Examine AI behaviour

promptfoo and garak: help evaluate AI behaviour using test cases and probes.

First question: what is the assistant allowed to do, and what should it refuse?

Use invented inputs and define expected behaviour before running a test.

Explain the evidence

A diagram, a pull request, a test log and a clear report are often more useful than a long tool list. Explain what the evidence shows and what it does not.

Optional guided next step

Cyber Agoge teaches code, cloud, pipeline and AI security through a fictional practice bank, with check-ins and office hours. Review the syllabus and current enrolment details: https://www.cyberagoge.com/bootcamp/

Backed by DevSecAI — the AI security company protecting real enterprises. Students practise on Arko.