In week one, a new developer should learn four things about your secure SDLC: how work flows from story to release, which checks run and what blocks a merge, who to ask for what, and how to report a mistake safely. End the week with one small change shipped through the full process.
Why plan it
New developers copy what they see. If nobody shows them the security steps, they will pick up whatever habits are nearest. NIST's Secure Software Development Framework asks organizations to provide role-based training for personnel with secure development responsibilities, to document the desired outcomes per role and to review proficiency periodically. A short, written week-one plan is a practical start.
The five days
| Day | Focus | Output |
|---|---|---|
| 1 | The flow | Can describe story, review, merge, release |
| 2 | The checks | Has seen each pipeline check fail and pass |
| 3 | The rituals | Has attended refinement, standup and a retro segment |
| 4 | The people | Knows owners and how to ask for help |
| 5 | A real change | Has shipped a small change end to end |
Day 1: the flow
Walk through one real story from the backlog to production. Show the definition of ready, the acceptance criteria, the definition of done and the release step. Use a recent example, not a diagram.
Day 2: the checks
Show the pipeline: dependency scan, static analysis, secret detection and code review. Make each check fail on purpose in a sandbox branch so the new developer sees what a failure looks like and how to fix it. Explain what blocks a merge and who can approve an exception.
Day 3: the rituals
Have them attend refinement and ask what the security question is. Show how standup surfaces blockers and how the retrospective picks up process changes. The Scrum Guide describes the daily event as 15 minutes and the retrospective as a way to plan improvements to quality and effectiveness, so the new person sees where they can speak up.
Day 4: the people
Give a one-page list: who is the tech lead, who is the security champion, who accepts risk, who is on call, and how to reach each. Explain which questions go where. Add the channel for asking "is this a security issue?" with no judgement.
Day 5: a real change
Pick a small, low-risk story. The developer writes the change, writes the test, fills in the pull request template and takes it through review and release with a buddy. Debrief afterward.
Things to tell them early
- Raising a mistake early is expected and welcome.
- If a check seems wrong or slow, say so. That feedback improves the process.
- Never paste secrets or customer data into chat, tickets or public tools.
- Nobody needs to know every rule on day one.
Assign a buddy
A named buddy makes all of this easier. The buddy answers small questions, reviews the first pull requests and shows where the checks live. Pick someone who follows the process, not someone who skips it.
Check it worked
At the end of week one, ask three questions. What blocks a merge here? Who accepts a risk? What would you do if you pasted a secret by mistake? If the answers are vague, adjust the plan. Revisit the plan every quarter and update it after each change in the pipeline.
Safeguard offers dependency scanning, SBOMs and policy gates, so a new developer can see real results on their first pull request. A free scan is at gold.safeguard.sh/scan.
Quick check
How long should security onboarding take?
Week one covers the basics in a few hours spread across five days, with the real learning coming from shipping a small change with a buddy.
Should new developers see failing checks?
Yes. Showing a failing check in a sandbox branch teaches what it looks like and how to fix it, with no pressure.
Sources
Last reviewed: 19 October 2026.
