Onboarding and induction for secure development

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

1. When should a new developer first learn the organisation's security policies and expected practices?

A During onboarding and induction, from their first day

B Only after they cause a security incident

2. Which is the best way to set up a new developer's account during onboarding?

A Give full administrator access in case they need it later

B Give only the access needed for their role (least privilege)

3. What is the purpose of a security policy briefing during induction?

A To explain the rules and procedures developers must follow to protect data and systems

B To let developers decide for themselves which security rules to follow

4. Which is a secure coding expectation that might be explained during onboarding?

A Validate all user input and keep secrets out of source code

B Hard-code API keys in the code so they are easy to find

5. Why might a new developer be asked to sign a confidentiality or acceptable use agreement?

A It makes the organisation fully responsible for any security mistakes they make

B It records that they understand and accept their security responsibilities

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

Left column		Right column
1Onboarding and induction		ASecure coding expectations are delivered too late. They should be taught from the first day, before the developer commits code.
2role: junior_dev, access: read-only		Binduction.briefing(policy="password and data handling")
3A security policy briefing makes sure new developers know the rules before they start work		CIntroducing new developers to the organisation's security policies, tools and expected practices from their first day
4Signing agreements records that a new developer has accepted their security responsibilities		DAccount setup with least privilege: a new developer gets only the access their role needs
5newDev.access = "admin" # full access on day one		EBreaks least privilege. A new developer should start with minimal access for their role, not admin rights.
6if (week > 4) { brief("secure coding") }		Fsign("confidentiality_agreement")

Definitions

Onboarding and induction

Fill in the Blanks

Complete each line of code by filling in the missing parts.

______________(new_dev, "read_only")

IF signed == _____ THEN deny_access()

___ EACH task IN checklist: complete(task)

IF reviewed ___ no_secrets THEN merge()

______ "Read the security policy first"

Spot the Error

Shade in the letter of the line that contains an error.

Question 1

A role ← 'junior developer'

B perms ← ALL

C createAccount(newDev, perms)

Question 2

A policy ← loadSecurityPolicy()

B present(newDev, policy)

C IF newDev.hasRead = TRUE THEN

D blockRepoAccess(newDev)

E END IF

Question 3

A standard ← getCodingStandard()

B teach(newDev, standard)

C ignoreFirstCommit(newDev)

D logEvent(newDev, 'trained')

Question 4

A rules ← personalPreferences

B FOR EACH rule IN rules

C explain(newDev, rule)

D NEXT rule

Question 5

A newDev ← createAccount(email)

B skipMFA(newDev)

C assignRole(newDev, 'junior')

D sendWelcomePack(newDev)

Answer Key

Onboarding and induction for secure development

Section A: Quick Questions

A — During onboarding and induction, from their first day

B — Give only the access needed for their role (least privilege)

A — To explain the rules and procedures developers must follow to protect data and systems

A — Validate all user input and keep secrets out of source code

B — It records that they understand and accept their security responsibilities

Section B: Match the Pairs

Onboarding and induction → Introducing new developers to the organisation's security policies, tools and expected practices from their first day

role: junior_dev, access: read-only → Account setup with least privilege: a new developer gets only the access their role needs

A security policy briefing makes sure new developers know the rules before they start work → induction.briefing(policy="password and data handling")

Signing agreements records that a new developer has accepted their security responsibilities → sign("confidentiality_agreement")

newDev.access = "admin" # full access on day one → Breaks least privilege. A new developer should start with minimal access for their role, not admin rights.

if (week > 4) { brief("secure coding") } → Secure coding expectations are delivered too late. They should be taught from the first day, before the developer commits code.

Section C: Definitions

Onboarding and induction — Introducing new developers to an organisation's security policies, tools and expected practices from their first day, so they work securely from the start.

Section D: Fill in the Blanks

create_account(new_dev, "read_only")

IF signed == FALSE THEN deny_access()

FOR EACH task IN checklist: complete(task)

IF reviewed AND no_secrets THEN merge()

OUTPUT "Read the security policy first"

Section E: Spot the Error

B — New accounts must follow least privilege. The permissions should be the minimum needed for the role, minimumFor(role), not ALL access.

C — Access should be blocked for developers who have NOT read the security policy. The condition should test for FALSE, not TRUE.

C — Secure coding expectations are checked by reviewing a new developer's first commit, so this should be reviewFirstCommit(newDev), not ignoring it.

A — Secure coding expectations come from the organisation's secure coding standard, not from personal preferences. It should be secureCodingStandard.

B — Onboarding should enrol new developers in multi-factor authentication from day one. The line should be enrolMFA(newDev), not skip it.