← VCE Software Development U4O2

What makes a development environment insecure

A workspace where weak controls over people, tools, code and data let vulnerabilities enter the software or let attackers reach it.

Part of: VCE Software Development - U4O2 - Cyber Security: secure software development practices — Module 23

Understanding What makes a development environment insecure in VCE Software Development U4O2

What it does: A public repository holding secrets is unprotected source code, which lets attackers reach the software. With logging and alerts turned off, there is no monitoring, so breaches and misuse are not detected. Weak access controls (shared accounts, excess privileges) are a key sign of an insecure development environment. Least privilege keeps access limited. Unmanaged tools and dependencies can bring in malicious or vulnerable code. An approved list helps control what enters the software. Without monitoring such as access logs and audit trails, attacks and unauthorised changes can continue for a long time without being detected.

Common mistakes: Allowing guest access to the development server is a weak access control, because anyone can reach the code and data without logging in. It should be server.allow_guest = False. Giving every developer admin rights breaks the principle of least privilege and is a weak access control. A developer should only get the access they need, such as allow_read(repo).

Class: _____________________ · Name: _____________________ · Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

🖨 Print worksheet + answer key Add What makes a development environment insecure to a class →

This module's key terms are also in a printable crossword (Modules 23–47) and word search (Modules 1–47).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning

Duo

Which development environment is MORE insecure?

Each developer has their own login with access only to the files they needEvery developer shares one admin login and can change any file

Matches

chmod 777 /project/source (every user can read, edit and delete the code)

↓

Permissions are too open, so any user or intruder can change the source code. It should follow least privilege with only the access each role needs.

Applying

Meanings

Term

insecure development environment

Meaning

A workspace where weak controls over people, tools, code and data let vulnerabilities enter the software or let attackers reach it.

Practice

weak_access ← TRUE

Testing

Gaps

repo.visibility = ""

Check Answer

Spots

2server.require_login = True

3server.allow_guest = True

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy

Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games

Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print

Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Add to class →

Quick Questions

1. Which development environment is MORE insecure?

A. Every developer shares one admin login and can change any file ✓

B. Each developer has their own login with access only to the files they need

Weak access controls (shared accounts, excess privileges) are a key sign of an insecure development environment. Least privilege keeps access limited.

2. Which practice makes a development environment insecure?

A. Developers only use libraries from an approved and checked list

B. Developers install any library they find without checking it ✓

Unmanaged tools and dependencies can bring in malicious or vulnerable code. An approved list helps control what enters the software.

3. True or false: A development environment is secure as long as the final software is tested before release.

A. False - the environment itself must also be protected ✓

B. True - testing the final product is enough

Weak controls over people, tools, code and data can let vulnerabilities in or let attackers reach the software, so testing the final product alone is not enough.

4. Which source code setup is MORE insecure?

A. Code stored in a public repository with no access restrictions ✓

B. Code stored in a private repository with restricted, logged access

Unprotected source code can be stolen, copied or altered. It can also expose secrets such as API keys.

5. Which situation shows 'no monitoring' in a development environment?

A. Access logs are reviewed, so unusual changes to the code are spotted

B. Nobody checks logs, so an attacker's changes to the code go unnoticed ✓

Without monitoring such as access logs and audit trails, attacks and unauthorised changes can continue for a long time without being detected.

Match the Pairs

Shared admin login: dev_team / Password1 for all developers → A weak access control: everyone shares one easily guessed admin account, so actions can't be traced and attackers can gain full access

npm install any-package --force (no version checks or approval) → An unmanaged tool and dependency: packages are added without vetting, so malicious or vulnerable code can enter the software

Unprotected source code: a public repository with no access restrictions exposes code and secrets to attackers → git remote add origin https://public-repo.com/payroll-app (visibility: public, API key in config.js)

No monitoring: without logs or alerts, suspicious activity in the environment goes unnoticed → logging = OFF; alerts = NONE; access_log_review = never

chmod 777 /project/source (every user can read, edit and delete the code) → Permissions are too open, so any user or intruder can change the source code. It should follow least privilege with only the access each role needs.

Developers install any free tool they like on the build server, and no one keeps a list → Tools are unmanaged, with no approved list, updates or tracking. Only approved, patched tools should be allowed and recorded.

Key Term

insecure development environment

A workspace where weak controls over people, tools, code and data let vulnerabilities enter the software or let attackers reach it.

Fill in the Blanks

1. repo.visibility = "public"

Hint: Type the visibility setting that lets anyone on the internet view the source code.

2. GRANT ALL PRIVILEGES ON *.* TO 'dev';

Hint: Type the keyword for the broadest permission level, which breaks least privilege for a developer account.

3. IF library.version < latest THEN FLAG library AS outdated

Hint: Type the comparison operator that shows the installed dependency is older than the newest release.

4. logging = False alerts = False

Hint: Type the Boolean value that leaves activity monitoring switched off so attacks go unnoticed.

5. git add .env git commit -m "update" git push origin main

Hint: Type the name of the settings file that holds secrets and should never be committed to a repository.

Spot the Error

Question 1

A server.env = 'development'

B server.require_login = True

C server.allow_guest = True

Line C — Allowing guest access to the development server is a weak access control, because anyone can reach the code and data without logging in. It should be server.allow_guest = False.

Question 2

A role = user.role

B if role == 'developer':

C allow_admin(repo)

D else:

E deny(user)

Line C — Giving every developer admin rights breaks the principle of least privilege and is a weak access control. A developer should only get the access they need, such as allow_read(repo).

Question 3

A pkgs = load('approved.txt')

B for p in requested:

C if p not in pkgs:

D install(p)

Line D — A package that is not on the approved list should be blocked. Installing it adds an unmanaged dependency that could be malicious or vulnerable. The line should be block(p).

Question 4

A def login(user, pw):

B delete_log(user)

C if check(user, pw):

D return True

E return False

Line B — Deleting the log means login attempts are not monitored, so attacks go unnoticed. The line should record the attempt with log_attempt(user).

Question 5

A repo.visibility = 'public'

B repo.branch_protect = True

C repo.require_review = True

Line A — A public repository leaves the source code unprotected, so anyone can read it and look for vulnerabilities or secrets. It should be set to 'private'.

Student with a class code? Join your class →